Ethernet/IP is a communication standard developed by Allen Bradley in 2001 and has been turned over to ODVA as an “open” standard for communicating real-time information over Ethernet. Ethernet/IP implements Allen-Bradley’s CIP (common industrial protocol) on Ethernet using TCP/IP and UDP/IP.
- click to enlarge
Note how CIP uses UDP (which supports unicast and multicast messages) for I/O control information.
For real-time messaging, EtherNet/IP also employs UDP over IP, which allows messages to be multicast to a group of destination addresses. This is how CIP I/O data transfers (implicit messaging) are sent on EtherNet/IP. With implicit messaging, the data field contains no protocol information, only real-time I/O data. Since the meaning of the data is pre-defined at the time the connection is established, processing time is minimized during runtime. UDP is connectionless and makes no guarantee that data will get from one device to another; however, UDP messages are smaller and can be processed more quickly than explicit messages. As a result, EtherNet/IP uses UDP/IP to transport I/O messages that typically contain time-critical control data. The CIP Connection mechanism provides timeout mechanisms that can detect data delivery problems, a capability that is essential for reliable control system performance.
Potential To Flood Devices With Traffic They Can Not Handle
Because the multicast message does not have a real destination address (but only contains a connection ID which is an IP address in a range reserved for multicast messages), the network switch forwards the message to all of its ports. This can cause problems with certain devices on the network that unnecessarily attempt to determine if the UDP message is for them. (This occurs at I/O update rates from multiple I/O adaptors easily reaching 1000 messages per second that need to be checked). In working with my clients we have always used IGMP snooping switches which can handle and properly route this type of traffic without flooding all of the ports. However many users report no problems using just standard switches in isolated I/O only networks. To this author it seems like relatively “cheap” insurance to use the IGMP snooping switches to avoid potential problems with multicasting, such as when someone else adds additional I/O to a system or to temporarily connect a PC to do some program updates or ad-hoc data monitoring.
Vendors are however also offering the option to turn multicasting off and to unicast all I/O information. I’m unclear how this affects the producer/consumer model. It would seem that there can be only one consumer if unicasting is used. For cost sensitive projects with only one PLC controlling all the I/O in a given I/O network this would be a welcome addition. Since this is “new”, I’d be interested in learning about user’s experience on doing this.
The Use Of Switches Keeps The Network Running Smoothly
This author observers that even though this type of messaging can not be guaranteed, the use of network switches effectively make each I/O module a direct connection to the first switch, with the switch in turn handling the data flow to the PLC and other attached devices. This insures that all messages do in fact get through in a timely manner without any “collisions” and retransmissions actually occurring. Only if the network is completely saturated will bottlenecks occur. This is not likely as wire speed is considerably faster than the network devices ability to process the data even with multiple network (host) cards on the same network.
For example a typical network (host) card can process 5000 packets/sec. Assuming a typical packet length of 120 bytes, this means that 4.8 MB/sec of bandwidth is needed. This leaves a lot of overhead on a 100MB/sec network.
Concluding Thoughts
It should be noted that only the I/O adaptor sends its I/O information (back to the PLC and any “listeners”) via the multicast messaging. The “owner” PLC responds (with an acknowledgement message that also contains an update of all the output information) back to the I/O adaptor as a unicast UDP message. Also all configuration information between the PLC and the I/O adaptor modules are also all unicast (TCP?) messages.
For additional background on Ethernet and Ethernet/IP from ODVA see the 118 page paper entitled “Network Infrastructure for EtherNet/IP: Introduction and Considerations“. The paper claims to be an introduction but I think most control engineers will find it quite complete.
For some comments on an Ethernet I/P discussion board see http://www.etherwire.com/discussion/33/cip-multcast-messaging/
Also see my other articles on Ethernet/IP in this blog.
Updated July 28, 2010 4:06 pm CST | Published: June 28, 2010
Harold On Controls 
Leave a Reply