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
