Cash Drawer Kick: the ESC/POS Command

A cash drawer doesn't open on its own — the receipt printer opens it. The drawer plugs into the printer's RJ12 socket (usually labeled "DK" for drawer kick), and the POS sends the printer a five-byte ESC/POS command (ESC/POS is the byte language receipt printers speak) — ESC p m t1 t2, typically 1B 70 00 19 FA — that fires a short electrical pulse down that cable to release the drawer's latch. If your drawer won't open, the fault is in that chain: the command, the printer, the cable, or the drawer. This guide covers the exact bytes, the troubleshooting flow, and a measured case study of the strangest failure mode of all — a kick that fires correctly, 9 to 24 seconds late.

Why the drawer plugs into the printer

Cash drawers are electrically dumb: inside is a spring-loaded latch held by a solenoid (an electromagnet). Energize the solenoid for a fraction of a second and the latch releases — that's the entire interface. Rather than give every drawer its own network connection, POS hardware standardized on borrowing the printer's: receipt printers carry a drawer-kick port (an RJ12 socket that looks like a slightly wider phone jack, often labeled DK), and a dedicated kick cable runs from there to the drawer.

This has a practical consequence worth knowing before any troubleshooting: no working printer, no opening drawer. If the printer is off, offline, or erroring, drawer commands go nowhere.

The command: ESC p m t1 t2

The ESC/POS command "generate pulse" is five bytes:

The near-universal default is:

1B 70 00 19 FA

That's m = 0 (pin 2, the first drawer), t1 = 0x19 (25 × 2 = 50 ms on), t2 = 0xFA (250 × 2 = 500 ms off). Fifty milliseconds of current is enough for virtually every solenoid; the off-time mostly matters as a spacing guard if you fire twice.

Sending it from code is one raw write. To a network printer on port 9100:

import net from "node:net";
 
const KICK = Buffer.from([0x1b, 0x70, 0x00, 0x19, 0xfa]);
const sock = net.createConnection(9100, "192.168.1.240", () => {
  sock.end(KICK);
});

Two variants you'll meet in the wild:

• DLE DC4 fn=1 (10 14 01 m t) is the "real-time" cousin — some printers process it even mid-job. Support varies; ESC p is the portable choice.
• "Open drawer before/after printing" checkboxes in POS software just prepend or append these same bytes to the receipt job.

Pins and pulses, briefly

The RJ12 connector carries six pins: pin 2 and pin 5 are the two kick signals (that's what m selects), pin 4 carries the drive voltage (usually 24 V from the printer's own supply), and pin 3 can carry a drawer open/closed switch signal back to the printer — more on that below. Two-drawer setups (rare outside banks and some bars) use a splitter or a dual-drawer cable, with one drawer on pin 2 and the other on pin 5.

If a drawer clicks but doesn't pop open, the solenoid is firing but the pulse may be too short for that drawer's mechanism, or the drawer is physically jammed (overstuffed bill slot is the classic). Try a longer pulse — t1 = 0x32 gives 100 ms:

1B 70 00 32 FA

Troubleshooting: drawer won't open

Work down this list in order; each step isolates one link in the chain.

1. Does the drawer open with the key? Turn the manual key/release. If it won't open even manually, the drawer is jammed or broken — no command will fix it.
2. Is the printer online? Print a test receipt from the POS. If the receipt doesn't print, fix the printer first (paper, cover, power, network — see our kitchen printer setup guide for the network side). The drawer command rides through the printer.
3. Check the cable and ports. Kick cable firmly seated in the printer's DK jack (not the network jack, not a phone-line jack) and in the drawer's printer port (not the daisy-chain port)? Kick cables are not ordinary phone cables — the wiring differs by drawer brand, so use the cable that came with the drawer or a replacement specified for that drawer/printer pairing.
4. Try the other pin. If the software fires m = 0 (pin 2) and nothing happens, try m = 1 (1B 70 01 19 FA). Some cables and drawers wire the kick line to pin 5 instead. POS settings often expose this as "drawer 1 / drawer 2."
5. Lengthen the pulse. Solenoid clicks but no pop: raise t1 from 19 to 32 (50 → 100 ms) as shown above.
6. Swap components to isolate. Another kick cable, then another drawer, then another printer if available. In practice the cable is the culprit far more often than the drawer.
7. Confirm the software sends the command at all. Many POS systems only kick the drawer on cash-tender transactions, not card payments — by design. Check for a "no sale" / "open drawer" button and the drawer-kick settings before assuming hardware failure.

