Beyond the hardware tree: structured tags and AOIs redefine PLC programming

While optimizing physical hardware architecture and isolating network traffic layout establishes a robust foundation for a production line, it only covers one side of the modern engineering equation. To truly unlock the productivity gains of integrated safety and dual-port networking, we have to look at how the software environment has evolved to manage them. Just as hardware connectivity has broken down data silos, a parallel revolution in programming efficiency has transformed how controllers talk to field devices.

Another boost to design and programming of packaging equipment is the focus by hardware vendors on creating add-on profiles and add-on instructions to support the integration of their devices into the programmable controller software suite. When fieldbus technology first came out, the template for communicating with the device was to pass blocks of data back and forth between controller and device.

A remote I/O rack, for example, was configured to be ¼ rack, ½ rack or full rack of data and associated input and output words of type integer were constantly exchanged back and forth. Even if the rack didn’t have a full complement of I/O modules, the data exchange was always the assigned block of input and output words. As one can imagine, the amount of memory used up for this type of communication was significant and limited how much remote devices could be assigned to a processor. An HMI was assigned in a similar manner—blocks of data constantly being sent back and forth, regardless of whether it was used or not.

Variable-frequency drives were handled in much the same way, except the standard data packet was one word of command bits, one word of command frequency, one word of status bits back from the drive and one word for the actual frequency, again, back from the drive.

For many years, regardless of the fieldbus protocol—remote I/O, DeviceNet, ControlNet, Profibus, Profinet—the exchange of bit/word level blocks of data was the common method of communicating with devices.

The movement away from memory-based tags—bits, bytes, words, INT, REAL—to structured tags has allowed for the data exchange to be specific to the data that needs to be exchanged rather than whole blocks of data. Complex tags can now be configured such that a combination of Boolean, integer, double-integer, counter, timer, real and other tag structures can be defined as a single structure. These individual tag types can have real names that are easily recognizable to the programmer and to the technician troubleshooting the equipment.

Get your subscription to Control Design’s daily newsletter.

With user-defined tags in mind, the vendors have created add-on profiles that automatically assign the data exchange tag structure to the PLC tags when the module is added to the hardware tree in the programming software. This format has allowed for much more than just the status/command, frequency and feedback words of yesterday. Now we have access to accel/decel values, specific performance curves and other details that would normally require a separate software application to access or by connecting directly to the device via a local human interface module or buttons on the device itself.

Similarly, hardware vendors or the OEM building a machine can make add-on instructions, similar to a function block, to make use of the user-defined tags to control device functionality.

Not all PLCs could create or use function blocks/add-on instructions, but now it is seemingly commonplace. This is one of the highest impact developments in the design of equipment as it standardizes control algorithms and makes it easier to add functionality to a basic block or create multi-use function blocks.

An example might be an add-on instruction to control a conveyor. It might start with just basic start/stop, speed and ramp parameters. Later, that same add-on instruction might be expanded to include features that are particular to a type of conveyor. There might be a photo-sensor upstream of the conveyor to wake it up from a sleep mode. There might be another photo-sensor downstream that, if left clear for a particular amount of time, would prompt the conveyor to go back into sleep mode.

The photo-sensor might have different functions based on the type of sensor. A retro-reflective photo-sensor, for example, would be on, unless an object blocks it while a diffuse photo-sensor would be off unless an object blocks it. All of this could be combined into a single add-on instruction and then use input parameters to turn off and on features for a particular application scenario.

All these features can be applied both at the machine level and at the line control level. Combined, they greatly reduce the time required to design the control system, as well as effort involved in developing the program to operate the equipment. Easing the effort involved in integrating the various unit ops into complete line operation are greatly enhanced with the integrated technologies those unit ops are designed with.