I have been monitoring the Ethernet statistics on some of our PLC's that send/retrieve data across our LAN. One of the statistics is called Deferred Transmissions. I'm suspecting that our LAN is being overloaded, but need some expertise in these stats. Here are some examples on 3 plc's in a 4 hour period.

PLC1 Deferred Transmissions - 2819
Packets In - 1285509
Packets Out - 1174129
Single Collisions - 85
Multiple Collisions - 82

PLC2 Deferred Transmissions - 4058
Packets In - 1321743
Packets Out - 1189409
Single Collisions - 124
Multiple Collisions - 147

PLC3 Deferred Transmissions - 2426
Packets In - 1139660
Packets Out - 1011333
Single Collisions - 72
Multiple Collisions - 51

Any comments ?

 

This looks like the old Denver Airport baggage handling system. The deferred transmissions are most likely the ones that timed out and eventually got to the wire. This happens when the Ethernet module listens before transmitting and detects the line in use. It waits a random period then tries again. The warning sign are the multiple collisions. A normal flat Ethernet network often gets single collisions. Once set back and retried, they usually get through 96% of the time. Here first and multiple collisions are nearly equal.

The solution at Denver Airport was to subdivide the network with switches. Ethernet switches are not very expensive these days. With a full duplex switch, each PLC has a private line to the switch so that there can be no collisions. Full duplex allows it to receive while sending eliminating the delay from detection of a busy network. The switches resolve and buffer all transmissions at line speed.

Subnetwork and conquer.
Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

Not at all surprised. I believe Etherenet is still not an industrial network unless modified. Have had full mail boxes with GE-Fanuc PLCs on Ethernet - there were only 4 PLCs and receive requests were 2 seconds apart and very little data was involved.

GE-Fanuc have global I/O in their Ethernet solution now and it is supposed to be much better. I believe Omron either have the same thing or have it on the way. Perhaps others have it too. The PLC communications operate with there own protocol beneath the Ethernet layer, I am lead to belive.

Much prefer PLC proprietary networks based on token ring. For example, Omron Controller Link is fast and completely seamless.

 

Switches are often touted to be the solution to the collision problem. This is true in some cases but not in all cases. I recently surveyed an industrial network where collision rate was heavy. There were 15 stations on the segment and all of them were connected through switches. The cause of the problem has been identified to come from 5 ControlLogix PLCs that were multi-casting (broadcasting) at a high rate (approx 1Mbps).
Since brodcasting goes through all ports of switches, they were not really better than hubs.
These multi-casting packets were caused by producer/consumer connections. Most of them were point-to-point connections. We replaced them with explicit messages and the collision rate dropped down to an acceptable level.

Conclusion:
Modern industrial protocols (Ethernet/IP, Modbus/TCP and possibly others) are using broadcasting and if that feature is overused, it can slow down your network dramatically.

In the above example, a possible solution would have been to subsegment the network and use a router (routers can block broadcasting and multi-casting traffic) but removal of producer/consumer connections has been selected as a better
solution.

 

Thanks for the case history. You are correct, a foolish configuration can defeat any good design. I am sure that the producer/consumer messages simply overloaded the network. They can create collisions if you are NOT using a full duplex switch. Actually, most managed switches allow you to configure each device as full or half duplex, but default to half since ALL devices will work in half-duplex. Operation at full duplex allows the device to send even if it is receiving. I think that the ControlLogix
processors will work either way, but default to half-duplex.

Never-the-less, your solution was a well considered choice.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================