ControlLogix and Printing

The words, “ControlLogix” and “printing” aren’t often found together in the same sentence. For eons now, manufacturing applications have had to print labels, carton identification, product marking and much more. Programmable controllers, though, have not ever had good mechanisms to support printers.

In Windows, the printer manufacturers provide printer drivers that get loaded when you want to send data to a particular printer. The user doesn’t have to know anything about how to configure and send data to the printer.

Programmable Controllers like ControlLogix are a completely different world; a non-Windows environment where printing is one of the hardest things you can ask a programmable controller to do. Even though controls like ControlLogix have supported string data for the last 15 or 20 years, there just hasn’t been a good way to move those strings into a printer and drive the printer properly. It’s been a real headache for every programmable controller and printer manufacturer.

Printers, markers and labelers are generally pretty sophisticated devices, and the range of values they have to present is far more varied than what we are used to in a PLC. They can have lasers, sensors, motors and all sorts of mechanical and electrical components. They can have sophisticated application programs to manage and execute complicated jobs. Those jobs sometimes require sequenced data, custom data of various data types that has to be printed in very specific formats.

Challenge of Job Configuration

Printers, markers and the like don’t generally come with industrial application layer protocols like ProfiNet IO, EtherNet/IP and Modbus TCP. They begin life as IT devices for warehousing and other non-industrial uses, and then migrate onto the shop floor which has more challenges than in the non-factory environment.

First, every job has to be configured. On the factory floor it’s more critical to manage those jobs. Lots of questions to answer. Where are those jobs stored? How can we share jobs between manufacturing sites? Who has access to those jobs? Who can edit them? How can we secure them so that they aren’t lost, deleted or hacked? Should the job configuration be stored in the factory floor controller or not?

In most cases, the factory floor controller will be assigned to manage job execution. That means that the controller must somehow select jobs, configure those jobs with unique and sometimes sequential data and initiate execution of those jobs.

OT to IT connection problem
Doing all that has never been easy. It’s the old, OT (Operational Technology) to IT (Internet Technology) connection problem. Two devices from different cultures speaking different languages. And it’s further complicated by the fact that printers, markers and labelers often support proprietary protocols, protocols that aren’t easily supported by factory floor controllers.

And unfortunately, it’s not likely that this is going to get any better very soon. Even if new controllers begin supporting IT technologies, open information architectures like OPC UA, it will be many years before those controllers become prevalent on the factory floor.

What I’ve been recommending to clients in this area is to continue to use the printer, market or labeler’s custom tool to build and configure jobs. Those tools are the most efficient and straightforward way for a manufacturer to get the jobs built that they need for their application.

Once the jobs are built, a controller can then send the customized data and execution commands to the device to coordinate its operation with the operation of the manufacturing system. Here’s where it gets difficult and the printer, marker or labeler company has to make a choice. The choices are really just two:

1. Directly support an industrial application layer protocol like EtherNet/IP, ProfiNet IO or Modbus TCP.

2. Use a gateway to map the printer, marker, labeler’s custom protocol to a protocol supported by the controller.

Supporting a standard application layer protocol like EtherNet/IP, ProfiNet IO or Modbus TCP is a solution for some customers. Our company and others provide software to do that (see EtherNet/IP source code, ProfiNet IO source code or Modbus TCP source code).

The other option is to use a gateway (RTA supplies many different gateways) that can communicate with a controller over one of these application layer protocols and to the device. A gateway can be an inexpensive way to support many different industrial networks with no impact on the device’s operation.