'best' control network? Devicenet vs Lonworks vs CAN vs Fieldbus vs Ethernet ???

no doubt this is a FAQ oft beat to death, but, assuming 
one wanted to control a network of about 10 i/o modules each 
with maybe 100 i/o digital/analog points, at maybe a 100Hz
maximum rate (e.g. an automatic industrial processing machine of some kind) 
...

which control network would be, ahem, for lack of a better word, 'best'?

(i.e. in terms of price/node, support, ease of development, availability
of second-sources, availability of developers etc.?)

Personally, being somewhat naive and ignorant of the field, 
I would go for ethernet, for sheer availability of tools and
peripherals.  But would I be making a gross faux-pas in doing so?

is ethernet gaining ground as a general-purpose control network
over e.g. CAN etc.?

perfb wrote:
> no doubt this is a FAQ oft beat to death, but, assuming 
> one wanted to control a network of about 10 i/o modules each 
> with maybe 100 i/o digital/analog points, at maybe a 100Hz
> maximum rate (e.g. an automatic industrial processing machine of some kind) 
> ...
> 
> which control network would be, ahem, for lack of a better word, 'best'?
> 
> (i.e. in terms of price/node, support, ease of development, availability
> of second-sources, availability of developers etc.?)
> 
> Personally, being somewhat naive and ignorant of the field, 
> I would go for ethernet, for sheer availability of tools and
> peripherals.  But would I be making a gross faux-pas in doing so?
> 
> is ethernet gaining ground as a general-purpose control network
> over e.g. CAN etc.?

Ethernet.  Development costs might be a
little higher the first time through, but
the bandwidth per $ and the infrastructure
availability can't be beat.

Whatever system you look at, be sure it can handle broken wiring or loss of
communication.Especially it this is a 'critical' application.
30 years ago we chose to do an 'in-house' design for our remote energy
control system.Simple,reliable,lightning
proof,bidirectional,interlaced,tri-level,hackeproof and best of all ran on a
true single wire.This gave us a built in backup as we leased wires from Bell
and they were always in pairs! The system is still in use today.
Jay

j.b. miller wrote:
> Whatever system you look at, be sure it can handle broken wiring or
> loss of communication.Especially it this is a 'critical' application.
> 30 years ago we chose to do an 'in-house' design for our remote energy
> control system.Simple,reliable,lightning
> proof,bidirectional,interlaced,tri-level,hackeproof and best of all
> ran on a true single wire.This gave us a built in backup as we leased
> wires from Bell and they were always in pairs! The system is still in
> use today.

Do you have more information regarding this system ?

perfb wrote:

> no doubt this is a FAQ oft beat to death, but, assuming
> one wanted to control a network of about 10 i/o modules each
> with maybe 100 i/o digital/analog points, at maybe a 100Hz
> maximum rate (e.g. an automatic industrial processing machine of some
> kind) ...
> 
> which control network would be, ahem, for lack of a better word, 'best'?
> 
> (i.e. in terms of price/node, support, ease of development, availability
> of second-sources, availability of developers etc.?)
> 
> Personally, being somewhat naive and ignorant of the field,
> I would go for ethernet, for sheer availability of tools and
> peripherals.  But would I be making a gross faux-pas in doing so?
> 
> is ethernet gaining ground as a general-purpose control network
> over e.g. CAN etc.?

CAN could be able to handle the required bandwidth, using the max. speed of
1Mbit/s. You can choose between CANopen or DeviceNet as higher layer
protocol. In both cases you can easily upgrade to an Ethernet based Data
Link Layer, e.g. Ethernet-Powerlink or EthernetIP, without changing much
your application level software.

Ethernet based field busses will definitely complement CAN based if high
bandwidth is really needed.

Regarding you subject line:
> Re: 'best' control network?  Devicenet vs Lonworks vs CAN vs Fieldbus vs
Ethernet ???

DeviceNet _is_ CAN.
-- 

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

On 22 Jul 2004 16:18:59 -0700, perfb@yahoo.com (perfb) wrote:

