DeviceNet Assemblies Revisited

One of the hardest things to understand about DeviceNet is the concept of an assembly; what they are, how they are used and what the limitations are.

This is something that  I’ve explained over and over to lots of new users and I realize that it’ll never stop. There will always be people new to DeviceNet and I’ll have to go through this explanation again. So here it is:

You have to start with a DeviceNet Object (actually a CIP object) which is nothing more than a collection of related data. If you make a DeviceNet I/O device and have outputs, the state of each output, the power on state of each output, the communication failure state of each output and more would most likely all be grouped together in an Vendor Specific Object. You’d probably do the same with your discrete inputs. And if you had a series of temperatures you measured you’d group those temperatures in a Temperature Object.

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 Output. Each Output state, Temperature and Input state and everything else is an Attribute of an Object.

A special object in CIP is the Assembly object because it assembles data together. It kind of looks like this:

In this diagram the Assembly Object assembles that data from the Input Object to make the Input Assembly and distributes the data from the Output Assembly to the Output objects.

You can think of it as the train station for I/O messages coming to and leaving the device. The PLC or other DeviceNet 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 DeviceNet Scanner.

What’s interesting is that you can support multiple assemblies and let the user pick the one that makes sense in this application.

In the Robot and Drive projects that we’ve done we’ve created 2, 3 or sometimes as many as 10 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 this particular application.

One of the things we do in our DeviceNet gateways like the ASCII to DeviceNet gateway or the Modbus RTU device to DeviceNet Gateway or any of our other DeviceNet or CAN gateways is to let the user set the size of the assembly.

In DeviceNet, because it is on CAN, each message frame only support 8 bytes. The size of the data is critical to an efficient network. Having the user set the size needed for the application really helps optimize the system.