Whether your role is IT or OT, there tends to be an almost universal dislike of having to work with printers. It is likely, for this exact reason, that when tasked with integrating a printer (be it a laser jet printer for labelling packaging, or a label printer to track your products) many users are simply forgoing the integration completely. That might mean opting for limited integration with a PLC on the line or simply choosing to not integrate at all while continuing to make any configuration changes manually.
In this blog post, continuing our OmniServer Did You Know series, we’ll discuss several methods that users have implemented over the years when needing to use printers in a process and how OmniServer provides an off-the-shelf, easy-to-use alternative for direct integration of most printers with your process control systems.
In an extreme case just recently, I was contacted by a long-time customer where the print formats had to be manually created with every product change-over adding anywhere from 30-60 minutes to the change-over process. In any industry where time is money and extra hour of downtime can cost thousands, if not hundreds of thousands, of dollars – automating the printer setup and interaction can make all the difference.
What Methods Are Available for Integrating Printers?
If we look at what options are out there to download data to a printer, we generally end up with something like the following list of traditional methods that have been used in the past to integrate with such printers:
Manually entering the print formats at the physical printerPros: I can’t really think of any (…gives you something to do if you’re bored?). Seriously, though, there really aren't any upsides to manual entry in a situation like this.
Cons: Requires an operator to stand at the physical printer, requires duplicate work if multiple printers are used since the same format must be manually created at each printer, and creates the opportunity for errors in the format design since all data and layouts are created by hand. Additionally, manual entry creates an artificial production bottleneck – since there are only so many labels any person would be able to configure in a given time.
Downloading print formats to the printer using vendor-specific software that came with the printerPros: Formats can be easily duplicated to multiple printers, the configuration can be done from anywhere on the network (i.e. it doesn’t require physically being by the printer), WYSIWYG interfaces that are often available can cut down on configuration mistakes, and formats might be savable and reusable (cutting down on duplicate work).
Cons: This method still requires a user to manually interact with each printer to download the new print formats and generally offers no way to integrate the software with any HMI/SCADA/Automation platform (while print formats can be saved, field values must all still be manually entered by user). Such software is almost impossible to customize (i.e. not flexible since it was designed for a specific purpose).
Connect the printer with a PLC and rely on the PLC to download the print formats to the printerPros: Formats can be easily duplicated to multiple printers, networking the PLC and printer would likely not be a big deal, and print jobs can be triggered from anywhere.
Cons: This method requires PLC programming experience. Modifying formats after they have been created would require modifying the PLC code – for which resources may or may not be available. There's also no real way to see the print formats for diagnosing any issues, or to see what the formats look like without printing them (i.e. no UI to see what is configured), and no way to see the messages the PLC is sending (not without some strategic Wireshark use).
This also puts additional load on the PLC and can use significant memory space given the size of most print formats and depending on how many formats are configured. And there's still potentially no direct way to interface with PLC from most HMIs to affect the print formats – even if such an interface is available it then requires the communication drivers, adding an additional ‘hop’ layer of abstraction between the HMI and Printer.
Custom develop a solution that can download the print formats to the printerPros: This method can be as flexible as desired since the developer would have full design control over the solution. And such a solution could be designed to communicate with multiple printers. Depending on the SCADA/HMI package, integrating a custom solution into an existing system might be as easy as using a toolkit to expose the desired communication interfaces (such as OPC).
Cons: Custom development is typically expensive, can take massive development efforts, and development and QA can be time and labor restrictive.
Also The user must then maintain the code base (what happens if the original developer(s) leave the company?). And some SCADA/HMI packages do not have readily available communication libraries that are easy to acquire – this would limit the types of systems the custom solution could be integrated with.
How Can I Integrate Printers More Efficiently?
All of the traditional solutions have a common thread - they're not very effective at giving your control system access to the printer and they're also not very efficient. By contrast, OmniServer provides an easily configured, easy-to-integrate, custom protocol server, that can be configured to do anything from triggering individual prints to downloading whole print formats to the printer. And OmniServer can interface with those printers without any manual user interaction and without using proprietary custom written software. (For new users, if you'd like an introduction to using OmniServer, please click here.)
OmniServer’s easy-to-use protocol builder allows for quick protocol creation in an off-the-shelf solution. The only thing needed would be the protocol documentation [for a tutorial on evaluating protocol documentation, click here] on how to format the messages to the printer.
OmniServer effectively provides the flexibility of a custom developed solution, without the need to write any code, or the need to manage the application code. As such, OmniServer greatly reduces (if not eliminates) the upkeep cost of the solution.
And OmniServer provides OPC DA, OPC UA, and Wonderware SuiteLink (amongst other) communication interfaces for HMIs, SCADA, Historian, and/or other client software to connect to and interface with the printer – allowing for easy integration into existing automation control systems.
We’ve had experience implementing protocols for such printers as Leibinger, Zebra, Domino, Matrix, VideoJet, and others. Curious if OmniServer might work for integrating your printers? Email us at firstname.lastname@example.org with your questions and we encourage you to subscribe to our blog for more helpful OmniServer tutorials and tips. And don't forget to download your free trial of OmniServer to start integrating your own printers.