>no doubt this is a FAQ oft beat to death, but, assuming 
>one wanted to control a network of about 10 i/o modules each 
>with maybe 100 i/o digital/analog points, at maybe a 100Hz
>maximum rate (e.g. an automatic industrial processing machine of some kind) 

Do you have a simple master (multi)slave system or a peer-to-peer
system ? What is the distribution between the 100 digital+analog
points ? What kind of distances are between nodes ?

If there is only a single master polling all the stations, practically
any system would be usable and still get very predictable latencies.

>is ethernet gaining ground as a general-purpose control network
>over e.g. CAN etc.?

CAN based protocols are nice if nodes transmit messages spontaneously,
since the hardware based arbitration solves most of the problems.
However, the CAN frame can only contain 64 usable data bits (8 bytes),
so if there is a lot of analog points, quite a few frames would be
required. 

However, with your requirements, less than 10 frames could be sent
from a single module in each cycle at 1 Mbit/s. However, due to the
arbitration method, the maximum distances become quite short,
especially if optoisolators are used. For systems distributed over a
large area 500 kbit/s would be more usable, but this will enable only
3-5 frames/module/cycle.

Paul

perfb wrote:
> no doubt this is a FAQ oft beat to death, but, assuming 
> one wanted to control a network of about 10 i/o modules each 
> with maybe 100 i/o digital/analog points, at maybe a 100Hz
> maximum rate (e.g. an automatic industrial processing machine of some kind) 
> ...
> 
> which control network would be, ahem, for lack of a better word, 'best'?
> 
> (i.e. in terms of price/node, support, ease of development, availability
> of second-sources, availability of developers etc.?)
> 
> Personally, being somewhat naive and ignorant of the field, 
> I would go for ethernet, for sheer availability of tools and
> peripherals.  But would I be making a gross faux-pas in doing so?
> 
> is ethernet gaining ground as a general-purpose control network
> over e.g. CAN etc.?


Powerlink and EtherCAT (real-time Ethernet protocols) are already used 
in the field with great success. Both protocols are going to be 
standardized by standardization bodies ... which very important.

Powerlink and EtherCAT are using Ethernet as transport media together 
with their real-time protocols. Higher protocols can be use in parallel 
(low priority) or encapsulated with EtherCAT.

IOs are available ... but the number of vendors is still limited.

Regards

Armin Steinhoff

http://www.steinhoff-automation.com

Armin Steinhoff wrote:
> perfb wrote:
> 
>> no doubt this is a FAQ oft beat to death, but, assuming one wanted to 
>> control a network of about 10 i/o modules each with maybe 100 i/o 
>> digital/analog points, at maybe a 100Hz
>> maximum rate (e.g. an automatic industrial processing machine of some 
>> kind) ...
>>
>> which control network would be, ahem, for lack of a better word, 'best'?
>>
>> (i.e. in terms of price/node, support, ease of development, availability
>> of second-sources, availability of developers etc.?)
>>
>> Personally, being somewhat naive and ignorant of the field, I would go 
>> for ethernet, for sheer availability of tools and
>> peripherals.  But would I be making a gross faux-pas in doing so?
>>
>> is ethernet gaining ground as a general-purpose control network
>> over e.g. CAN etc.?
> 
> 
> 
> Powerlink and EtherCAT (real-time Ethernet protocols) are already used 
> in the field with great success. Both protocols are going to be 
> standardized by standardization bodies ... which very important.
> 
> Powerlink and EtherCAT are using Ethernet as transport media together 
> with their real-time protocols. Higher protocols can be use in parallel 
> (low priority) or encapsulated with EtherCAT.
> 
> IOs are available ... but the number of vendors is still limited.
> 
> Regards
> 
> Armin Steinhoff
> 
> http://www.steinhoff-automation.com

Ethernet will be you least expensive and most flexible medium. Any 
technology will provide lots of compensated support folks.

Ethernet base technology is more likely to be 'truely open' in the 
fact that you do not have to pay to join or use 'open' technology from 
a consortium of vendors.

You may want to enter these keywords into a Google search:

