EtherNet for Remote I/O

Would anyone like to share any experiences using Ethernet communications for ControlLogix Remote I/O? I am mainly interested in data reliability issues when used in an industrial environment. Did you use shielded or unshielded cable? What make of switches? Any experiences or advice would be appreciated.

Thanks

Don't have any experience at that but I would think that "traffic" could cause some serious timing and safety issues. Just watch what the i/o does that is controlled that way.

Drewcrew6

Why

drewcrew6 said:

Don't have any experience at that but I would think that "traffic" could cause some serious timing and safety issues. Just watch what the i/o does that is controlled that way.

Drewcrew6

Click to expand...

What do you expect the I/O to do?

Vic, a hub won't do. You need a switch that can handle 10/100 Mb using Full Duplex. If the I/O uses the UDP to 'produce' data then a another problem will occur because this data is 'produced' to all nodes to see and a stupid switch will not keep packets from going to nodes that have no used for the data. A level 3 switch with packet snooping is required for really big systems. We do a lot of Ethernet development using Ethernet/IP. We had to get a smarter switch to keep the I/O traffic from being multicast all over our office network.

We have tested an ENBT module with 11 of our controllers. Each control writes 80 words and receives 48 words every 5 milliseconds. That is equivalent to 22528 bits of I/O. Yes, there are collisions and sometimes the information got delay 20 milliseconds but for the most part the standard deviation was only a fraction of a millisecond.
We used stupid switches for this test. This test also convinced us to get a smarter switch.

The Remote I/O should use the UDP/IO feature of Ethernet/IP.

Ethernet is good if you don't need a very fast I/O, because the TCP/IP protocol is not a real time comunication.
If you have a lot of data to excange the time to acquire increase, if your process is not fast there is no problem, but if your process is fast is not a right solution, the better solution is to use a Industrial Bus: CanBus , ProfiBus for example or other sulution, that is able to keep a speed I/O reading.

Peter I assume this was meant in regards to my post?

What do you expect the I/O to do?

Click to expand...

What I meant was if he's looking for high speed i/o then I wouldn't think its the best way to go about it.

For example to time a variable high speed cutter with an encoder for position and a limit switch or prox to track product position I would think that your cut tolerance would not be very tight.

But I may be wrong as I said I have never dealt with this.

Drewcrew6

drewcrew6 said:

Peter I assume this was meant in regards to my post?


What I meant was if he's looking for high speed i/o then I wouldn't think its the best way to go about it.

For example to time a variable high speed cutter with an encoder for position and a limit switch or prox to track product position I would think that your cut tolerance would not be very tight.

But I may be wrong as I said I have never dealt with this.

Drewcrew6

Click to expand...

We make motion controllers that can be used to cut wood in saw mills.
Communication to our controller is typically Ethernet.
Obviously the photocell, the feed chain encoder and other actuators are connected directly to our controller. Since one already has smarts on the I/O, why not make it smarter?

Coordinating multiple separate I/O nodes can not be synchronized but if it grouped together in a package then the I/O can be.

I know. This isn't remote I/O, one must get the right tool for the right job. The remote I/O can be used for the less demanding I/O.

With Ethernet, intelligent I/O and remote I/O can be combined easily.

luca.bettinelli said:

Ethernet is good if you don't need a very fast I/O, because the TCP/IP protocol is not a real time comunication.
If you have a lot of data to excange the time to acquire increase, if your process is not fast there is no problem, but if your process is fast is not a right solution, the better solution is to use a Industrial Bus: CanBus , ProfiBus for example or other sulution, that is able to keep a speed I/O reading.

Click to expand...

Define fast. If you saw my post above one can see that a Can oriented field bus has no chance of doing that much I/O. Profibus can, but few Profibus masters for PLCs are good enough.

I agree TCP/IP is not very good for real time communications. That is why Ethernet/IP uses UDP, with a smart application layer, to send real time data.