Barcode scanner to PLC response time: cut serial scan-to-flag latency

A scanned code can sit in the scanner's buffer for 120 ms before the PLC flag latches it, and the cylinder move that waits on that flag keeps missing its window on a fast internal transport. The delay is almost never the decode: it is the path — serial into a fieldbus bridge, a cyclic refresh into the master unit, then the controller's communications slice. This guide shows where each millisecond goes, ranks the likely causes in order of probability, and gives the fix with its arithmetic. Moving the scanner onto a serial port in the CPU rack and letting its read sequence loop continuously turns a measured 120 ms scan-to-flag time into roughly a third of that, without starving a 9.85 ms ladder scan. Substitute your own numbers in the worked example; the same budget tells you which input path your machine needs.

Where the scan-to-flag time goes

Between the scanner asserting buffer full and the ladder seeing the ready flag, four delays stack:

• t_line — the serial burst. 8N1 framing sends 10 bits per character, so a 20-character code is 200 bits: 20.8 ms at 9,600 baud, 5.2 ms at 38,400 baud, 1.7 ms at 115,200 baud.
• t_queue — the bridge buffer. A serial-to-fieldbus bridge holds the message until the network's cyclic slot comes round; on a bridged path this is the dominant term.
• t_refresh — the master unit copy. Network I/O reaches controller memory at the servicing boundary, not on arrival.
• t_service — the communications slice. The controller services its ports for a set slice of each cycle; a thin slice makes one burst wait several ladder scans.

Likely causes, in order of probability

1. A double-buffered bridge path. Scanner to RS-232, bridge to the fieldbus, master unit into controller memory: two queues and a cyclic refresh stack on top of the line time. Test: timestamp the scanner's buffer-full output and the PLC latch on a bench link straight into a serial port. If the gap collapses to tens of milliseconds, the bridge path is the cost. Fix: the local-port layout in the sections below.
2. A read sequence started once per code. On mid-range controllers, starting a protocol macro from the ladder costs about 40 ms before the first character moves. Test: check whether the port idles between reads while the ladder re-triggers it every cycle. Fix: let the sequence loop; silent serial trigger commands covers the handshake side.
3. A thin communications slice. With peripheral servicing at its default few milliseconds, a burst arriving mid-scan waits whole cycles. Test: raise the slice to 25 ms — entered as 250 on controllers that step in 0.1 ms — and re-time. A drop of 20-60 ms confirms it. Fix: hold the slice at the value that fits your fastest ladder reaction (next section).
4. Line settings and intercharacter delays. A 50 ms intercharacter delay stretches a 20-character burst from 20.8 ms to just over one second. Test: read the scanner's communication settings; any nonzero intercharacter or inter-message delay is throughput lost. Fix: 0 ms delay and the fastest baud both ends share. The factors that set serial response time — baud, frame length, poll interval — are the same across makes; this Modbus RTU slave response time walkthrough works them through.

Worked example: scan-to-flag budget for a 20-character code at 38,400 baud

Inputs, and where each comes from:

• 20 characters per code at 8N1 framing, 10 bits per character: a typical payload for this link type; substitute your own length.
• 38,400 baud on the new local serial leg, 9,600 baud on the old bridge leg: common defaults both ends support.
• 9.85 ms ladder scan: measured on the line in question.
• 25 ms peripheral servicing slice: the value set on that line, entered as 250 where the setting steps in 0.1 ms.
• About 40 ms to start a read sequence once from the ladder: measured on mid-range controllers in this class.
• 120 ms scan-to-flag through the bridge path: measured on the same line.

Rule in words: with the read sequence looping continuously on a local port, the flag reaches the ladder within one full cycle — ladder scan plus servicing slice — of the burst ending. A sequence started once per read adds its start overhead to every read.

Arithmetic:

• Line time, new link: 20 chars × 10 bits = 200 bits; 200 / 38,400 baud = 5.2 ms.
• Line time, old bridge leg: 200 / 9,600 baud = 20.8 ms.
• Cycle wait: 9.85 ms + 25 ms = 34.9 ms.
• Looping local port: 5.2 + 34.9 ≈ 40 ms worst case.
• One-shot local port: 40 + 5.2 + 34.9 ≈ 80 ms, on every read.
• Bridge path: 120 ms measured — consistent with the 20.8 ms serial leg plus two queues and a refresh on slower servicing.

