CANOpen vs Ethernet

My project will involve multiple PC-104 modules with embedded Linux
performing specialized tasks such as video processing, servo motor
control, etc.  These modules will need to talk to each other, and I am
considering options such as CANOpen and Ethernet.

It seems that the main advantage of CANOpen is in the way the packets
are handled to improve latency.  However I am not sure that we need
this extra performance for our application if there is a lot of extra
work involved.  It would be nice to use Ethernet because it is such a
well developed standard.

Some packets we send will be small (servo control decisions), others
may be larger (output of video processing for intermediate
processing).

Any thoughts on the real world comparisons of CANOpen vs Ethernet; for
example, performance and development time?

Thanks

On 16 Apr 2004 18:12:51 -0700, ngpost@pacificp.com (DD) wrote:

>My project will involve multiple PC-104 modules with embedded Linux
>performing specialized tasks such as video processing, servo motor
>control, etc.  These modules will need to talk to each other, and I am
>considering options such as CANOpen and Ethernet.

Why do you keep insisting on using multiple low performance PC/104
processors for such different tasks as video processing and stepper
motor control ?

For instance, I very much doubt that a PC/104 processor could do much
video processing :-). 

Either use a single very powerful processor and use video and stepper
motor PCI peripheral cards or use a truly distributed system with each
node with required capabilities.

"Embedded Linux"  (whatever that refers to) is not a hard real time
environment (unless patched up with a separate real time kernel), so
putting everything on a single processor is not a good idea, if
critical timing or security things must be considered.

On a distributed system, put the video processing close to the camera
or display unit and use some PCI based 500-1000 MHz processor. If full
speed digital video needs to be processed, even Ethernet does not
necessary have the required performance.

The rest of the functionality could most likely be handled with
separate 100 MHz PC/104 CPU cards which can be  stacked with
additional PC/104 peripheral cards, with each node close to the
stepper motors or other systems that needs to be controlled.

The communication system depends on _what_ you want to communicate. I
very much doubt that video frames are sent directly to the stepper
motor controller :-). 

CAN is very nice, if you frequently want to transfer small amounts of
data (64 _bits_ or less), while Ethernet is nice if you infrequently
want to transfer large amounts (up to 1500 _bytes_). At lower speeds,
a CAN bus can be longer than a standard 100 m Ethernet segment, but in
this case one other alternative would be to use RS-485 with some
protocol on top of it.

For a small system, with only a few nodes and only a limited number of
message types, a simple CAN bus implementation is usually sufficient
with manually tracking the CAN identifiers. However, if the number of
nodes is large, the configured nodes change or more than 64 bit data
entities needs to be transferred, then it is usually easier to
implement CanOpen than try to invent your own high level protocol.
  
Depending on what functionality you put into each box, this determines
what data have to be transferred between nodes and this dictates what
kinds of connections between the boxes are viable.

Paul
 

Thanks for the great info Paul.  To clarify, the video processing will be
performed on a workstation PC with fast processors.  Smaller sets of data
will be passed to algorithms on a PC-104 that also combine data from other
PC-104s, and this will be passed on to a PC-104 with the servo controller
code.

I am leaning toward Ethernet.  Is the latency advantage of CAN very large
compared with Ethernet?  Ideally the various modules would have max latency
of 0.05 - 0.2 sec.

Thanks

DD <nowhere@noemail.org> wrote:

> I am leaning toward Ethernet.  Is the latency advantage of CAN very large
> compared with Ethernet?  

CAN has no particular advantage in latency --- it has one in
*determinism*, i.e. its latencies won't vary as wildly as those of an
Ethernet at the same throughput load relative to their respective
capacities.  Ethernet is essentially dead once you get more than about
10 percent collision rate.  CAN can survive that, because in case of a
collisision, one of the colliding packets wins and still gets
transmitted.

Given that CAN only goes up to 1 MBit/s to begin with, its total
throughput is at least one, possibly three orders of magnitude less
than that of Ethernet (assuming Gigabit is a viable option for you).
That's what yoy should worry about primarily if you plan on
transporting stuff like video streams.

> Ideally the various modules would have max latency
> of 0.05 - 0.2 sec.

50 milliseconds is an eternity for both Ethernet and CAN.  

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

ngpost@pacificp.com (DD) wrote in message news:<bb790921.0404161712.f6b8c09@posting.google.com>...
> My project will involve multiple PC-104 modules with embedded Linux
> performing specialized tasks such as video processing, servo motor
> control, etc.  These modules will need to talk to each other, and I am
> considering options such as CANOpen and Ethernet.
> 
> It seems that the main advantage of CANOpen is in the way the packets
> are handled to improve latency.  However I am not sure that we need
> this extra performance for our application if there is a lot of extra
> work involved.  It would be nice to use Ethernet because it is such a
> well developed standard.
> 
> Some packets we send will be small (servo control decisions), others
> may be larger (output of video processing for intermediate
> processing).
> 
> Any thoughts on the real world comparisons of CANOpen vs Ethernet; for
> example, performance and development time?

