Nothing stands still in IT. Least of all printer manufacturers, and developers at Zebra Technologies have made great strides in the last couple of years to add functionality to their Zebra label printer line. These new capabilities make assured delivery and error tolerance much easier to implement. Let’s look at the features added in detail, explain why they are of use in output management, and how you can leverage them using VPSX software.
Zebra thermal printers have a small print buffer, and print “slowly” when compared to a laser printer. Before the recent enhancements, if large jobs were sent to a Zebra label printer, it would use standard TCP window reduction techniques to stop more data being sent than the printer could buffer. This means that for larger jobs, data from the EOM software took longer to get to a label printer than it would have with a laser printer. (This issue is not limited to Zebra label printers by the way; a typical Intermec label printer, SATO label printer, or other barcode label device faced the same challenge.)
From the VPSX perspective, to ensure that we have every byte of data in the print job, we must receive the final acknowledgement (“ACK”) from the printer. This confirms that the TCP connection has been closed both by the VPSX software and by the print device. A Zebra thermal printer does this ONLY when a print job has been correctly printed. If there is a Zebra printer support issue and the labels cannot print, the LRS software needs to be informed somehow. What’s more, if the issue occurs during printing and it is permanent, we will need to send the labels again. For non-permanent issues, we simply need to wait until we can send more data. This situation is usually handled by the TCP window. For permanent errors, again, relying on TCP, the printer should RESET the TCP connection, informing the EOM solution that the socket closed abnormally before the print could complete.
One other useful feature helps to prevent Zebra printer support issues: you can send a ZPL Host status command to the printer, and it should respond with its print engine status (e.g., “Ready,” “Hood Up,” “OFFLINE,” “Ribbon Out”). This is something we can check on BEFORE sending the print data.
To correctly handle such longer printing sessions, you would take the following steps when configuring the printer. First, you should specify ZPL (which incidentally stands for “Zebra Programming Language,” not Zebra Printer Label) in the VPSX printer definition. Next, TCP Keepalives should be turned on in the operating system, and TCP Missing Response should be set to a reasonable number of seconds. In addition, we need to check any interposing internal firewalls, since firewalls have a nasty habit of discarding half-close connections after a certain time, (half-close is what happens when VPSX has completed sending all the data and is just waiting for the final ACK from the printer). Firewalls will then silently discard any packets (from or to the printer) once they have discarded a half-close connection. So again, we need to have the firewall administrators adjust the time period after which the firewall will discard the connection. It must be less than our TCP MRD setting and it has to be agreed with the customer that after some specified minutes of hearing NOTHING from the printer we are allowed to assume it is broken.
Finally, as with all slow printers with a small buffer, if you are using a WAN IP Optimizer you will need to exclude the printer endpoint from the optimization. If you don’t do that, then the optimizer will be making TCP replies to optimize the WAN throughput and minimize the number of open connections. These optimizations will paint a false picture of the actual printer status and can lead us to assume that a job has printed correctly when in fact it has not. These are just a few things you need to think about during the Zebra printer troubleshooting process.
So, from a practical perspective, what does this give us? Well, to ensure a successful process, we will need to print everything in a print job. However, in this case (just like any other LPR or Socket based print protocol), we have no feedback apart from “it’s complete.” Although we can resend a job in the case of it not being printed, we cannot “checkpoint restart” that print on the right page as the printer has never told us which pages it has printed. Also, our reporting of errors, as seen on the printer display (and in our Web UI) is limited, as there is no status update.
Therefore, if you needed to be absolutely sure that all the labels had been printed once and only once no matter what, you would have to send each individual label as its own job. If you didn’t, then following a permanent print failure, the VPSX software has no choice but to send ALL the labels in the job again and your operator must identify and destroy the previous, incomplete print job.
New and Improved
As I said, nothing stands still in IT, and Zebra Technologies engineers have introduced two new features to their more modern Zebra label printer ranges ZT610 and ZT411. Firstly, they have added the SNMP MIB for printing and have correctly updated the host MIB with current error status and messages. This means that you can switch on the SNMP flag in the printer definition, and you will be sure to get up-to-date messages about the status of the device. Secondly, they added PJL Status feedback for page and device, which enables a two-way conversation with the printer as well as an application level Keepalive (no need for TCP Keepalives). It also provides status feedback for each label (page) that has been physically printed. To use those features, simply configure the printer to use a TCPIP/PJL connection with the SNMP flag on. Note that because the conversation never enters, “half-close” status, we also avoid a lot of the Firewall issues. That’s one less challenge to deal with.
So now we can reliably restart print jobs from the correct page if we need to, and we can reliably report on the status of the printer to VPSX. As a result, you can send hundreds of labels to the printer in one job, and if it breaks halfway through the job, a modern Zebra label printer will start printing again from the last page status it fed back to us. Because it uses true two-way communication (not just TCP flags), the TCP connection status will constantly be feeding information to VPSX about the state of the printer. What’s more, since it’s at the application level, the WAN Optimizer won’t interfere with things.
What are the real-world use cases for this type of Zebra printer support? We get new ones every day. Zebra label printers, Intermec label printers, and those from other vendors are heavily involved in shop floor production purposes and logistics. Nearly every manufacturer and/or shipping department uses them in critical business processes. Sadly, the operators don’t treat those printers very nicely, so we need to be at the top of our game to deliver the required results.
Case one: The Warehouse Label Printer person, whose job it is to print labels and refill the printer consumables, switches off the printer when he goes home for the evening. When he comes back, he expects the printer to start exactly where it left off. The printer is located in China.
Issue: China has its own compulsory, government-maintained firewall, over which no external party has control. As a result, the required firewall adjustments CANNOT be made.
Solution: To overcome these challenges, an international company could either have a Satellite VPSX instance on premise or in a China-based cloud. Alternatively, one could simply buy a PJL-capable Zebra printer.
Case two: A customer is printing labels on the production lines and notices that occasionally there are long delays before printing starts, causing some print jobs to be printed twice or not to completely print.
Solution: Carefully examine the packets generated by the printer at BOTH ends of the connection (the VPSX network interface and the Printer Port in the warehouse) and send the traces to LRS support. By reading the trace, LRS can tell that not only was the firewall discarding half-close connections, but the WAN Optimizer was answering TCP Keepalives as well as sending the final ACK even when the printer was in no condition to acknowledge the end of job.
My message for today is this: pay careful attention to slow, critical Zebra label printers, especially older ones without advanced features like SNMP and PJL. By carefully configuring these devices, you can achieve satisfactory results. Also, if you are refreshing your fleet, it would be wise to purchase printers with these SNMP and PJL functions. They will improve the results a great deal. When applied to business-critical printing, this will surely improve your bottom line.
Best Wishes from the Odenwald.