Barcode scanner input methods to a PLC: serial, USB and Ethernet

A code reader is only half a system. Until the decoded string and a valid-read flag arrive at the PLC, no divert fires, no reject strokes and no traceability record exists. Three input routes carry scan data into a controller: RS-232 serial, USB and Ethernet. They differ in what the PLC must already support, how far the cable runs, and how the good-read signal travels alongside the data. Each route below gets its transfer numbers, a realistic 24-byte read worked through the arithmetic, and a recommendation for the cases that come up most often.

Pick the route by one question

Ask what the controller already accepts, in this order.

1. A spare serial port with matching framing: choose RS-232. One scanner per port, plain ASCII into a buffer, a hard-wired good-read pulse, no protocol work at all.
2. Reader and PLC speak the same industrial protocol, EtherNet/IP being the common pairing on fixed code readers: connect straight over Ethernet, implicit messaging where the reader offers it.
3. Reader has plain Ethernet or RS-232, PLC speaks only its own protocol: put a gateway between them and map the string into input registers.
4. Scanner in hand is USB: it plugs into a USB host, which means a PC, a panel or a converter, never directly into the PLC CPU.

Whichever route you take, wire the good-read output to a discrete input and latch the string buffer on its rising edge. The PLC communication planning guide covers the rest of that link: buffer handling, handshakes and what to do when a read fails.

RS-232: point-to-point and predictable

RS-232 sends each read as ASCII bytes over three wires, transmit, receive and ground, usually on a DE-9 connector. Set both ends to the same framing: 8 data bits, no parity, 1 stop bit, and a baud both devices share. 9600 is the usual default and 115200 is common at the top end. One scanner per port, because RS-232 is strictly point-to-point; a second reader means a second port or a gateway.

The route's virtues are mechanical: no protocol to match, no address to set, and a string that lands in a buffer register you own. The RS-232 connection guide for embedded hosts shows the wiring and framing that make the first read arrive intact, and the prefix and suffix framing guide explains how a carriage return marks the end of the string in the buffer.

Reach is the limit: about 15 m at full rate is the classic figure, and longer runs work only at reduced baud, if at all. Serial-interface readers are still easy to find: the fixed code readers category lists 28 of them. For fast carton lines that still want the serial route, a high-resolution logistics reader keeps decode headroom while sending results over its serial link.

Worked example: how long one read holds the port

Each byte costs 10 bits at 8N1 framing: one start, eight data, one stop. A realistic logistics read is a 23-character GS1 string plus a carriage return, 24 bytes in all.

At 9600, one read holds the port for 25 ms. A line presenting a carton every 300 ms uses 25 / 300 ≈ 8% of the port, which is trivial headroom. At ten reads per second the same string at 9600 consumes 250 ms of every second and the route is saturated; at 115200 it consumes 21 ms, which still fits. So the rule: compute bytes × 10 / baud, keep it under roughly a third of your read period, and step up the baud or step to Ethernet when it crowds that line.

USB: a host problem, not a cable problem

A USB device needs a host that enumerates it and runs a driver stack. The USB socket on a PLC CPU exists for programming, logging and firmware work; it is not a host for a scanner. USB scan data therefore reaches the PLC in two moves.

Move one: the scanner plugs into a device that is a USB host, such as a PC or a panel built to take HID input, and that device forwards the string. The USB data capture guide shows the application side, and the HMI serial port guide covers the panel-to-controller hop. A handheld at a bench or check station lives here; the handheld scanner to a PLC without Ethernet guide compares its serial and USB cases.

Move two: a converter turns USB into a link the PLC already has, most often RS-232, and then the ordinary serial rules apply. Wiring a USB scanner output for PLC serial input walks the pin mapping. One trap: in keyboard-wedge mode the string arrives with no good-read flag, because a suffix only proves a key was pressed, not that the read was good. Put the reader into protocol mode if the PLC needs the flag.

USB 2.0 reach is about 5 m; beyond that, use an active extension or change the route.

Bench and check-station readers that end in USB: the LS-CRD-0047 fixed reader reads at 60-120 mm working distance over USB 2.0, and the LS-HCR-0001 handheld pairs a 1.0 MP sensor with the same USB 2.0 link.

Ethernet: direct only when the protocols match

Ethernet on a reader's spec sheet names the physical layer and nothing more. The PLC exchanges data over it only when both ends speak the same protocol. Fixed code readers commonly offer an industrial protocol such as EtherNet/IP, in two forms:

• Implicit messaging: reader and PLC open one connection, and the reader pushes its data assembly, string bytes, status word and read counter, at a fixed update period you set when the connection opens. Data age is at most one update period: set 50 ms, worst case 50 ms.
• Explicit messaging: the PLC pulls the data with a message instruction at its own poll interval. Poll every 50 ms and a fresh string waits 25 ms on average, 50 ms at worst.

