Published:
A warehouse prints a pallet label and it comes out at the returns desk. Nobody's code changed. This failure feels random, but it is not — it is an identity problem. Almost every printing stack identifies a printer by something that is allowed to change: a queue name, an IP address, a Windows share. When that identity drifts, jobs follow the identity, not the machine.
Printers get leases like laptops do. The printer you installed at 192.168.1.50 reboots after a power cut and comes back at .73; some other device picks up .50. Every job addressed to .50 now prints somewhere else — and port 9100 accepts it silently, because raw printing has no handshake that asks "are you the printer I think you are?"
Windows and CUPS queues are a name-to-port mapping maintained by hand. Clone a workstation, restore a backup, or "helpfully" reinstall a driver, and PRINTER_A quietly maps to PRINTER_B's port. The application did everything right; the mapping lied.
Two sites, both with a queue called ZEBRA-DOCK. A laptop travels, connects to the wrong VPN profile, and prints five hundred shipping labels at the wrong site. Name-based identity has no concept of which ZEBRA-DOCK.
Notice what is not on this list: reprinting and hoping, or blaming the label file. The bytes are almost always correct — ZPL describes a label, never a destination — so a content-level check cannot find this fault. If you want to rule the file out first, a browser preview shows exactly what the bytes would produce; when the preview is right and the paper is wrong, the fault is in the addressing, not the layout.
Every mechanism above fails silently and intermittently: a lease has to expire and another device has to claim the address; an image has to be cloned and a name has to collide. Sites go years without it, then lose a shift of shipping labels at the wrong desk. The absence of the failure is luck compounding, not evidence of a safe design — which is exactly why the fix belongs in the addressing layer and not in a habit.
The layer-by-layer anatomy of why the stack makes this so easy is in printer identity: why queue names and IPs betray you.
Because the printer was addressed by something that is allowed to change: a DHCP lease, a queue-to-port mapping, or a shared queue name. When that identity drifts, the job follows the identity rather than the machine, and port 9100 accepts it without ever asking which device it is.
Print a test label carrying the target's own identity — its serial number or configuration label — from each queue, and compare it with the device you believe the queue points to. Repeat after every network change, not once.
No. ZPL describes a label, never a destination: there is no field that names the intended printer. If a browser preview shows the correct label and the paper is still wrong, the fault is in the addressing layer, not in the layout.
ZPL is the language Zebra thermal printers understand. How to read the commands, how a label is put together, and the most common mistakes.
Which barcode symbology should I use?EAN-13, Code 128 or QR? Practical rules for picking a barcode based on your data, your space and the scanner that has to read it.
How to preview a ZPL file without a printerA ZPL file is just text — the label only exists once something draws it. Three practical ways to see a ZPL label before it reaches the printer.