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

P

perfb

Jan 1, 1970
0
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.?

J

Jim Stewart

Jan 1, 1970
0
perfb said:
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. J j.b. miller Jan 1, 1970 0 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 P Poul Bundgaard Jan 1, 1970 0 j.b. miller said: 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 ? H H.-J.Oertel Jan 1, 1970 0 perfb said: 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[email protected] | 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 +=================================================================== P Paul Keinanen Jan 1, 1970 0 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 A Armin Steinhoff Jan 1, 1970 0 perfb said: 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 J James Jan 1, 1970 0 Armin said: 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 K Kevin Kramb Jan 1, 1970 0 '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 T Tutors of ESAcademy Jan 1, 1970 0 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
www.CANopenBook.com

B

Barry S

Jan 1, 1970
0
which control network would be, ahem, for lack of a better word, 'best'?
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:
<snip>

In addition to the good advice Olaf gave you, let me throw in another
perspective:

You never mention what your wiring contraints are (ie space and length
of cable runs). Some of the "serial-style" protocols like CANopen (and
others) are great for minimizing cable runs and providing you a much
greater total length of your runs.

Ethernet, on the other hand, has some limitations regarding cable runs.
Mostly, ethernet would be run using a switch (or hub, if they still
exist). This would affect many logistical aspects of your design.
Namely, can you support many 'home-runs' back to the switch from your
devices -- and are they within 200 FT or so from the switch.

Of course, the serial world has its own set of drawbacks concerning
logistics. Mainly, you need to be concerned with induction. Since each
device is daisy-chained, and if they are in a high EMF and high
electrostatic environment, you will need to look at using optoisolators.
Otherwise, be prepared for a world of pain. Nothing like get zapped and
having all your devices go off line while you run around like a madman
with an oscillator / test equipment.

Moreover, you need to be honest regarding your own skill set. You never
mentioned what protocol you would be running over Ethernet, but I assume
it would be TCP/IP. TCP has a wealth of tools available for diagnostics
(ie. ping, traceroute, etc). Many of the proprietary serial-based
protocols have very little with regard of diagnostics. It can be hard to
find why one particular device won't resond. So, you need to
either "know" that protocol or be prepared for some learning
curves.

From my own perspective, I've used many types and I've always wished
that I had attributes of the "other type" from time to time. Like you
hinted in your question, there is no *best*, there is only *best for

Overall, if you choose a serial-type protocol, go with something open.
ease of documentation, etc. There is nothing worse then needing to get a
part shipped *ASAP* because your network is down, but the only supplier
is closed because its Friday afternoon.

-Barry

P

perfb

Jan 1, 1970
0
thanks to all for the valuable feedback!

I notice no one brought up LON/LONWorks as a candidate, is that
becoming an orphan technology, or just a narrow niche technology?
Or, is it just too proprietary/unsupported to consider for
general machine control?

tia!

C

Cameron Dorrough

Jan 1, 1970
0
perfb said:
thanks to all for the valuable feedback!

I notice no one brought up LON/LONWorks as a candidate, is that
becoming an orphan technology, or just a narrow niche technology?
Or, is it just too proprietary/unsupported to consider for
general machine control?

LON was developed by Echelon Corporation way back when, and is a proprietary
protocol that is only "open" in the sense that Echelon are quite happy to
sell the comms chips to OEMs - at the right price (a little like Devicenet
now I think of it ;-).

It is designed specifically for Building Automation and is not a machine
control network. It is also rapidly losing market share to BACNet (short
for Building Automation Control Network) which actually is an "open"
ASHRAE-standard network.

I hope this helps,
Cameron

M

Mike V.

Jan 1, 1970
0
In my case, I don't want to tear up ceilings and walls to run cables
through, so i'm holding off til Zigbee is ready.

Yeah, i know Zigbee is still a pipe dream, but I have other projects
i'm working on at the moment after which I hope Zigbee will be ready
by then.

The best you can get right now with Zigbee are "Zigbee-ready" boards,
since i guess they haven't figured out the stack yet.

By the way, i am making my current projects "CAN-ready", i.e. it has
the hardware ready, but the firmware won't have any CAN functionality
until later product releases. It seems to be a cheaper alternative to
something proprietary like LonWorks. Besides, many of your 8/16/32 bit
micros (e.g. PICs, AVRs, ARM7s, ST-type of micros, Coldfires, etc.)
come ready with a CAN interface. Throw in an 80-cent transceiver, and

-Mike

Replies
7
Views
1K
Replies
6
Views
2K
H
Replies
5
Views
839
T
Replies
1
Views
800
Rich Grise
R
T
Replies
7
Views
1K
JeffM
J