Many PLC CPUs expose no raw TCP socket to the running logic, so a reader offering only plain TCP stops at a PC or at a gateway. For the register-by-register layout of an implicit connection, the implicit I/O assembly mapping guide walks a working map. Whichever mode you choose, keep the status word in the same assembly as the string, so the PLC judges freshness on data it already holds.

Reach is a non-issue in a plant: 100 m per Ethernet segment, and a switch extends it further. Two catalog examples: the LS-CRD-0052, a compact reader with an Ethernet interface and a 12 mm lens, and the MV-ID5120RM-08M-RBN, which reads over GigE at 12 MP through an M12 mount.

Gateways: the bridge when protocols differ

A gateway translates: serial or plain TCP on the scanner side, the PLC's protocol on the controller side. A serial-to-EtherNet/IP gateway maps the scanner's string buffer into input registers and exposes a status word; to the PLC it looks like any other EtherNet/IP device. The set-up is three values, buffer address, buffer length and status word, plus one mapping step in the PLC program.

The bridge adds a fixed transfer delay, typically a few milliseconds, which no carton line notices. It also solves the two-scanner problem: a gateway with multiple serial ports exposes each reader as its own register block, where a second RS-232 port would otherwise be needed. For the legacy case of an RS-232 scanner meeting an Ethernet-only controller, connecting an RS-232 scanner to a PLC over Ethernet covers the mapping end to end.

The code reader accessories category carries the I/O boxes and breakout modules that turn a reader's trigger and good-read lines into terminals a PLC cabinet can wire to.

The good-read handshake: the part people skip

A string in a buffer without a freshness flag is a guess: the PLC cannot tell a fresh read from the previous part's leftover bytes. Every route therefore carries a good-read signal alongside the data.

• RS-232: wire the reader's good-read output to a discrete input and copy the buffer in the same scan cycle as the pulse's rising edge.
• Ethernet implicit: read the status or trigger word inside the same input assembly as the string; no second path, no race.
• USB: keyboard mode has no flag, so either put the reader into protocol mode or accept that the PLC trusts the forwarding device.

Size the pulse to survive scan cycles: at a 10 ms PLC scan, a 50 ms pulse covers five scans with margin, and a pulse shorter than two scans can be missed entirely, leaving a stale string that looks real. Trust in the decode itself, before any wiring matters, is a separate question: the read confidence guide grades the evidence, and the serial trigger guide covers the reverse direction, when the PLC commands the scanner and nothing comes back.

The three routes compared

The table's figures assume a 24-byte string and 8N1 framing; the arithmetic above shows how each one moves with payload and baud.

Which route for which job

• Retrofit with a spare serial port and one fixed reader: RS-232 at 115200, wired good-read pulse, framed with a carriage return. Done in an afternoon.
• New build with fixed code readers on the line: buy readers that speak the PLC's protocol, connect over Ethernet with implicit messaging, and map the status word with the string.
• Reader fleet already owned, plain Ethernet or serial: a gateway between scanner and controller, and the scanners stay as they are.
• Handheld at a bench, gate or tool crib: USB into a host that forwards, never into the PLC CPU.
• Line running faster than about 10 reads per second: check bytes × 10 / baud against the read period, and move to Ethernet if it crowds a third of it. A reader such as the LS-CRD-0028 decodes at up to 60 codes/s and sends results over Fast Ethernet, so the network, not the string transfer, sets the pace.

Checks before you order

• Count the controller's ports and protocols; confirm the spare port is an application serial port, not a programming-only socket.
• Match framing at both ends: data bits, parity, stop bits, baud, suffix.
• Read the reader's protocol option list against the PLC's: implicit or explicit on EtherNet/IP, and which assembly layout each side expects.
• Reserve discrete inputs for trigger and good-read, and order an I/O breakout from the code reader accessories range if the cabinet needs terminals rather than a connector.
• Size the runs before pulling cable: about 15 m for RS-232 at full rate, about 5 m for USB 2.0, 100 m per Ethernet segment.
• For a gateway, write down the buffer address, length and status word registers before the hardware arrives, so the PLC program is ready the day it lands.

When the usual answer is wrong

It has Ethernet, so it goes straight to the PLC. Only with a protocol match. Plain TCP stops at a PC or a gateway, because most PLC CPUs offer no raw socket to the running logic.

A USB adapter makes it serial. The adapter changes the plug, not the host problem: the scanner still needs a host on one side, so a converter has to land on a real application serial port with its framing matched.

It worked on the bench at 20 m, so it will work at 20 m on the line. Marginal serial runs corrupt strings intermittently at production rates. Move to Ethernet instead of chasing phantom failures.

The reads look good in the office, so the string alone is enough. Line vibration, glare and speed change decode quality between bench and production. The handshake travels with the string; build it in from the first day.

To choose the hardware for the route you picked, start at the code reader finder, or put the whole station together in the configurator. For a second opinion on an existing panel's mapping, the contact page reaches the applications team, and the code-reading topic page collects the rest of the series.