Hi Nicklas When CANopen first came out I was quite resistant to the protocol. But as I've used it more I've come to appreciate it's positives. A lot of COTS devices out there don't support the whole concept of everything configurable with files and on power up. But it doesn't really matter.
And although CANopen is really good as a PLC replacement and the number of devices that now are compatible makes doing projects very simple there are other areas where it just wouldn't work. Ethercat is probably better for full axis control. The system on my home page is an example of a real mixed CAN project. Two controllers each with 5 CAN channels. USB interface to the PC for each. With a limit of 120 nodes maximum on any single CAN bus (driver issues) and the mechanical infrastructure set up as thirds the 150 lamps (PIC 18F series) were broken into 3 groups of 50 per ring. With 5 rings that's 750 lamps per side for a total of 1500 lamps. CAN bridges were used between the controller and the groups of fifty. Coincidently they had the same M9S12 processor we used in the controller so they had an extra CAN port available that was CANopen compatible. So PC -> USB -> M9S12 -...> 5 CAN channels Each CAN channel to Bridge ...-> 3 CAN channels to 50 lamps. Each Bridge also PC -> USB -> CAN4USB to all 10 Bridges with CANopen. The lamps periodically reported temperature and voltage and could be queried for their serial number. The node ID of the lamp could be programmed by sending a broadcast message with the serial number and new node number. Another broadcast message for all nodes could also ask the lamp with a specific serial # what its node # was. If a lamp was installed out of place it didn't require physical access at the end of a long arm bucket to switch out a lamp. The CANopen access allowed us to collect other statistics on CAN activity. The lamps were refreshed at a CINE camera rate of 24Hz which can be sample in such a way that film cameras, 50Hz European and 60Hz North American video would not result in a flickering effect due to refresh rates. This was an example where a custom high level protocol was the only solution. I've also been shipped around the world to a few places to fix custom CAN protocols that broke rules and resulted in the equipment not working well. John Dammeyer http://www.autoartisans.com > -----Original Message----- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > Sent: March-09-19 10:00 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything > more? --> Not fast enough > > > So CANopen is way different. Far more jitter. If you figure that the > average 8 byte CAN message is really closer to 135 bits with bit stuffing and > CRC each message at 1Mbps is 135 uS. That's only 7.4khz. Even if you used > less data and managed to keep the bit stuffed messages under 64 bits that's > still 64 microseconds and 15.6kHz. Not fast enough for step/direction > messages. > > > > John Dammeyer > > http://www.autoartisans.com > > Speed is certainly a problem on several axis and why I will not use CAN but I > want however use CANopen message format over other networks. > > > Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
