Barcode scanner not sending data to your HMI: fix the serial link

A barcode reader that beeps while the register on the panel stays empty is a configuration problem far more often than a hardware failure. The beep certifies the optics and the decoder; the serial port, the cable, the panel's scanner driver and the commit step are where the data dies. This guide walks the checks in the order that finds the fault fastest: the five serial settings, the crossed TX and RX wiring, the trigger and output profile, the string timing on a 9600 baud link, and the choice between wiring the reader to the panel or straight to the PLC. It ends with a layer-by-layer test that names the guilty layer. Work through it once with a laptop, a USB-to-serial adapter and a null modem plug, and the register updates within the hour in most cases.

Why does the reader beep but the PLC register stay empty?

The beep certifies the decode — it says nothing about what happens after. The likely causes in order are swapped TX and RX wiring, a disabled or wrong-protocol panel serial driver, a baud or framing mismatch, and an output profile pointed away from the cable.

Rank the suspects and test them in this order:

Two boundary notes keep you out of the wrong half of the cabinet. A reader that never beeps has a fault upstream of the serial link: distance, illumination and code quality own that symptom, and no baud rate fixes it. And with the panel in the middle, the PLC program needs no scanner setup at all — the panel reads the port and writes the register, so an empty register indicts the panel's serial configuration, not the ladder.

Which serial settings must match at both ends of the cable?

Match five values at both ends — 9600 baud, 8 data bits, no parity, 1 stop bit and no handshake. 9600 8N1 with flow control off is the default combination on most industrial readers and most panel scanner drivers, and any change must land on both ends at once.

Set the same five values in the reader's interface menu and in the panel's serial driver:

• Baud rate 9600 — the clock both ends agree on; a mismatch garbles or silences the link.
• Data bits 8, parity none, stop bits 1 — the frame each character travels in; a mismatch drops or doubles characters mid-string.
• Handshake none — a port configured for RTS/CTS while the cable carries no handshake wires waits forever and reports nothing.

A baud mismatch has a readable signature: every character wrong points at speed, while a clean start followed by debris points at framing — the garbage characters fix shows how to tell the two apart. Many panels ship a dedicated scanner device driver that wraps these five settings plus the register mapping; a generic free-port driver exposes the same fields raw, so the values above apply either way. If you raise the speed for longer codes, change both ends in the same sitting — a half-updated pair reads exactly like a broken one.

Does the cable need a null modem, and do the voltage levels match?

One end's transmit must land on the other end's receive: cross pins 2 and 3 and keep pin 5 as ground when both devices present a DTE-style port. Never feed a 0–5 V TTL output into an RS-232 port that swings between −3 and −15 V.

On a DE-9 connector, pin 2 is receive, pin 3 transmit and pin 5 ground for a DTE-style device, and most readers and panels present that same pinout, so the cable crosses 2 and 3. The 30-second test is a null modem adapter: it swaps the two pins and usually jumpers the handshake lines as well. Where either end insists on handshaking, loop the requests at the passive side: RTS to CTS (pins 7 and 8), and DTR to DSR plus DCD (pins 4, 6 and 1). The handshake and wiring checks walk each pin and each loop.

Voltage family is the second half of the check. A true RS-232 port marks a logic 1 between −3 and −15 V and a logic 0 between +3 and +15 V; a board-level TTL UART swings 0 to 5 V, often 0 to 3.3 V. Signals from one family never cross the other family's receiver thresholds with the right polarity, so the port reads nothing or nonsense.

Is the reader waiting for a trigger command the HMI never sends?

Check the reader's output profile and trigger mode before blaming the cable: an output set to USB-HID over a serial cable transmits into thin air, and a reader left in host-trigger mode stays silent until the panel sends a start command on that same port.

Readers ship in one of three trigger modes, and the mode decides who starts each read:

• Free-run (continuous) — decode and transmit on every pass; the mode for fixed mounts over a moving line.
• Sensor trigger — a photoelectric sensor wired to the reader's input starts the read; one decode per part on fast lines.
• Host or serial trigger — the reader holds until a start command arrives on the same port; the mode for panel- or PLC-orchestrated reads.

The silent host command is a common enough failure to have its own diagnosis path: fixing silent serial trigger commands covers the exchange between host and reader, and the three trigger modes compared helps you pick the right mode per station. Set the mode and the data suffix on the same interface menu while you are there, then rescan — trigger and suffix changes cost nothing and explain a large share of empty-register calls.

How long does a scan take to arrive at 9600 baud?

At 9600 baud with 8N1 framing, a 22-character scan — a 20-character code plus CR and LF — needs 220 bit-times, and 220 / 9600 = 22.9 ms. Any receive timeout or handshake flag set shorter than about 25 ms will cut the message off mid-string.

Worked example, a Code 128 label with a 20-character payload plus a CR terminator: 22 characters × 10 bits = 220 bits, and 220 / 9600 bit/s = 0.0229 s, about 23 ms. Raise the speed and the same string lands in 11.5 ms at 19200, 5.7 ms at 38400 and 1.9 ms at 115200. A 40-character DataMatrix payload plus terminator is 41 characters × 10 = 410 bits, or 42.7 ms at 9600 — enough to overrun a handshake flag that resets after a single 20 ms cycle.

