CIP Assemblies – Revisited

Every once in a while I use these pages to revisit the CIP Assembly. It’s really the most crucial aspect of a DeviceNet / EtherNet/IP / CompoNet / ControlNet object model. I’d venture to say other than the messaging modes, it is the number 1 key concept for CIP.


Object Models as we should all know are how CIP devices represent data. For those of us lucky enough (really?) to attend a Computer Science program it’s like old home week. At least in my day we heard all sorts of stuff about grouping data into some sort of object model. I don’t know (I could start every sentence that way) but I have heard that they don’t teach that sort of stuff in Comp Sci anymore. They just teach you to make applets for Iphones and crap like that. Suits me fine as it will keep my company in business for a long, long time if no one else knows how to write embedded software. But I digress (again).


Since I am digressing I just read a study that said women from the poorer parts of the world really like hunks – guys with that rugged masculine look. Women from more affluent places like the softer, gentler version, Man 2.0 I guess. (Drew tells me that studies say it based on birthconrol oil and the way the different hormones lvls affect choices) It was a blind study done over the Internet. I have more to say about that but back to our program…


Object models. CIP has its own way of representing data. It groups common data into objects. Every device has some identity data describing what it is; manufacturer, catalog number, description and so on. The Identify Object is part of the CIP Required Object set. There’s a number of these required objects; TCP Object, Router Object, DeviceNet Object and so on. Some of these are particular to one transport method (TCP Object implies CIP, DeviceNet Object implies DeviceNet) but all are required.


Application objects are optional. Most all devices have application data describing their real world I/O, things like Flow Rate and Flow Speed. These common data sets are also grouped into Objects. And if there are multiple of them, two sets of flows being monitored, you have Instances of that grouping; Instance 1 and Instance 2.


The data in these objects is referred to as attributes. Attributes have a name, a type, a value and other descriptors. The sum of all your Objects, Instances and Attributes is a CIP Object Model. And it’s the same for DeviceNet, EtherNet/IP and all the rest.


To facilitate the cyclic transfer of data, CIP has a special object, the Assembly Object. An assembly object has instances that are either Input instances (Target to Initiator) or Output Instances (Initiator to Target). That’s some of the formal language used in the spec but typically a PLC is the Initiator and a device is the Target.


The Input instances combine data from any number of application objects to form the data that is transferred to the Initiator. The Output instances describe how to divide the data that is received from the Initiator.


What many don’t understand is that you can have many Instances of the Assembly Object. You might have different Assembly Instances for different customer applications. Each Instance would support the particular data set that is important for that particular application.


For DeviceNet these choices are critical. DeviceNet cyclic data is limited to 8 bytes before the wildly unproductive and bandwidth hogging fragmented I/O messaging kicks in. Having different instances for different applications is very useful. With each different assembly instance supporting 8 bytes or less you can avoid paying the performance penalty for transferring data that isn’t important to this application.


Of course, that’s irrelevant for EtherNet/IP where you can have more than 400 bytes of EtherNet/IP cyclic data.


So there is my review of the Assembly Objects. Keep the cards and letters coming in. Until next time…