Printer connection problems: what to do when labels will not print

Fixes for the errors you actually run into: No route to host, PRINTER_OFFLINE, a printer IP that changed, the same printer listed three times, "Out of ink" on a Mac, an update stuck on "Downloading update…", blank or garbled labels — starting with the one check that splits every problem in two: the Device Hub Test Print.

When labels will not print, the fault sits in one of three places: the path from the computer to the printer, the printer itself, or the system sending the job to the wrong printer entry. One check separates them: open Device Hub on the workstation, find the printer under Connected Devices, and click Test Print on its row. If the test label comes out, the computer-to-printer path and the printer are both fine — the problem is in which printer the app is using (see the last section). If Test Print fails, the error wording tells you which section below to read. Keep the exact error text: the keywords (for example "No route to host") are how you — and support — find the right fix fast.

1. "No route to host": the computer cannot reach the printer#

What you see: Test Print in Device Hub fails with a red message like "Test print failed: [PRINTER_OFFLINE] connect 10.10.200.138:9100 failed: No route to host". "No route to host" means exactly what it says: your computer has no network path to the printer’s address. The printer is fine — it has its own address (a network printer shows it on its screen, for example "ETH 10.10.200.138") — but the computer and the printer are on different networks. The usual causes: the printer’s network cable is plugged into a different router or switch than the one your computer uses, or the computer is on a guest Wi-Fi network, which typically blocks access to local devices.

1. Read the printer’s IP address on its own screen (the Ready screen shows it). Then read your computer’s IP address: Mac — System Settings → Wi-Fi → details of the connected network; Windows — Settings → Network & internet → Properties.
2. Compare the first three groups of numbers. Computer 192.168.1.20 and printer 10.10.200.138 are different networks — that is the whole problem. Same first three groups (for example both 10.10.200.x) means same network, and the cause is elsewhere.
3. Plug the printer’s network cable into the same router or switch your computer uses, and connect the computer to the main Wi-Fi, not the guest one. The printer’s screen will show a new address in your computer’s network range.
4. If the address changed, Device Hub still holds the old one: delete that network printer entry in Device Hub and add it again with the new address (the Setup Wizard walks you through it), then run Test Print again.

2. The printer’s IP changed: it worked yesterday, not today#

Most networks hand out addresses automatically (this is called DHCP). After a restart or a power cut, the printer can come back with a different address, while Device Hub keeps trying the old one — same symptom as section 1, but nothing was re-plugged. Compare the address on the printer’s screen with the address stored in Device Hub: if they differ, that is the whole story. To stop it happening again, reserve the address for the printer in your router (address reservation, tied to the printer), or set a fixed (static) address in the printer’s own network settings — then update the entry in Device Hub once, and it stays put.

3. PRINTER_OFFLINE: check the printer itself first#

When a job fails with PRINTER_OFFLINE, do not start by changing computer settings — walk to the printer and read its screen. Most "offline" reports are the printer asking for something:

• Out of labels or ribbon — load a new roll (and run a Calibration from the printer’s screen menu after changing rolls, so it learns the new label gap).
• Cover not fully closed — press the top cover down until it latches on both sides.
• Paused — many printers pause after an error or a button press; bring it back to Ready from its screen or buttons.
• For a network printer, also check the cable: seated at both ends, and the switch port light on. Then go back to Device Hub and click Test Print to confirm it recovered.

4. The same printer appears several times — and became the default printer#

What you see: the Mac or Windows printer list shows the same printer two or three times (names ending in " 2", " 3"), and one of them is set as the system default — so an ordinary document print lands on the label printer as a tiny label. This happens when the printer was added more than once, in different ways (by address, by discovery, after a driver reinstall). The duplicates are not harmless: apps pick entries you did not intend, and jobs seem to vanish.

1. Delete the duplicates in the system printer settings (Mac: System Settings → Printers & Scanners; Windows: Settings → Bluetooth & devices → Printers & scanners). Removing the system entries does not affect Device Hub: the Hub’s network printer (shown as "Network printer 10.10.200.138 · 9100") talks to the printer directly and does not go through the system list.
2. Set the system default printer back to a regular office printer, so everyday documents stop landing on the label printer.
3. In Device Hub, check the printer’s class: label printers belong under Label Printer, office printers under Regular Printer. Each row has a button to switch class (for example "Change to Label Printer") — labels can only go to a Label Printer, never to a regular one.

5. "Out of ink" on a Mac: a false alarm#

Thermal and thermal-transfer label printers have no ink cartridges at all — they print by heating a print head. macOS cannot read this kind of printer’s status properly, so it may report "Out of ink" (and mark the printer with a red dot) when everything is fine. Ignore it: the printer’s own screen is the source of truth. If it truly runs out of labels or ribbon, the printer says so on its own display, in plain words.

