Abort a serial barcode read when the scanner reads nothing

A barcode reader on an RS-232 line is quiet by design. It transmits only when it decodes a code, so a cycle that passes with no readable code leaves the line idle. If your read call waits for data with no time limit, the program sits inside that read forever: no error, no alarm, just a station that never advances. This guide shows how to give the read a finite timeout, branch on the timeout status, and abort or retry on purpose. The same pattern works on a robot controller serial port, a PLC ASCII port or a PC application, and it turns an unbounded hang into a worst case you can compute before the line ever runs.

Why the read never ends

Three different faults all look identical from the program's side: an idle line. The first is normal behavior. A decoder transmits data only after a decode, so when the optics see no code there is nothing to send. The second is configuration: some readers decode but stay silent on the serial interface until the data output is programmed, and reader troubleshooting tables list exactly this, alongside a loose interface cable, as the usual causes of a decode with no data arriving at the host. The third is electrical or setup: a baud rate, parity or handshaking mismatch, or a damaged cable, so bytes never arrive intact.

Against all three, a blocking read with no timeout has only one possible outcome. Many serial libraries make the infinite wait the default, expressed as a zero or negative timeout value, which is why the read always completes on the bench, where a code sits in front of the reader, and hangs on the line the first time a part arrives without one. If you fire the read trigger over the same port, check that side too: the guide to diagnosing a silent serial trigger covers a scanner that receives no command and therefore answers none.

What you need

• The reader's serial interface specification: connector pinout, baud rate, parity, stop bits, and the terminator the reader appends to each transmission.
• A cable with the correct pinout between reader and controller port. On readers that carry power, trigger I/O and data through one connector, an integrated loom such as the MV-IDA-PE-M12A17pF-openRJ45DB9-HF-5m breaks a single 17-pin connector out to open leads, RJ45 and a DB9 over 5 m of high-flex cable, with the GigE data on the same run.
• The documentation entry for your environment's read call: its timeout argument, its units in milliseconds or seconds, and the status or error value it returns when the window closes with no data.
• One known-good test code and one deliberate no-code scenario, so both branches get exercised on the bench.

The code reader cables range covers looms and breakouts; match the controller-side connector before you order.

Set a finite timeout and branch on the status

1. Find the timeout argument on the read call. Almost every serial read function takes one, in milliseconds or seconds, and a zero or negative value usually means wait forever. State the number explicitly rather than trusting the default.
2. Size the window. Start from 2 to 5 s: long enough to cover part detection, exposure, decode and transmission, short enough to abort inside a cycle. You will shrink it once decode times are logged.
3. Call the read and treat its two outcomes as first-class results: data, or the timeout status. The call now always returns within the window, which is the whole point of the change.
4. On the data branch, strip the framing before the string is used: prefix, suffix, CR/LF terminator and any padding bytes. Framing that survives into the buffer causes mismatches and races downstream; the guide on ASCII barcode data framing in the PLC receive buffer shows what arrives when terminator handling goes wrong.
5. On the timeout branch, run the abort path: set a fail output to the PLC, write a timestamped log entry, and end the cycle as a no-read. Never write an empty string into the variable a good read would fill.
6. If empty triggers are legitimate on your line, wrap steps 3 to 5 in a retry with a counter, two or three attempts, and run the abort path once the counter caps out.

Two attempts at a 2.5 s window cap the whole read block at 5.0 s; before the change, the same block had no upper bound at all.

Worked example: a 2.5 s window with two attempts on a robot load station

The case: a robot load station reads a code on each part before pickup, the read program previously waited forever, and the new requirement is that the read block can never exceed 5 s. The inputs:

• Window per attempt: 2.5 s, the middle of the 2 to 5 s starting range, set before any decode logging exists.
• Attempts: 2, so a skipped part gets one clean second chance.
• The read call returns at the window's end in both outcomes: data when a code arrives, the timeout status when it does not.

The rule in words: the read call adds no time beyond its own window, so the worst case for the whole block is attempts multiplied by window.

The arithmetic: both attempts timing out gives 2 × 2.5 s = 5.0 s. One attempt gives 1 × 2.5 s = 2.5 s. Worst case at the top of the starting range gives 2 × 5 s = 10 s.

Result: the read block is capped at 5.0 s, where it previously had no bound. The decision that follows: give the read block at least 5 s of station time and run two attempts; if the cycle allows the read less than 5 s, drop to one 2.5 s attempt and abort on the first timeout. After a shift of logging, shrink the window toward twice the slowest logged decode — a slowest decode of 600 ms sets the window to 1.2 s, and the two-attempt worst case falls to 2 × 1.2 s = 2.4 s.

