POS peripherals not responding: receipt printers, scanners, and cash drawers

Troubleshooting · 9 min read

A peripheral dies at the till and the queue forms. The instinct is to blame the device and reach for a replacement. Resist it. In an LS Central setup the device is only the last link in a chain, and most "dead printer" calls are a cable, a stopped service, or a profile pointing at the wrong hardware. Work the chain in order and the fault names itself — usually within ten minutes, and without buying anything.

Start with the layer, not the device

Every keystroke and print job travels the same path. The POS talks to a hardware profile, which defines which devices — printers, scanners, EFT terminals, scales — are connected to that POS environment. The profile in turn points at LS Hardware Station, a Windows service for OPOS and other retail devices, which is what actually talks to the hardware. Hardware Station's supported device types include the cash drawer, printer, scanner, line display, MSR, scale, and EFT. Underneath all of that sit the plain physical facts: power, cables, paper, and the Windows/OPOS device layer.

That gives you five layers to test, cheapest first: physical (power, cable, paper, jams), Windows/OPOS (is the device installed and loaded), Hardware Station (is the service running and can it operate the device on its own), profile (does LS Central point at the device that Hardware Station loaded), and only then the device itself. Skipping ahead is how a store ends up with a new printer on a bad cable.

The diagnosis order

Run these steps in order for any unresponsive peripheral. Do not change two things at once — a fix you cannot attribute is a fault that comes back.

1. Power and the obvious. Confirm the device is plugged in and powered on, cables are seated at both ends, and the power strip or surge protector is switched on. Test a suspect outlet with another device. For a printer, check paper is loaded and there is no jam before anything else — empty or jammed paper is a documented first suspect for a printer that will not print.
2. Isolate the symptom. Note exactly what fails: one device or every peripheral on the till, one till or every till in the store. Everything dead on one till points at the shared layers (service, profile, PC). One device dead points lower. The same device dead on every till points at central configuration, not hardware.
3. Restart in order. Power down the peripheral and the terminal, wait at least 30 seconds, and bring them back up. A restart clears temporary communication glitches — but if it "fixes" the problem, still finish the checks below; you have a recurring fault, not a resolved one.
4. Check Hardware Station is alive. The Hardware Station service has to be running — after installation it is started manually, and anything that stops it (a reboot, an update, a service failure) silently takes every OPOS device with it. Open the Management Portal (localhost:8088 by default; the service itself listens on port 8082 by default) and confirm it connects. If you restarted the service, refresh the portal page to establish a new connection.
5. Check the device is loaded in the portal. No OPOS devices are loaded when Hardware Station first starts — they must be loaded with Load All Devices or the Load button for the device type. Once loaded, a device is loaded again at every service restart unless it was deleted or its Ignore Device flag is set. A device missing from the portal cannot respond to the POS, full stop. Note the trap: new devices cannot be installed through the portal. Hardware Station discovers devices that are properly installed; installation itself happens at the Windows/OPOS level first.
6. Test the device inside the portal. The Management Portal can perform basic operations directly, such as opening a cash drawer. If the drawer opens from the portal but not from the POS, the hardware, cable, and service are proven good in one step — the fault sits above, in the profile or the POS. That single test splits the problem in half.
7. Check the hardware profile in LS Central. Open Hardware Profiles, select the profile the terminal uses, and confirm the LS Hardware Station FastTab has Sync with LS Hardware Station selected and the correct host in the Hardware Station Host field (port 8082 is assumed if none is specified). Run Detect Hardware: devices loaded in the portal are added to the profile, each in its relevant FastTab. Two warnings from the LS documentation matter here: a device added manually to a FastTab is not guaranteed to be loaded in Hardware Station, and if the Web POS cannot connect, check that port 8082 is open on the Hardware Station machine's firewall. When the connection works, the Web POS shows a banner confirming it. Also confirm the terminal is actually using this profile — Hardware Profiles can be assigned on the POS Terminal card and on the Store card (for self-checkout, the connector card is checked first, then the terminal, then the store as fallback), so a correct profile on the wrong card changes nothing.
8. Swap-test, one variable at a time. Only now, with the upper layers proven, test the hardware itself. Move the suspect device to a known-good till, or connect a known-good device to the suspect till. Swap the cable separately from the device — a frayed cable and a dead device present identically. Where the fault lands after the swap is where the fault is.

Receipt printer not responding

Work the generic causes first: paper loaded, jam cleared, cover closed, and the correct driver — a wrong driver is a documented cause of a printer that sits silent. Then check which printer the setup thinks it has. Windows printers are added to Hardware Station in the Management Portal with Create Printer, which lists the available Windows printers to select and load; an OPOS printer must be installed at the OPOS level (OPOS software is installed when OPOS printers are used) and then loaded in the portal like any other device. Finally, confirm the printer appears in the hardware profile's printer FastTab after Detect Hardware — receipt printing follows the profile, which is how the POS knows which printer to use. A printer that prints from Windows but not from the POS is almost never a printer fault: it is the loading or profile step in between.

Scanner not responding

Scanners fail quietly. Start physical: reseat the cable, and clean the scan window — a dirty lens is a standard cause of missed and failed reads. Test with a different item and a known-good barcode; if one label fails and others read, the problem is the label, not the scanner. Check the scanner's mode/profile against what the POS expects — the generic guidance for a non-reading scanner is cable, scan mode, and lens, in that order. Then apply the LS layer: confirm the scanner is loaded in the Management Portal and present in the hardware profile after Detect Hardware. The decisive test is the swap: the same scanner on another terminal separates a device fault from a till fault in one move. (If scans arrive but post wrongly, that is a different problem — see posting troubleshooting.)

Cash drawer not opening

A drawer that will not open is three different faults wearing one symptom. Mechanical first: is the drawer fully closed, locked, or jammed? Use the manual release/eject latch to open it and clear anything obstructing the track. Electrical second: the interface cable can be loose, damaged, or simply the wrong type, and on printer-driven drawers the cable's orientation matters — the "To Printer" end belongs at the printer, the "To Drawer" end at the drawer. Configuration third: in LS Central the drawer is a Hardware Station device, so run the portal test — open the drawer from the Management Portal, which can perform that operation directly. If it opens there, the drawer, cable, and service are good, and the fault is the profile or the POS setup (including whether the setup opens the drawer as part of the receipt/transaction flow). If it does not open there either, swap the cable, then treat it as hardware.

Hardware fault or configuration fault?

What success looks like

The diagnosis is done when all of the following are true: the device responds from the POS in a live transaction, not just in a test — a receipt prints with the sale, a scan adds the item, the drawer opens on the tender that should open it; the device appears loaded in the Management Portal and in the hardware profile; the Web POS shows its connected banner for Hardware Station; and you can name the layer that was at fault and the single change that fixed it. If the last point is "it started working after we restarted things," the incident is not closed — write down when it happened, because the pattern across two or three incidents is what finally identifies the failing cable, service, or profile.

FAQ

Everything on the till stopped at once. Where do I look? At the shared layers first: Hardware Station service running, portal reachable, and the Web POS connection banner. Five devices do not fail together; one service stops alone.

The printer prints test pages but not receipts. The hardware and Windows layers are proven. Check the device is loaded in Hardware Station and present in the hardware profile the terminal actually uses.

When is it really the device? When the fault follows it: the device fails on a known-good till with a known-good cable, while a spare device works in its place. Anything short of that test is a guess. And if the till itself stops mid-sale rather than the peripherals, check the offline mode checklist next.