6. Labels come out blank, garbled, or the wrong size#

The job reaches the printer, but what comes out is wrong. Check these four things, in this order:

1. The right entry: print through the network entry in Device Hub (the one that shows the IP address and port 9100) — it sends the label data to the printer as-is. An entry that goes through the operating system’s printer driver can rescale or re-encode the job on the way, which is how labels come out shrunk, shifted or not at all.
2. The printer language: Docklify shipping labels are ZPL printer code. The printer must be working in ZPL mode (many industrial printers also speak their own language, such as TSPL, and offer ZPL emulation — if yours is set to its native language only, ZPL comes out as blank pages or lines of raw text). Switch the emulation in the printer’s settings if needed; before printing, you can preview what the ZPL should look like in Utilities → ZPL Viewer (/utilities/zpl-viewer) to separate a data problem from a printer problem.
3. The size: the label size in the template must match the label stock loaded in the printer — a 4×6 shipping label template on 4×3 stock will be cut off or shrunk. Change the size where the label is created (label template), not at the printer.
4. Calibration after a roll change: if the print drifts, skips labels or stops between labels after you loaded a new roll, run Calibration from the printer’s screen menu — it re-measures the gap between labels.

7. Device Hub is "not ready", or its log fills with failed job pulls#

What you see: labels stop arriving even though the printer is fine, and the bottom of the Device Hub window — its Runtime Log — shows repeated errors about failing to pull jobs, or the cloud sync never reaches "ready". Two different things hide behind this. The common one: the workstation briefly lost its internet connection, the Hub logged a burst of errors, and later recovered by itself — old error lines stay in the log, so it looks broken long after it healed. The real one: the Hub genuinely cannot reach the cloud right now, or it lost its pairing, so jobs from the web app never reach this computer. The log tells them apart: every line carries a timestamp.

1. Read the newest lines first. If the errors are old (an hour ago, last night) and the newest lines show the sync completing successfully — the log itself is written in Chinese, so judge by the timestamps and the newest entries rather than by searching for English words — it already recovered; there is nothing to fix.
2. Check the pairing state in the Hub window. If it shows not paired, pair again: read the Hub’s 6-digit pairing code and enter it on the web side — in the pairing dialog that appears when you print, or in SaaS → Admin → Print Devices, where Hub pairing is managed.
3. Restart the Hub: fully quit Device Hub and reopen it. On startup it re-registers, re-syncs the device registry and reconnects the cloud sync — then confirm in the log that fresh lines show sync completing, and run a Test Print.
4. Still failing? Check this computer’s internet first (open any web page). If the web works but the Hub log keeps growing new errors, click Copy Log in the Hub window and send the log to support, noting roughly when it started — the timestamps do the rest.

8. An update sits on "Downloading update…" and the bar never moves#

What you see: Device Hub offers a new version, a progress bar starts under "Downloading update…", and then nothing moves for a very long time; the window may also say a print job is in progress and that the update was postponed. Nothing is actually stuck. The Hub will not install an update while printing is active — a single Test Print counts as printing. If it detects print activity when the install is about to start, it quietly cancels that attempt and postpones the update (you get reminded again later, typically in an hour), and in older versions the window could keep showing the download as if it were still going, which made it look stuck.

1. Fully quit Device Hub and reopen it — really quit the app (on a Mac, Quit from its menu; on Windows, Exit from the tray icon), not just close the window. That clears the leftover "downloading / print in progress" state.
2. After reopening, click Update now and let it finish in one go: it downloads, installs and restarts by itself. The version number changing is the proof it landed.
3. During those few minutes, do not click Test Print and do not print labels from the packing station — any print activity makes the installer postpone again.

9. Test Print works, but the packing station prints nothing#

A successful Test Print proves the computer-to-printer path and the printer itself are fine. So when the Packing Station (SaaS → WMS → Packing Station) seems to print but no label comes out, the job went somewhere else. In Docklify, which printer a label job goes to is decided at two levels. First comes this workstation’s own Hub default: the printer marked as the default label printer in Device Hub → Connected Devices on this computer — it wins. Only if this Hub has no default of its own does the warehouse default apply: the printer flagged for this warehouse in SaaS → Admin → Print Devices. If that warehouse-default printer belongs to another workstation’s Hub, the job is sent to it through the cloud relay, and that computer’s Device Hub must be running — if it is not, the job cannot be delivered at all. And if neither level has a default set, printing does not pick a printer for you: a printer picker pops up and lets you choose, and while choosing you can also save that printer as this workstation’s Hub default.

