Ethernet DIO, was DIO Boards


Thread Starter

Ken Crater

This message is being forwarded from Stephen Mason [[email protected]]:
> -----Original Message-----
> From: Stephen Mason [SMTP:[email protected]]
> Sent: Monday, March 27, 2000 1:25 PM
> To: [email protected]
> I am new to this group so forgive my ignorance. I thought the whole issue about using Ethernet for control was the fact that Ethernet is not
deterministic and is susceptible to data collisions. Am I wrong about this?

Isn't that why everyone who uses Ethernet for control has to bastardize it? I would be cautious about using Ethernet on anything that requires
real time I/O control. I am certainly in agreement with the statement that if Linux is to take off as a PLC operating system, it must support the traditional I/O in the marketplace from the traditional vendors, Rockwell, Siemens, etc...

LinuxPLC mailing list
[email protected]
This is an old bug-a-boo.

For years people "proved" Ethernet was no good for control on paper, but the *unfortunate* reality is anyone who did a good job of designing an Ethernet with limited traffic & over-capacity has found it performs much, much better than any deterministic "control network" in all situations. For example, suppose I have 1 PLC acting as Modbus/TCP master and 10 "slaves" - if this whole thing is on an isolated/switched network then you will NEVER have any measurable collisions. I've seen such networks reach 4000 messages/second - pretty good for a cheap, general-purpose, commercial solution.

I'd say the bottom line is: something like "ControlNet" is fool-proof - one cannot design one where determinisim will be a problem, but performance is limited. With Ethernet your options to do it right (or shoot yourself in the
foot) are greatly expended. Any vendor who sells "Ethernet" risks users mis-applying it & getting a bad reputation. Any user who uses Ethernet has
the option to do it right or do it wrong.

If you desire a network with forces users to do it right, then Ethernet is not a good choice.


Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected]
Tel: (949)450-7272 Fax: (949)453-7132

LinuxPLC mailing list
[email protected]

Harald Albrecht

It is interesting to hear information stemming from experience with Ethernet. The situation you mentioned reminds me somehow of Profibus, where the master station polls the slaves for their sensor inputs, sending them the new output values at the same time.

What makes me curious is how Foundation Fieldbus will act with all the other protocols, like SNMP, XNTP, etc. running over the same wire at the same time. The wire then probably would not be as quiet as before...


Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]

LinuxPLC mailing list
[email protected]

Jack Gallagher


I think your whole point about Ethernet needing to be installed by someone who knows what they are doing, is also the argument for the open source industry. Companies should pay for the intelligent engineering and maintenance of systems but not for re-releases of bug fixed code. Engineers develop the code and solutions to the problems and deliver the sources with
their solution. As far as I am concerned, their should always be someone involved with these systems, that knows what they are doing.

The reason Ethernet is so popular is because I can take my nice fast, cheap Windows PC and connect it to most devices over Ethernet. These solutions are cheaper and already supported by a large group of vendors. As a software engineer that designs distributed systems, I don't want to have to concern myself with the communications medium. I just want it to work when I plug it together. Solution Ethernet! :)

LinuxPLC mailing list
[email protected]

Curt Wuollet

Hi Stephen.

Much of what you have heard is from people who have a vested interest in proprietary networks. It's very similar to the real time OS wars in that
very few applications need absolute determinism. "Fast Enough" will serve in most applications. If I was doing machine control, I would greatly prefer 100mbit/sec Ethernet over a deterministic 9600 baud serial protocol. True one of my packets could be delayed by an arbitrary amount, but, I could resend several hundred times and still match the response. Done properly, that is, as a switched isoleted network, it's deterministic enough for all practical purposes. Done on commodity hubs it's still pretty good. I have seen a greater chance that the PLC will miss a read under load than the network. My "deterministic" Devicenet can't follow a 100 hz square wave reliably. When you consider all the links in the chain, sampling theory, etc. I can't get too excited about the "lack" of determinism. And that's from the real world. I'm not selling anything. The bastardization has to do with the fact that there is no "standard" proto on top of Ethernet, but Modbus/TCP is close and probably most prevalent. It also has the same causes as the fieldbus wars. Once "their" protocol runs over Ethernet, you won't hear that Ethernet sucks anymore.

I agree that we have to support the proprietary fieldbusses (and there are NO open fieldbusses) also. If we wait on that, it makes the project
vulnerable to legal bluster from the establishment companies and gives them a means to delay the project. I will do open technology first, de facto standards next, and deal with the rest later. Of course, if anybody coded a legally defensible driver for any of the big busses, it will be accepted gratefully and immediately. We have the chance to excell in Ethernet connectivity before it gets trashed by over commercialization.


Curt Wuollet

LinuxPLC mailing list
[email protected]
Just a few comments to Curt's response...

1) "My "deterministic" Devicenet can't follow a 100 hz square wave reliably." ----- The salesguy who told you DeviceNet was deterministic should be beaten. DeviceNet is based on CAN and CAN uses CSMA/BA which means lower addresses have higher priority and therefore NOT deterministic (and "slow" due to overhead)

2) "I agree that we have to support the proprietary fieldbusses (and there are NO open fieldbusses) also" ---- AS-Interface is totally open and as a result is completly forward and backword compatiable.

3) Just a question? Why would anyone want to deal with all the headaches of ethernet to "do it right" with switches and low traffic levels and and and when they can get better speed, an industrial physical layer and simplicity from a true industrial network. 90% of networked products are sensors. I don't think we will see EtherNet at this level. Most OEM's use conventional wiring methods because the networks are perceived as difficult (even AS-i). Imagine talking to an engineer who is a "pipe and wire" guy are switches? Forget it....This agrument is the same as 7 years ago the PC's would replace PLC's for control. Same story, same outcome.