EtherNet/IP Big Data Part 2

EtherNet/IP Big Data

In my last article, I discussed how to use EtherNet/IP Explicit Messages to transfer large blocks of data between an Originator (typically a Scanner like a PLC or PC) and a Target (some end device). In this article I’m going to discuss the various ways you can use I/O Messaging (also called Implicit Messaging) to move large blocks of data. Unlike Explicit Messaging, which moves a specific attribute between Originator and Target, I/O Messaging moves I/O Assemblies between Originator and Target. Understanding all this is critical without a foundation knowledge of CIP (Common Industrial Profile) data.

Here’s a cheat sheet on CIP terminology that you’ll need to understand all this:

CIP Devices: Common Industrial Profile (CIP) devices are devices which organize data in terms of Objects, Instances and Attributes.

Objects: Objects are groupings of like Attributes. For example, the predefined Identity Object is the collection of Attributes like Vendor Number, Revision Number, Product Code, Description and other Identity data.

Instances: Instances are Objects that duplicate the Attributes of an Object Class. A Flow Meter that monitors two water channels might have two instances of Flow Attributes, one for the first channel and one for the second channel.
Attributes Attributes are the data elements of an Object Instance.

Input Assemblies: An Input Assembly is a collection of Input Attributes, or real world inputs, that are collected together to be transmitted to a Scanner as a group

Output Assemblies: An Output Assembly is a collection of Output Attributes or real world outputs that are collected together to be received from the Scanner as a group

It’s critical to understand that an EtherNet/IP Adapter device simply connects the Scanner to the real world. The Scanner sends a set of Output Assemblies to the Adapter and the adapter device sets its real world outputs from the output buffer. The same thing happens cyclically to the inputs. The Adapter device collects inputs and cyclically send those inputs as an Input Assembly to the Scanner.

In normal operation, these Input and Output Assemblies are pretty small. For example, the Output Assembly for a sixteen valve, pneumatic valve is simply sixteen bits long. Likewise, the Input Assembly is typically also sixteen bits; the current state of each of the sixteen valves.
But often, and it’s happening more now than ever, an Adapter device has much more than sixteen bits of data. Sometimes it has 1K or 2K or 10K of data – much more than is allowed in an Ethernet packet, let alone an I/O message. The limits to an I/O message are what fits in a UDP packet (I/O messages travel as UDP packets). That means 1500 bytes, except when a Rockwell ControlLogix or CompactLogix are the Scanner. The I/O message size is reduced to 500 bytes for these devices.
When the Input or Output data you want to transfer exceeds the limits of a Rockwell Scanner or a UDP packet, there are several options:

OPTION 1 – Use Multiple IP Addresses

In a PC environment you need multiple NICs (Network Interface Cards) to create an Adapter device that appears to a Scanner as multiple devices. In an embedded device you need multiple PHYs and Ethernet MACs (Media Access Channels). The PHYs are the physical interface to the network. The MACs provide the software interface. The PHYs know how to electrically put a bit on the wire while the MACs know the how and the when of putting bits on the wire.
If you use this option you can split your data among the I/O assemblies for each address. You can get 500 bytes of Input and 500 bytes of Output for each IP address.

OPTION 2 – Only Transfer Data That Is Really I/O Data

If you have more than 500 bytes of Input or Output, can you trim that down by eliminating some data? A lot of people make the mistake of transferring data as I/O data that really isn’t I/O data. Obviously, physical I/O is really I/O data. But what about counters? Do you really need to transfer diagnostic counters in the Input assemblies or configuration data as part of Output assemblies? Eliminating configuration data or diagnostic counters that don’t need to be updated every 10msec can sometimes get you under the limit. Use Explicit Messaging to move that data on an as-needed basis.

OPTION 3 – Use Multiple Assemblies & Multiple I/O Connections

There is no requirement in EtherNet/IP to have a single Input Assembly and a single Output Assembly. In fact, there are now provisions in ControlLogix and CompactLogix to support multiple assemblies and multiple I/O connections. Contact our EtherNet/IP experts for more information on how many Input Assemblies and Output Assemblies you can support. Our Royalty Free EtherNet/IP C Source Code supports multiple I/O Assemblies and I/O connections.

OPTION 4 – Use Some Sort of Fragmented Messaging

Another way to support lots of I/O data is to use fragmented messaging. Now, fragmentation of I/O is not built into the Logix PLCs, so you have to build a proprietary fragmented protocol as part of the I/O Assembly. Essentially you would define some sort of header in each Input or Output assembly to be a fragmentation header so that the message can be reassembled properly at the other end. This isn’t a great solution, as it means that some PLC programmer is going to have to implement it in the PLC logic, but it will work.

That’s the conclusion of my two-article series on transferring large amounts of data in EtherNet/IP. If you have questions on this or need some assistance, please contact me, John Rinaldi, directly using