1. First check this workstation’s Hub default: open Device Hub → Connected Devices on the packing-station computer and see which printer’s row carries the default label printer mark. If the wrong printer is marked — or the right one is not marked at all — use “Set as default label printer” on the correct printer’s row. This Hub default is checked first, so fix it here before changing anything else.
2. Then check the warehouse default: open SaaS → Admin → Print Devices and see which printer is flagged as the default label printer for this warehouse, and whether it shows online. If the flag is on the wrong printer, move it to the right one. Remember that this warehouse default only takes effect when the local Hub has no default of its own — and if the flagged printer belongs to another workstation’s Hub, jobs reach it through the cloud relay, so that computer’s Hub has to be running.
3. If the right printer shows offline, go to its computer and start Device Hub there — without the Hub running on that machine, no job can reach the printer.
4. Also confirm the printer’s class in Device Hub on that computer: it must sit under Label Printer, not Regular Printer (switch it with the "Change to Label Printer" button on its row).
5. Print again from the Packing Station and watch that printer. If labels now come out there, the setup is right — the earlier jobs were simply delivered to wherever the default pointed at the time.

10. Carrier labels, pairing prompts, and carrier refusals at the packing station#

When an order names a carrier such as UPS or FedEx, the Packing Station buys the label from that carrier and it prints straight to your label printer, like any other label. If the carrier returns the label as an image instead, the label opens in a new browser tab and the print dialog appears on its own — print it from that dialog. The message at the station tells you which of the two happened: it only says “printed” when the label really went to a printer, and it says the label opened in a new tab when you still need to print it there. Reprinting a label always reprints the same one; it never buys a second label.

If this computer’s Device Hub is running but this browser has not been paired with it, labels no longer stop at the pairing prompt: when the warehouse has a cloud printer available, the label is sent there automatically and prints anyway. You only need to type the 6-digit pairing code when no cloud printer is available. If you close the pairing box without pairing, the station says the label has not printed yet — finish the pairing, or use Reprint on the package when you are ready.

And when a carrier refuses to create a label, the station now explains in plain words what went wrong and what to do next — for example, check the order’s address, the carrier account, or the service you picked — instead of a generic “something went wrong”. The refused attempt is also listed under Exceptions as a blocked label: fix the cause, then buy the label again from there. The station never quietly prints a local label in place of a carrier label the carrier refused.

11. On the phone, My Printers is missing printers — or shows one as offline while the office screen says online#

What you see: on the phone (Mobile → WMS → More → My Printers) the list is much shorter than the printers your warehouse actually prints to — or a printer there is tagged Offline while a colleague checking SaaS → Admin → Print Devices sees the same printer Online. Both are display rules, not printer faults. My Printers lists the printers of the warehouse you have selected on the phone, plus any org printers an admin has not assigned to a warehouse yet — those appear in their own group marked “Not assigned to a warehouse yet”. If the phone is set to a different warehouse than the one you are standing in, the list follows the phone’s warehouse, so check the selected warehouse first. And “offline” on either screen simply means the system has not heard from that printer’s Device Hub for over two minutes — the Hub app on the printer’s computer is closed, asleep or off the network.

1. Check the warehouse selected on the phone first. My Printers follows the phone’s current warehouse — switch to the warehouse you are in and reopen the page.
2. Look in the “Not assigned to a warehouse yet” group before concluding a printer is missing. Printers in that group are fully usable — printing can already reach them (one of them may even be your org default). You can also pick one there as your personal default.
3. If a printer should belong to a warehouse permanently, an admin assigns it once in SaaS → Admin → Print Devices (the page has a filter and a banner counting unassigned printers). After that it moves into that warehouse’s group everywhere.
4. If a printer shows offline, go to the computer that printer is connected to and open Device Hub there, then reopen My Printers — once the Hub reports in again, the tag clears within a couple of minutes. It is the same check an admin sees under Print Devices, so both screens agree.

Docklify features used in this article#

• Test Print for any connected printer — Device Hub → Connected Devices
• Add a network printer and the first-run setup walkthrough — Device Hub → Setup Wizard
• Switch a printer between Label Printer and Regular Printer — Device Hub → Connected Devices → Change to Label / Regular Printer
• Warehouse default label printer, device online status and Hub pairing — SaaS → Admin → Print Devices; the Hub-level default, which each workstation uses first, is set on the printer’s row in Device Hub → Connected Devices
• Runtime Log and Copy Log for support — Device Hub → Runtime Log
• Preview what a ZPL label should look like before printing — SaaS → Utilities → ZPL Viewer (/utilities/zpl-viewer)
• Label printing at the packing bench — SaaS → WMS → Packing Station