We’re going to talk about EtherNet/IP again this month. I’ve discussed it a number of times in these pages, but there are still aspects of it and idiosyncrasies that are pretty interesting even after all this time.
The topic for this discussion of EtherNet/IP is going to be EtherNet/IP connection management. Before we go there, let’s review the basics of EtherNet/IP so we’re all on the same page. Here are my ten keys to understanding EtherNet/IP:
1 - EtherNet/IP uses standard Ethernet – same as your home network, but I hope that you’re running more industrialized, hardened devices in your factory.
2 - EtherNet/IP messaging is based on CIP – the Common Industrial Protocol. CIP defines the messages, the objects and the profiles (device classifications) used in EtherNet/IP. CIP is also the core of ControlNet, DeviceNet and CompoNet.
3 - EtherNet/IP was derived from ControlNet (one of the other CIP protocols) using many of the same constructs for creating connections and performing messaging. A main difference is the physical layer and the messaging scheduling.
4 - The ODVA owns the technology and the specification. You might be able to code an EtherNet/IP device, but you can’t legally use the EtherNet/IP name without signing a license agreement. I know that because I once dated a very pretty, red-headed lawyer.
5 - EtherNet/IP is a certifiable standard – The EtherNet/IP license agreement states that you won’t sell an Adapter device without ODVA certification testing in their lab. But we make that easy. If you use our source code, we handle all that for you.
6 - EtherNet/IP has two device types: the Scanner and the Adapter. The Scanner, almost always a PLC, makes connections to Adapters and writes Outputs to its Adapters. The Adapter accepts connections and delivers Inputs to the Scanner.
7 - EtherNet/IP uses two message types – Explicit and Implicit. Explicit messages are message/response oriented and used to asynchronously access data in an Adapter device. Implicit messages (I/O messages) are used for control. Inputs cyclically flow from an Adapter to a Scanner. Outputs cyclically flow from the Scanner to the Adapter.
8 - EtherNet/IP uses both TCP and UDP. TCP is used for Explicit messaging and UDP is used for Implicit Messaging. TCP is connection oriented. TCP opens a connection and keeps it open until it’s closed. TCP messages are acknowledged. UDP is connection-less. There is no acknowledgement, no guarantee of delivery, and no notification of a failure. But since we are going to send another I/O message in a few milliseconds, we ignore those that fail.
9 - All EtherNet/IP devices have the same set of required objects – that’s actually a CIP requirement. A Scanner device can always depend on a device implementing the same set of required objects. The Vendor Name is always Attribute 7 of Instance 1 of Object 1.
10 - EtherNet/IP is a control protocol and not an information protocol.
It’s this last point that always gets me in trouble. Trouble with the ODVA for EtherNet/IP and trouble with PI (PROFINET and PROFIBUS International) for PROFINET. These protocols are control protocols, really good at adapting standard Ethernet for I/O applications on the factory floor. They are not good information protocols the way that OPC UA, SNMP and MTT are. They don’t have the flexibility, the transport layers, the security, the event handling and other features required to easily move data into the Enterprise.
Now that we’ve got the basics out of the way, let’s get into the meat of EtherNet/IP connection management. I recently unlocked the door to Jamin Wendorf’s office (he’s our EtherNet/IP guru) and asked him to explain some of the common questions that people have about EtherNet/IP connection management.
Question - Tell me about Connected vs. Unconnected messaging in EtherNet/IP applications.
Answer: This really only applies to Explicit Messaging. I/O messaging is always connected. You can think of it like this: Unconnected is for the simple “connect, send a message, get some result, terminate” type of messaging. It is NOT recommended for constant communications. Configuration and commissioning tools should be the only devices using unconnected messaging.
Question - As a user, why should I care?
Answer: You need to understand how devices are operating to optimize your EtherNet/IP network. When you make a connected messaging connection, you are reserving a part of the bandwidth for the Scanner and Adapter. Scanner devices (like Rockwell PLCs) share resources for unconnected messages but not for connected messaging, and you can run out of those resources. The second reason is to know when a device disappears. With unconnected messaging, a device could vanish from the network and you might not know it for a long time.
Question - Are you saying unconnected messaging impacts detecting cable breaks and other network problems?
Answer: Not for connected I/O connections – you’ll know about those right away. For connected connections, Scanner devices will resend ForwardOpen messages. Since the Adapter isn’t online, the messages get retried by the TCP layer. When the link is finally re-established, those previous ForwardOpen messages are received by the Adapter and a new connection is established. But the Scanner ignores that connection since that request timed out long ago. Now only the Adapter thinks the connection is good. And a low resourced Adapter with a single connection then rejects all subsequent ForwardOpen messages until the half-open connection times out (10 seconds). Only then can a new connection be established. Sometimes this takes 40+ seconds to work itself out.
Question - What do we do to avoid this?
Answer: I tell all of our customers to avoid unconnected messaging in the application processing. There’s also a new required behavior in the TCP object to handle application layer timeout. This should correct some of this behavior, especially the low-end device issue. The TCP connection will close after 2 minutes (once the I/O connection is established). This means the reconnect process will have to open a NEW TCP connection, and there won’t be any old ForwardOpen requests.
Question - You mention the ForwardOpen message. What is that?
Answer: A ForwardOpen is the message that opens a Class 1 I/O connection or a Class 3 Explicit connection. The ForwardOpen includes the RPI (Requested Packet Interval), the routing path (the assemblies that point to the I/O), and any configuration data needed by the Adapter. This is the single EtherNet/IP message that opens a connection. By comparison, DeviceNet had multiple messages to do the same thing.
Question - Tell me about that RPI. What is it, how is it established, and what are the typical values?
Answer: RPI is “Requested Packet Interval.” It’s passed to the Adapter in the ForwardOpen. PLCs usually set it to 10ms for I/O messages and 500ms to 10 seconds for Explicit Messages.
Question - What about duplicate IP Address detection? Do Adapter devices need to implement it?
Answer: Duplicate IP Address detection or Address Conflict Detection (ACD) is part of the EtherNet/IP specification. It is currently not required for ODVA compliance, but is required for Plugfest interoperability certification