"RFC real time"  RFC are Request For Comment and they form the basis 
of truely open standards that are recognized for no-cost and not 
patented. Many 'open' standards are economically encumbered by vendor 
groups.

Can does offer a very useful feature: if one of the 2 wires is cut, 
you can still communicate with remote devices. However, as the prices 
of cat 5 cables and wireless ehternet devices continue to plunge, you 
can also set up redundancy in your ethernet network, quite cost 
effectively.

If you do not use raw ethernet, use CAN-Open, as devicenet is a 
particularly *BAD* implementation on Can (from an embedded software 
developer's point of view) that is artificially expensive, due to a 
'good ole boys club' of vendors...... There is NOTHING useful that 
Device net can do, that cannot be done on plan old CAN, with a little 
extra programming.

James

"James" <wireless@tampabay.rr.com> wrote in message
news:4106725D.5070705@tampabay.rr.com...
<snip>
> 'good ole boys club' of vendors...... There is NOTHING useful that
> Device net can do, that cannot be done on plan old CAN, with a little
> extra programming.
>
> James

This is similar to saying, "There is nothing useful that
TCP/IP can do that cannot be done on plain old Ethernet,
with a little extra programming."

DeviceNet defines a complete 7-layer OSI networking model.
CAN is the Data Link layer but DeviceNet goes well beyond
that.

Three useful things that DeviceNet adds to CAN are:
- DeviceNet's Physical layer includes power for devices
  on the network (plus cable and connector standards),
- A conformance testing policy and service that helps to
  ensure interoperability of devices from different vendors,
- Market recognition and acceptance in the industrial
  networking arena.

I'm not saying that there aren't other application
layers for CAN that provide similar useful benefits.
And I'm not saying that these benefits are useful for
every application.  But if these *are* useful to your
application then it would require more than "a little
extra programming" to build these sorts of things into
a home-brewed application layer for CAN.

 -- Kevin

perfb@yahoo.com (perfb) wrote in message news:<775799ec.0407221518.76180fde@posting.google.com>...
> no doubt this is a FAQ oft beat to death, but, assuming 
> one wanted to control a network of about 10 i/o modules each 
> with maybe 100 i/o digital/analog points, at maybe a 100Hz
> maximum rate (e.g. an automatic industrial processing machine of some kind) 
> ...
> 
> which control network would be, ahem, for lack of a better word, 'best'?
> 
> (i.e. in terms of price/node, support, ease of development, availability
> of second-sources, availability of developers etc.?)
> 
> Personally, being somewhat naive and ignorant of the field, 
> I would go for ethernet, for sheer availability of tools and
> peripherals.  But would I be making a gross faux-pas in doing so?
> 
> is ethernet gaining ground as a general-purpose control network
> over e.g. CAN etc.?

To throw in a few more cents (of most likely biased information):

I would not only look at the "best" technology, but also at the
slightly bigger picture:


1.) Do you want to use off-the-shelf components, or develop your own,
or mix both?

If you use ONLY off-the-shelf components, I would make sure that
whatever you pick is supported by at least 2, better 3 big vendors and
that their components can be exchanged and that they have "reasonable"
pricing. Which network technology is actually used then becomes less
relevant.

If you want to develop some or all of the nodes yourself, you should
pick a technology "as open" as possible. One of the reasons we focused
on CANopen is, that it is one of the few protocols that is very
flexible in regards to the functionality you actually implement.
Functionality you don't need you simply don't implement. This allows
for minimal implementations (like www.MicroCANopen.com) greatly
reducing development time and cost, but also helping in keeping
per-node costs down, as smaller microcontrollers can be chosen.


2.) You never mentioned volume and price requirements

If it is a low volume application and the per-node costs are not
terribly important, then again the specific technology is less
important. However, if you have any per-node pricing restraints, you
need to start looking at how to save money.

Here CAN and CANopen are still at the lower end of the scale. A
digital CANopen I/O node can still be built using an 8-bit
microcontroller. Even with all peripheral chips and glue logic needed,
the costs of the hardware components can be below $5 (volume
depending).

Olaf
Tutor at ESAcademy
www.CANopenBook.com