TCP/IP Stacks Part 3

In this blog I am going to discuss a little known flaw in a lot of current EtherNet/IP devices that causes problems for lots of EtherNet/IP Adapter device developers.

When an EtherNet/IP controller opens an EtherNet/IP connection it does that by first opening a TCP connection and then opening an UDP I/O connection. The TCP connection is used to configure and instantiate the I/O connection.

I you’re and old timer, you’ll recognize that this is very similar to what was done in DeviceNet. In DeviceNet we have Unconnected Message connections. Those were special connections that did nothing more than instantiate other connections.

The problem that shows up in a lot of EtherNet/IP Adapter devices is that the TCP connection is sometimes never closed. That’s okay if the I/O connection continues to live. The controller is never going to use that TCP connection.

The problem occurs if the controller is disconnected. Someone might power down the controller or pull the cable out of the Adapter, the Controller or the switch. When that happens, the original TCP connection remains alive. The I/O connection by specification must terminate due to a timeout but there is no equivalent requirement for the TCP connection. It stays alive and keeps any resources (RAM) that it had previously.

On a Controller power on or a reconnection, the Controller opens a new TCP connection. The Adapter device allocates a new set of resources to the TCP connection. That connection is used until the I/O connection is instantiated and now you have two TCP connections.

If this happens again (a reconnection or controller power cycle) – and remember this can takes months – eventually your Adapter device runs out of resources. At that point, it refuses to connect to the controller and you get “the call”.

Your customer says, it works fine for a couple of months but eventually it locks up and I have to power cycle it. And you start tearing your hair out over this intermittent problem.

One of the reasons we know about this bug is that it happened to us on our Ethernet Device Converters for ControlLogixs PLCs. We had devices that worked fine for a while but eventually froze up. We traced it to this very problem.

RTA is part of a working group at the ODVA that is making the effort to incorporate some new technology into the EtherNet/IP specification to resolve this problem. That effort will probably not get accepted until sometime late in 2014 or even 2015.

In the meantime, contact us if you have this problem or want
to avoid it. We have some work arounds that we can give you to avoid that dreaded
intermittent failure of your EtherNet/IP device.