Result: the looping figure against 120 ms. That is an 80 ms saving, with the code in the ladder in a third of the time.

Decision: if the machine needs the flag inside 60 ms, the looping local port clears it with room to spare; the one-shot variant at about 80 ms and the bridge path at 120 ms do not. Start the loop at power-up so the sequence-start cost never returns. If the budget were tighter than about 35 ms, no serial path clears it — move to the Ethernet or discrete rows in the table below.

Is a 25 ms servicing slice too much?

The slice is paid on every cycle, not per read. A 9.85 ms scan with a 25 ms slice repeats about every 34.9 ms, so ladder logic that ran each 10 ms now runs each 35 ms. For a mostly-network line whose fastest ladder reaction is tens of milliseconds, that trade is sound: the flag arrives 80 ms earlier and the ladder still beats it. If an interlock must react in about 10 ms, trim the slice to 5-10 ms — the cycle becomes 14.9-19.9 ms — and take the speed from the looping port instead; the loop, not the slice, is where the 80 ms came from. A timing-critical reaction can also move to a hardware interrupt input, which skips the servicing wait entirely; this high-speed counter interrupt latency calculation shows how that path's budget is built.

The fix: a looping read sequence on a local port

1. Move the serial link off the bridge onto a serial communications unit in the CPU rack — same cabinet as the controller, no network hop. The wiring and buffer handling are the same as when you read a barcode scanner into a PLC CPU module over serial.
2. Define the sequence once in the port's protocol tool: one step that requests the buffer, one that receives the code, writes the string and sets the ready flag. On PC-based soft controllers the same link is made over a serial port, as in this walkthrough that connects a barcode scanner to a soft controller over serial.
3. Point the sequence's last step back to its first so it loops continuously. The ladder only reads the flag and clears it; it never starts the port.
4. Set peripheral servicing to 25 ms (250 in 0.1 ms steps), then trim it per the section above.
5. Set the scanner to 0 ms intercharacter delay and to 38,400 baud, or the fastest speed both ends share.
6. Prove it: timestamp the scanner's ready output and the PLC flag latch across 50-100 reads. Expect a gap near the looping figure in the budget above, never much above 60 ms.

Which input path is fastest

The Ethernet figure is wire time plus stack plus scan: a full 1,500-byte frame is 12,000 bits, 0.12 ms at 100 Mbps, so the budget is software and one or two 9.85 ms scans. For a shared or remote reader, plan the link with the reader-to-PLC communication guide; the three input paths into a PLC maps what each path carries.

For the Ethernet row, the hardware bill is one network reader. The LS-CRD-0028 is rated at 60 codes/s over Fast Ethernet.

Where panel space is tight, the MV-ID813M-05S-WBN-SR gives the same GigE path in a compact M10-mount body.

Where the reader also drives a gate or a reject, the LS-CRD-0052 carries trigger and output wiring on dual aviation plugs.

When the path is not the problem

• Decode-limited line. If the read rate itself is the limit — damaged or low-contrast codes — no PLC change moves the flag. Fix contrast, exposure and optics first: recover decode rate on damaged, low-contrast codes, and check the reader's rate budget against line speed in choosing a reader and setup for high-speed conveyor reading.
• Ladder-limited motion. A faster flag exposes a slow cylinder move rather than fixing it; time the move separately before blaming the link.
• Flag needed before the string. Wire the reader's read-complete output to an input and start motion on its edge; the string arrives on the data path in parallel.

Keep it fast after the change

• Re-check the intercharacter delay after any scanner configuration or firmware change.
• Re-arm the sequence loop at power-up and after every communications error.
• Re-time after controller firmware updates: servicing defaults and refresh behaviour can move.
• Log flag-to-latch in production and alarm above 60 ms, so a drifting path is caught before the cylinder misses its window.

Pick the path from the table first, then the hardware: the code reader finder filters reader models by interface and read rate, and code reader accessories covers the trigger cables, connector boxes and light boards around the read. If the layout is unusual — a mixed network, a soft controller, a hard cycle budget — send the timing sketch through the contact page and we will budget it with you. The systems topic collects the rest of the line-integration guides.