It is always hard to directly compare network architectures without
having "far" more details about the communication requirements as you
can always construct examples where one is better.

As a CANopen addict I am biased (www.CANopenBook.com), but allow me to
highlight a few CANopen plus points:

CANopen is not really depending on CAN as the basis, it can run on top
of Ethernet (Powerlink), too (http://www.ethernet-powerlink.com).

You can drastically shorten your development time by using CANopen
chips (www.canopenia.com), CANopen boards (www.phytec.com,
www.peak.com, www.ccontrols.com) and many off-the-shelf I/O nodes
including I/O nodes (see www.canopen.us for a list of some
products/vendors)..

If your own boards remain "simple" in I/O, www.MicroCANopen.com is a
good point to get started with CANopen source code.

In regards to latency times here is an example: In case of the highest
CAN bus speed (1Mbps) a single message with 7 data bytes) takes about
100 microseconds to transmit. Assume that it has a "high" priority
then only those messages with an even higher priority will delay that
message, so the latency of a high priority message can be below 1
millisecond.

Olaf
Tutor at ESAcademy
www.esacademy.com
www.microcanopen.com
www.canopen.us

Paul Keinanen wrote:

> On 16 Apr 2004 18:12:51 -0700, ngpost@pacificp.com (DD) wrote:
> 
>>My project will involve multiple PC-104 modules with embedded Linux
>>performing specialized tasks such as vidseparatesnetworkservo motor
>>control, etc.  These modules will need to talk to each other, and I am
>>considering options such as CANOpen and Ethernet.
> 
> Why do you keep insisting on using multiple low performance PC/104
> processors for such different tasks as video processing and stepper
> motor control ?
> 
> For instance, I very much doubt that a PC/104 processor could do much
> video processing :-).
> 
> Either use a single very powerful processor and use video and stepper
> motor PCI peripheral cards or use a truly distributed system with each
> node with required capabilities.
> 
> "Embedded Linux"  (whatever that refers to) is not a hard real time
> environment (unless patched up with a separate real time kernel), so
> putting everything on a single processor is not a good idea, if
> critical timing or security things must be considered.
> 
> On a distributed system, put the video processing close to the camera
> or display unit and use some PCI based 500-1000 MHz processor. If full
> speed digital video needs to be processed, even Ethernet does not
> necessary have the required performance.
> 
> The rest of the functionality could most likely be handled with
> separate 100 MHz PC/104 CPU cards which can be  stacked with
> additional PC/104 peripheral cards, with each node close to the
> stepper motors or other systems that needs to be controlled.
> 
> The communication system depends on _what_ you want to communicate. I
> very much doubt that video frames are sent directly to the stepper
> motor controller :-).
> 
> CAN is very nice, if you frequently want to transfer small amounts of
> data (64 _bits_ or less), while Ethernet is nice if you infrequently
> want to transfer large amounts (up to 1500 _bytes_). At lower speeds,
> a CAN bus can be longer than a standard 100 m Ethernet segment, but in
> this case one other alternative would be to use RS-485 with some
> protocol on top of it.
> 
> For a small system, with only a few nodes and only a limited number of
> message types, a simple CAN bus implementation is usually sufficient
> with manually tracking the CAN identifiers. However, if the number of
> nodes is large, the configured nodes change or more than 64 bit data
> entities needs to be transferred, then it is usually easier to
> implement CanOpen than try to invent your own high level protocol.
>   
> Depending on what functionality you put into each box, this determines
> what data have to be transferred between nodes and this dictates what
> kinds of connections between the boxes are viable.
> 
> Paul


CANopen could be an option for the control part of his application, if servo
drives with CANopen filedbus interface are available. CAN interfaces are
typically  cheap, it might make sense to have a separate network for the
motion control tasks.
-- 

with best regards / mit freundlichen Gr��en

   Heinz-J�rgen Oertel
+===================================================================
| Heinz-J�rgen Oertel  port GmbH  http://www.port.de
| mailto:oe@port.de
| phone +49 345 77755-0     fax   +49 345 77755-20
| Regensburger Str. 7b,     D-06132 Halle/Saale,  Germany 
| CAN Wiki    http://www.CAN-Wiki.info
| Newsletter: http://www.port.de/engl/company/content/abo_form.html
+===================================================================