A worked example: the drawer that opened 9 seconds late

There's a failure mode the checklist above can't catch, because nothing in the chain is broken: the kick fires every time — just late. We hit it ourselves on the Proxy Nodes bench, and it's worth walking through because the debugging method transfers to any networked kick path.

The symptom: a drawer-kick request that should feel instant took anywhere from 9 to 24 seconds. Not failing, not intermittent — reliably slow, with the delay landing at oddly consistent values. Every instinct points at the pulse: maybe t1 is wrong, maybe the solenoid is weak. But pulse parameters decide whether the drawer opens, not when. The 50 ms pulse was fine.

The productive move is to split the path and time each segment. A networked drawer kick has two phases: establish the TCP connection, then write five bytes. Timing them separately showed the write completing in single-digit milliseconds — once the connection existed. All of the 9–24 seconds lived in the TCP connect.

That pattern has a fingerprint. When a device's Wi-Fi radio is in power-save mode, it sleeps between access-point beacons and can miss packets sent to it — including the SYN packet that opens a TCP connection. The client's operating system doesn't give up; it retransmits the SYN on an exponential backoff (roughly 1 s, then 2 s, then 4 s, then 8 s...). So the connect succeeds eventually, on whichever retry catches the radio awake — and the observed latency quantizes near the retry marks instead of varying smoothly. Delays that cluster at specific values are the tell that you're watching a retransmission schedule, not a slow wire.

The fix was firmware, not hardware: firmware 1.0.9 disabled Wi-Fi power save on the node, and the measured request-to-pulse time dropped from 9–24 s to 0.15 s. The lesson generalizes: when a networked peripheral "works but is slow," measure the connection setup before touching the payload. The bytes are almost never the slow part.

Checking drawer status with DLE EOT

ESC/POS can also ask whether the drawer is open. The real-time status command DLE EOT n with n = 1 requests printer status:

10 04 01

The printer replies with one status byte; bit 2 reflects the level on drawer-kick pin 3, which — when the drawer has a status switch wired to that pin — tells you open versus closed.

The honest caveat: many setups can't actually report drawer state. Plenty of cash drawers don't wire a status switch to pin 3 at all, plenty of kick cables don't carry the pin, and even when both do, whether "high" means open or closed varies by drawer. The printer dutifully reports a pin level either way, which is how you get systems confidently displaying "drawer closed" while the till sits wide open. If drawer-open alerts matter to your operation, test the reading with your exact drawer, cable, and printer — and treat an unverifiable reading as unknown, not closed. (Byte-level detail on all four status queries lives in our DLE EOT status guide.)

One HTTP request instead of a raw socket

This is why drawer support in Proxy Nodes works the way it does. A node sits in front of the printer and serves a plain HTTP endpoint on your local network, so opening the drawer is one request instead of a raw-byte socket write:

curl -X POST http://proxynodes-a1b2.local/drawer/kick

That endpoint ships in firmware 1.0.24, and the whole path is measured: 0.15 s from request to kick pulse. The status side is deliberately honest — when drawer state genuinely can't be verified through the hardware (no switch, no pin 3 in the cable), the driver layer models the reading as unknown rather than guessing, so your UI can say "can't tell" instead of showing a green checkmark over an open till. And the node accepts the classic raw bytes on port :9100 — ESC p, DLE EOT, the lot — so existing POS software needs zero changes. Developers can exercise the entire flow, drawer kick included, against the free digital twin before any hardware is involved; the same 123 conformance specs run against the twin and a real node.

Quick reference

For the rest of the command set, see the ESC/POS command reference. Operators wiring up a full station will also want the kitchen printer setup guide and the hub pages for restaurants and developers.

FAQ