CIP Terminology

I had a friend who worked at NASA a number of years ago when the space program was in full swing. It was an intense, driven environment where some of the brightest minds in the world were working on putting humans into space. It was his dream job.

The most difficult aspect of his work was the terminology. Most places have acronyms; I suppose that even in the trash collection business there are terms that those not in the business wouldn’t understand. But at NASA, acronyms are on steroids. Everything has an acronym and trying to just identify the topic of a conversation was sometimes difficult. He even had the experience of not understanding a lunch invitation because it was cloaked in an acronym. “Ready for PRC?” someone said. PRC was Personnel Refreshment Center – cafeteria to us laymen.

We also have that in industrial networking – too much of it sometimes. Every protocol has its own terms that can be mysterious to the user of some other technology. PROFINET has IRT – Isochronous Real Time. That’s a mouthful and quite impressive the first time you hear it, but not so much once you understand it. Modbus has terms like Holding Register and Status Coil. Not as difficult, but still terms with particular meaning to Modbus.

EtherNet/IP has its class system – Class 1, 2 and 3 communications. But particular to it and other CIP protocols is the way data is described. This is an important concept. I have always said the first thing you want to understand about a communication technology is how it represents data. It really is key to understanding it. In the Common Industrial Protocol (CIP), the core for CompoNet, DeviceNet, ControlNet and EtherNet/IP, we have Objects, Instances, and Attributes. Let’s look at each of them.

Objects are collections of like data. It’s sort of an unfortunate term. To software people, objects imply some sort of structure with a hierarchy and geeky things like inheritance. It’s much simpler than all that in EtherNet/IP. EtherNet/IP Objects are unrelated to each other. They have a number signifying the kind of object they are. Object numbers below 100 are restricted to System Objects while object numbers from 100 and above are User Objects.

System Objects include the Identity Object and the TCP Object. Each one of these brings like data together. An Identity Object brings data like the vendor number, software revision, catalog number and product description together. A TCP Object does the same with data like the TCP/IP address and other data related to the TCP connection. User Objects on the other hand, bring together whatever data the user decides is important to the application. That could be all the analog inputs and outputs or just the analog inputs on Channel 7.

Objects have instances. Generally, there is only a single instance of a System Object but multiple instances of User Objects. Some users will simply put all their data in one instance of one object while others may have lots of objects and lots of instances. There are people who have built representations where a 10 channel device has 10 instances of an object, each with only a single data element.

The data elements of an object are called attributes in this system. The number of data elements is limited to 65,536 elements with a rich selection of data types that correspond nicely with the data types available in an Allen-Bradley PLC. Again, the attributes for the System Object are defined by the specification for the technology while the attributes for user objects are under complete control of the device designer.

In the manufacturing world, things usually aren’t NASA complicated, but we do have terms and technology that are particular to us. Object, Instance and Attributes are some of those things.