What the abort path should do

A timeout is a defined, expected outcome, so the abort path should behave like a measurement rather than a crash. Set the fail output to the PLC first, before the program stops, so downstream logic sees a defined state on every cycle. Raise an alarm message that names the port and the window, so the screen shows no code in 2.5 s instead of a frozen program. Keep the part in place or divert it: a no-read is a reject like any other.

The receiving end matters as much as the reader side. If you are building the check station that must never pass a blank as a good read, the barcode match verification guide lays out the pass/fail logic that consumes exactly this signal. On a PLC serial port, the ASCII read instruction carries its own timeout and error bits, and the CompactLogix serial port ASCII read setup for barcode scanners walks the PLC side of the pairing, port settings through terminator handling.

Where the timeout lives on Ethernet and USB readers

The pattern is identical; only the call changes. A reader with a native Ethernet interface — most fixed code readers now have one — connects over a TCP socket, and the receive timeout set on that socket read branches on its status exactly as above. The guide to reading a barcode reader into a PLC over raw TCP sockets shows the connection end to end. The MV-ID3013PM-12M-WBN pairs a 1.3 MP sensor with a 12 mm focal length on Fast Ethernet, and the LS-CRD-0052 carries 1.2 MP at 12 mm over Ethernet with dual aviation plugs for power and trigger wiring; both run the trigger-and-timeout pattern unchanged.

USB splits into two behaviors, and only one accepts a read timeout. A reader that enumerates as a serial COM port behaves like RS-232 and takes the treatment above unchanged. A reader in HID keyboard mode delivers keystrokes only after a decode, so a read on that stream has nothing to time out; put the limit in your application instead, as an input wait that expires and raises the same abort path. Which mode a reader presents is settled in the reader's own configuration, so decide it before writing the receive loop: the guide on USB barcode scanners on a PLC HMI: HID keyboard mode or serial port covers the choice, and the companion piece on why serial still wins on a PLC USB port weighs the trade from the controller side.

For a compact fixed station at close range, the LS-CRD-0047 is specified at 1.2 MP on USB 2.0 with a 60-120 mm reading distance. In a manually loaded cell, handheld code readers present the same two modes over USB or Ethernet, and the receiving program needs the identical branch.

On a PC, the same argument exists in every serial library — in .NET it is the SerialPort.ReadTimeout property, expressed in milliseconds — and the walkthrough on reading a USB barcode scanner in C# with SerialPort and a POS API shows it in working code.

Verify it worked

• Good-code pass: read a known-good code and confirm the data branch fires well inside the window, with prefix, suffix and terminator already stripped.
• No-code pass: remove the code, trigger the read, and time the program to the abort branch. It should land at one window per attempt — two 2.5 s attempts abort at 5.0 s.
• PLC-side check: watch the fail output change on the no-code pass and stay unchanged on a good read.
• Speed check: repeat both passes at the fastest and slowest part presentation the line runs.
• The same one-wait-one-status discipline applies beyond serial: a frame that didn't arrive within its timeout applies it to camera frame waits.

Common mistakes

• Trusting the library default. Zero or negative timeout values mean wait forever in many libraries, and the hang returns the first time the bench habit of always having a code breaks.
• A window shorter than trigger to transmit. If good reads time out, the window does not cover detection, exposure and transmission; log decode times and widen to twice the slowest.
• Handshake and port mismatches. Baud, parity, stop bits or flow control that do not match the reader leave the line idle on every cycle, which the timeout branch dutifully reports as a no-read. Check the wiring and settings first: the RS-232 ASCII wiring guide for a PLC serial port covers pinout and framing, the guide on garbage characters from a barcode scanner covers link-level causes, and a port-setup walkthrough such as the D2-260 scanner port configuration for reliable RS-232 reads gives the settings table to work through.
• Empty string treated as data. Writing a blank into the variable a good read fills turns the failure into a downstream mismatch at a random later station; keep no-read and good-read in different variables so the abort path stays clear.

For the surrounding integration work — interface choice, PLC links, scan-to-output latency — the systems guides collect the topic, and the configurator below starts at cables and adapters, where the reader-to-controller link gets settled.

If you want the port settings and read logic checked against a specific controller before commissioning, the contact page reaches the applications team, and free expert support comes with every order.