CIP Class Complexity

As many of you know who continually read these articles, I am a very simple guy. I hate complexity. I don’t want to spend 20 minutes trying to understand the dashboard on my rental car. I want to use a cell phone to make telephone calls (not necessarily receive them). And I want a thermostat that I set to a temperature and it stays there. I don’t want it “thinking” about what time I plan to return to the house. Is it just me, or do other people long for the simple days of the past?

Some people have fun with complexity and pointless invention. I just read about a machine called the “waiting machine” that taps a finger of a mechanical hand for you. Then there’s the gasoline powered flashlight for those of you who require portability and convenience. And another is the paper tearing machine. We all do so much writing these days and who wants to tear their own paper up after another failed draft?

That stuff makes fun of complexity but it doesn’t do much to root it out and expose it where it needs to be exposed. For example, in the automation world, the terms Class 1 and Class 3 just bug me. They don’t clarify anything. They don’t make EtherNet/IP or DeviceNet more understandable. They just contribute to the general complexity of describing how these networks operate. I feel that if we are going to use those terms we should also have a secret handshake and a decoder ring.

I like to describe things clearly, but I am often stymied because those are the terms used in the specifications. But when I hear them, it often seems that someone is trying to impress me that they read the specifications because that’s the only place that you can learn them.

The EtherNet/IP and DeviceNet (CIP – Common Industrial Protocol) specifications describe Class 1 and Class 3 communications. In the specification, a Class 1 connection refers to an implicit I/O connection. That’s the connection type where a Scanner device makes a connection with an Adapter device and requests an implicit I/O connection. In that kind of connection, a set of outputs are sent to the Adapter and the Adapter returns a set of inputs. The Adapter converts the outputs to some physical, digital, or analog representation. It converts its physical inputs to a digital or analog value and sends those to the Scanner.

Unlike a message/response pair used in lots of other communication systems, the output and input messages are unrelated in a Class 1 message. The Scanner could issue output messages every 10 msecs and request input messages every 4 seconds. Both messages are independent and cyclic. That’s why the term Cyclic I/O makes so much more sense: it actually provides information to the reader. Class 1 doesn’t.

Class 3, on the other hand, is for those message/response type messages. CIP supports a set of function codes that a Scanner can request from an Adapter. An Adapter must support function codes to read and write attributes, for example. It can also support functions to execute vendor specific functions. A vendor could implement functions to start a recipe, soft reset a device, or execute a self-cleaning sequence. These kinds of messages require a response from the Adapter. The EtherNet/IP and DeviceNet specifications call these kinds of messages Class 3 messages, but I prefer the term acyclic messaging. I find that more descriptive.

Other protocols have the same kind of functionality but don’t seem to mess it up with non-descriptive terms. Modbus has message/response type functionality. In fact, that is all it has, so Modbus messaging doesn’t have the confusion. ProfiNet IO has both cyclic and acyclic messaging and calls it that. Usually the Germans are more complex than us, but in this case, they are using the terms that make the most sense.

And that ends my rant on the terms Class 1 and Class 3. You can continue to count on me to be the Don Quixote of the automation world fighting the windmills of complexity wherever I find them. My gas powered flashlight and I will be there shining the light on complexity wherever I find it.