The decision: keep 9600 for codes up to about 30 characters on manually scanned stations; move both ends to 38400 or faster when payloads run longer or the read rate climbs, because 9600 carries 960 characters per second — roughly 43 twenty-two-character reads. When strings arrive sliced or the message boundary gets lost, the framing without headers fix restores clean boundaries on a raw serial driver.

Should the reader feed the HMI, or the PLC directly?

Keep the panel in the path when the register feeds displays, recipes or operator entry. Wire the reader to a PLC serial port or the plant network when the scan must gate machine logic, because the panel adds its own communication cycle to every scan-to-register trip.

Put numbers on the two paths. Through the panel, the scan spends its 23 ms on the wire and then waits for the panel's communication cycle to reach the register — budget at least one full panel update, commonly 100 ms and more, before the ladder sees the value. Wired into a spare PLC serial port, the same scan arrives in its 23 ms plus one PLC scan of a few milliseconds. A reject gate or diverter with a 100 ms window therefore wants the direct path; displays, recipe entry and operator logging are fine through the panel.

Map the options with the input methods compared, weigh Ethernet against serial and USB for cable runs, and plan buffers and retries with the communication planning guide. When every serial port is taken, reading the reader through the panel as a bridge beats daisy-chaining two devices onto one port.

When is USB or Ethernet the better link than RS-232?

Switch to USB when the panel has a USB host port and the run is under 5 m, and to Ethernet when the reader sits farther away or several stations share the data — both routes remove the null-modem, baud-matching and handshake faults entirely.

USB HID puts the reader on the panel as a keyboard: no baud, no null modem, no handshake — the scan lands in the focused input field and commits on the Enter suffix. Two traps to watch: the field must keep focus, and panels driven over remote sessions drop wedge input in ways the keyboard wedge and RDP failure explains, while the HID versus serial choice settles when keyboard mode beats a COM port.

Ethernet takes over past USB's cable limit or when several stations share the codes: Fast Ethernet readers sit on the plant network the panel already uses, and PoE models drop the separate power supply. Start from the code reader finder.

For an operator station, a wired USB handheld code reader plugs straight into the panel's USB host port.

For a scanner mounted away from the panel, a PoE Fast Ethernet handheld reader needs only one cable — it carries data and power.

At an unattended read point, the MV-ID3013PM-12M-WBN is a compact fixed code reader with a 12 mm lens on Fast Ethernet.

The fixed code readers page lists more Ethernet-mounted models for line-side reading, and the handheld code readers page covers operator-side scanning.

How do you prove the link works, layer by layer?

Test in layers, one guilty component per step: a laptop terminal proves the reader transmits, the same laptop on the far end of the cable proves the wiring, and a known 11-character test code proves the panel and the register write — three checks, one laptop, ten minutes.

1. Reader alone. Connect the reader to a laptop terminal through a USB-to-serial adapter at 9600 8N1 and scan a test label; the on-screen string must appear complete, suffix included. Nothing points at the trigger or output profile; debris points at baud or framing.
2. Cable. Move the laptop to the panel end of the installed cable; the same string must appear. If it appears with one cable orientation and not the other, the cable is straight-through and needs the null modem.
3. Panel driver. Enable the scanner or free-port driver with the five settings and open its receive monitor while scanning. The receive counter must tick before any register mapping matters — a counter stuck at zero indicts the driver or the port, not the mapping.
4. Register. Scan a fixed test code — ABC12345678 is 11 characters — and require all 11 in the register. If the string reaches an input field but never commits, add the Enter suffix or wire the field's commit as in commit tag data with Enter.
5. Worst case. Scan at the line's true pace and confirm no character loss at the set speed; the timing numbers above give the margin.

How do you keep the link alive through the next maintenance swap?

Write the five serial settings and the cable's pin crosses on the panel drawing, keep one jumpered null modem adapter and one loopback plug in the spare-parts tray, and retest with the 11-character code after every panel project update — replaced hardware defaults to factory serial settings, and factory settings seldom match yours.

• Panel drawing lists the five settings (9600 8N1, no handshake) and the reader's suffix, so the next driver build matches by copy rather than memory.
• Cable label states what the cable is — null modem, pins 2 and 3 crossed, handshake jumpered — because a mislabeled straight-through cable costs more hours than every baud setting combined.
• Spare tray holds one null modem adapter, one loopback plug and one known-good cable; small parts stop lines more often than readers do, and the code reader accessories page lists light boards, protective covers and I/O boxes and modules worth keeping on hand.
• Release test after any panel project or firmware update: scan the 11-character code and check the register before the line runs product.

More serial-link repairs, from framing to response-time tuning, sit on the code-reading topic page. If the register still refuses to update after these checks, start the system configurator to spec a reader with the interface your panel actually takes, or reach us through the contact page — free expert support comes with every order.