Scanners, and Adapters, and EtherNet/IP. Oh My!

The Tin Man, Cowardly Lion, Scarecrow and Dorothy were afraid of lions, and tigers and bears… and you might be afraid to look closer at Scanners and Adapters and EtherNet/IP. It can be confusing! If there is one thing that seems to elude a lot of the people looking at EtherNet/IP technology, it’s that a Scanner, by definition, contains an Adapter. I don’t know if that fact is hidden but most people looking at Scanners always seem surprised when I explain that.

It might be that there is so much to absorb that it’s easily missed. The terminology is the first challenge for everyone. In the very early days of EtherNet/IP, they called the piece that made the connections, sent out outputs, and got back inputs, Clients. They called the piece that sat there and patiently waited for somebody to talk to it, a Server. Unfortunately, there was so much confusion between EtherNet/IP Client and Servers, and Ethernet Clients and Servers, that the ODVA adopted the terms Scanner and Adapter.

(That alleviated some of the confusion but let’s be honest, they called the thing “EtherNet/IP” – one of the most confusing terms of all time. IP, as all but the most clueless software engineer knows, is Internet Protocol as in TCP/IP. That is until it’s the IP of EtherNet/IP than it stands for Industrial Protocol. No awards for the selection of that term.)

But I digress. Back to Scanners and Adapters. Why do Scanners have built-in Adapters? It’s actually kind of obvious. When a Scanner wants to interrogate a device and get its manufacturing date, vendor ID, product catalog number, and other identity information, it needs to make a connection to it. To accept the connection from a Scanner, a device has to act like an Adapter and accept an explicit message from the Scanner. (An explicit message is one that explicitly specifies what is being read or written.)

Scanners acting like adapters

An Adapter is a device that accepts connections from Scanners and processes explicit and implicit (cyclic) messages. But the Scanner device, which just might be a PC Tool that issues the connection message, doesn’t know if there is an Adapter or Scanner at that IP address. All it knows is that it wants to make a connection and get its identity data. If the target device is a Scanner, the only way it can respond to that explicit message is if it acts like an Adapter. And so, it was decided to force all Scanners to act like Adapters, at least as far as explicit messages are concerned.

Now that doesn’t necessarily mean that the Adapter embedded in the Scanner is a fully functioning Adapter. A lot of PLCs limit the Adapter capability. Some will have dedicated buffers that they use to support implicit messaging and let other Scanners access their data tables. Others, like ControlLogix and CompactLogix, don’t support any implicit messaging. As a Scanner, you have to query the target device to see if it supports implicit messages, or only explicit.

Another thing that confuses our customers is that, when they buy a Scanner for a product line, they can use the same code to make an Adapter product or a Scanner product, or a dual Scanner/Adapter. It’s completely up to them.

Some customers just want an EtherNet/IP Adapter device so they purchase only that code set. Other customers want the royalty free EtherNet/IP Scanner code set so that they get a product that has the capabilities to be either a Scanner or an Adapter.

So that’s a big part of my job – clearing up the confusion in the networking part of industrial automation. Fortunately, with that in my job description, I’ll always have work.