EtherNet/IP Assemblies 101

One of the hardest things to understand about EtherNet/IP is the concept of an assembly: what they are, how they are used, and what the limitations are. You can think of it as the train station for I/O messages coming to and leaving a device.

Since an assembly is actually a CIP (Common Industrial Protocol) object, to understand EtherNet/IP assemblies we have to understand CIP objects. CIP is the foundation technology for CompoNet, DeviceNet, EtherNet/IP and ControlNet. CIP objects represent all the data in those protocols. CIP Objects are nothing more than a collection of related data.

To explore CIP Objects, let’s examine a fictional EtherNet/IP I/O device. Our imagined EtherNet/IP I/O device is going to have some inputs and outputs, some discretes, and some analogs. Depending on the input or output type, there is a lot of associated data. For discrete outputs, there will be the current state of each output, the desired state of each at power on, the state of each at communication failure, and lots more. For the analog inputs, there is going to be a high and low range, units information, and a scaling factor.

As the designer of the device, we can organize this information in many different ways. One object could contain all the points. Or there could an object for each type: an object for analog inputs, one for analog outputs, one for discrete inputs, and one for discrete outputs. All the items of a type, analog inputs, for example, would be contained in the analog Input object. Sixteen analog inputs would be organized as items 1 to 16 of the analog Input object.

The alternatives are almost endless. The designer could make every I/O type an object and group all the other points as instances. The first discrete Input would be instance 1 of the discrete Input Object, the second input instance 2, and so on. All the similar I/O point Objects would simply be an instance of the main type.

The detailed data in each of these Objects is called an attribute. An attribute is nothing more than the name given to each piece of data in an Object. Each output state, engineering unit, input state and everything else is an attribute of an Object. Attributes are specified by the Object number and Attribute number.

An Assembly Object is nothing more than an Object that assembles data from all these data objects together in one place. The Input Assembly assembles one or more attributes from each of the Input Objects, and the Output Assembly distributes outputs to one or more attributes in the Output Objects.

If an Object has both inputs (data moving toward the EtherNet/IP Scanner) and outputs (data moving from the scanner to the device), it can both provide data to the Input Assembly and get data from the Output Assembly.

A key concept here is that the Input and Output Assemblies are the place where the PLC Scanners exchange data with the device. The Input Assembly is cyclically transferred to the scanner. The Output Assembly is cyclically received from the scanner.

The PLC or other EtherNet/IP Scanner device writes outputs to the Assembly Object and they get distributed. The device collects data from its Input Objects in the Input Assembly and sends that assembly to the PLC or other EtherNet/IP Scanner.
What’s interesting is that you can support multiple assemblies and let the user pick the one that makes sense in a given application. In the Robot and Drive projects that we’ve done, we’ve created two, three or sometimes as many as ten assemblies. Some have little to no data in them. Others have everything including the kitchen sink. The end user (or PLC programmer) gets to pick what assembly makes sense in any particular application.

I’ll be regularly publishing information you need to continue your understanding of EtherNet/IP. Watch for more in RTA blog posts, articles in the RTA “Best Darn Newsletter” and the RTA page on LinkedIn.