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

>> 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:
> 
<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
the task at hand*.

Overall, if you choose a serial-type protocol, go with something open.
Olaf had some very good advice regarding finding numerous suppliers,
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

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

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!

> >> 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:
> > 
> <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
> the task at hand*.
> 
> Overall, if you choose a serial-type protocol, go with something open.
> Olaf had some very good advice regarding finding numerous suppliers,
> 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
> 
> > 
> > 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

"perfb" <perfb@yahoo.com> wrote in message
news:775799ec.0408020921.72e8090c@posting.google.com...
> 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:-)

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
you're CAN-ready.

-Mike


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