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 

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

> -----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

Reply via email to