Making eight label printers stop locking up

The eight label printers locked up because their print servers take one connection at a time on the raw port, and every label resent the logo bitmap in full. We serialized jobs behind a per-printer lock, closed each connection cleanly and stored the logo in printer flash, recalled by a 24-byte instruction. The lock-ups stopped.

Printers wedged during bursts and stayed wedged until someone power-cycled them. On a receiving dock, that stops work.

There were two real causes and neither was hardware failure. These print servers accept one connection at a time on their raw port, and concurrent or half-closed connections leave them stuck. And every label carried the company logo inline — three and a half kilobytes of compressed bitmap describing a seventeen-kilobyte image — sent again, in full, on every single print. Both causes sit in the traffic, not the printer, and that is where label printer and print-queue work usually starts.

A transport layer that respects what the hardware can actually do. Jobs to the same device are serialized behind a per-printer lock. Connections are shut down in write direction before closing, so the printer sees a clean end-of-stream and frees its connection slot immediately rather than waiting out a network timeout. A short cooldown sits between jobs to the same device, and lock acquisition itself times out — a wedged printer fails fast instead of queueing work behind it forever.

Then the payload problem. The printers can store graphics in onboard flash and recall them by name, so the logo only needs to be sent once per device, ever. It is a small change with a large effect wherever ZPL and print-and-apply on the warehouse floor runs labels by the thousand.

• The logo is fingerprinted by content hash, so the same image gets the same name on every printer and across restarts
• The printer is asked whether it already holds that graphic, and the upload is verified before the label is rewritten to use it
• The inline image becomes a short recall instruction — twenty-four bytes in place of three and a half thousand
• Status queries read the reply before half-closing, because these print servers abandon a pending response the moment they see a close

Logo sent inline or recalled from flash

The interesting decision is what happens when the printer doesn't answer. There are three possible answers to 'do you already have this graphic' — yes, no, and no reply — and treating the third as a 'yes' would produce labels with a silently missing logo.

So the check is explicitly three-valued. No reply means the full image is sent inline, exactly as before. Any partial failure returns the original label untouched rather than a half-converted one. The optimization is allowed to not apply; it is never allowed to produce a wrong label.

A live status board polls every printer in parallel and reports paper out, head open, ribbon out, paused or offline — so the question 'is the printer broken or is it out of labels' has an answer on a screen.

The lock-ups stopped. Print volume that previously wedged the hardware runs through it, and when a printer genuinely does have a problem, the board says which one and what kind.

This is the pattern of most performance work we do: measuring where the time goes before changing anything. Nothing was rewritten and nothing was replaced — the fix came from reading the hardware's documentation carefully enough to find out what it had been trying to tell us. The office version of the same problem has its own guide: why an office network printer keeps going offline.