Barcode scanner interface to a PLC: Ethernet, serial or USB

You have a PLC with a spare Ethernet port, a scan station, and a catalog of readers that all claim to connect. The interface you pick decides the project: it sets the hardware, the ladder logic and whether the scan string ever lands in a controller tag. This guide compares the three paths — EtherNet/IP explicit messaging over Ethernet, RS-232 into a serial or ASCII module, and USB as a keyboard wedge — with the cable limits, the poll arithmetic and the integration cost of each. The answer favors Ethernet for PLC-side work: one cable, no converter, and the read arrives where your program can use it. If you want the receiving-end view first, the barcode scanner input methods to a PLC overview covers what each port accepts.

Which interface should connect a barcode scanner to a PLC?

Pick Ethernet with EtherNet/IP when your PLC can run explicit messages: a 100 m cable run per segment lands the string in a controller tag with no converter, RS-232 needs an ASCII module in the rack, and USB-HID stops at the HMI, 5 m from the scanner.

The decision rule is to follow the string. If the PLC program must branch on the code — job selection, reject handling, traceability — the interface has to reach the controller, and Ethernet or serial are the only candidates. If an operator just needs the code in an HMI field or a PC form, USB is enough and adds no rack hardware.

Distance works in Ethernet's favor: one clean segment spans a cell, and a switch extends it wherever the station moves next. USB's short reach is built into the standard, and RS-232's limit at common baud rates sits in the comparison table below.

Per case, the pick looks like this:

• EtherNet/IP-capable CPU, reader anywhere in the plant: wired Fast Ethernet handheld and an explicit-message poll.
• Rack with a spare serial or ASCII module, run inside the serial limit: RS-232 handheld at the default serial settings, one terminator.
• Code goes to an HMI recipe field or a PC application: USB keyboard wedge, and the PLC stays out of it.

When the controller has no Ethernet port at all, RS-232-versus-USB becomes the whole decision, and the handheld scanner to a PLC without Ethernet guide works through exactly that choice.

How does an Ethernet reader put the scan string into a PLC tag?

The reader holds the last decode in a data table, and your PLC reads it with an explicit-message instruction: the MSG block opens a TCP session on port 44818, addresses the reader's IP in the message path, and copies the string into a controller tag each time it runs.

Explicit messaging is a request-and-response exchange, not a continuous stream: each message names the data type and size it wants, the reader answers, and the exchange is over. That profile is aimed at exactly this kind of non-time-critical read. The other EtherNet/IP mode, implicit Class 1 connections, exchanges a fixed set of data on a strict cycle for time-critical I/O; a scan string is not time-critical, so explicit messaging fits and consumes no connection budget.

In ladder-based controllers two rungs do the whole job: the poll, configured with the reader's IP address in the message path and a controller tag as the destination; and a handshake rung that copies the string onward when the reader's new-read flag toggles. Most industrial readers expose the last decode, its symbology and a timestamp in that data table, so one message brings all three across.

Readers without EtherNet/IP firmware are not excluded: many act as a plain TCP server that streams ASCII, and a controller with raw socket support reads that stream instead. The barcode reader as TCP server guide covers the reader side, and the raw TCP socket method covers the PLC side.

Wired Fast Ethernet handhelds that take the direct path:

Where the reader sits away from an outlet, PoE versions carry data and power over the same single cable:

What does each interface cost to integrate?

Ethernet costs one cable and a handful of ladder rungs; serial costs an ASCII module plus framing code; USB costs nothing in the rack but buys you nothing in the PLC, because the string never leaves the HMI or PC.

The pattern in the table: serial's cost is code you maintain — framing, terminators, buffer clears — while USB's cost is a string that never arrives in the ladder. Ethernet's cost is one message you write once. When no serial port exists to hang a reader on, a serial-to-Ethernet gateway feeds the string into plant data tags over the network, and a USB-to-RS-232 converter rewires a USB reader as a serial device — the interface conversion wiring guide shows both cable sides.

How fast must the PLC poll a handheld scanner?

Poll at 100 ms and you will never miss a handheld scan: an operator fires a reader about once per second at most, so ten poll cycles pass between two triggers and the string simply waits in the reader for the very next one.

The poll interval is a handshake choice, not a performance cliff: a slow poll delays a read but never loses one. Set the pace from the two relations below, then check the result against the fastest station on your line.

The factor of 10 in the first line is the 8 data bits plus the start and stop bits of an 8N1 serial frame.

Over Ethernet the same fetch is one request and one response, typically a few milliseconds on a clean segment. If a serial application does need tighter scan-to-flag timing, the PLC response time guide walks the buffers and handshakes that actually move that number.

When is RS-232 still the right choice?

Choose RS-232 when the rack already has a serial or ASCII module and the run stays under 15 m at 9 600 bit/s: you add framing and a terminator, and the same controller tag results without touching the plant network.

The serial path needs three pieces: a physical port — CPU serial or an ASCII module in the rack — a framing rule, and a buffer sized to your longest code. Framing means a terminator, most often a carriage return, plus a maximum length so a partial scan cannot wait forever. Clear the buffer the moment a read is credited, or the next poll returns stale data; the ASCII string storage guide shows the byte layout and the clears.

Serial's classic failure is garbage characters, and the cause is almost always a settings mismatch: baud, parity, stop bits or the terminator set differently on each end. Match the defaults on both devices and the symptom disappears; the PLC serial link fix guide lists the remaining suspects.

Want the whole setup worked line by line? The Mitsubishi FX3U serial barcode scanner interface setup walks the register map and protocol settings end to end.

When does USB work, and when does it quietly fail?

USB works when the destination is an HMI, a PC or a Linux controller with a USB host port, and it fails quietly in the main case: the string appears as keystrokes in the HMI recipe field and never reaches the PLC program.

The USB port on a PLC CPU is a programming port by design. It does not hand HID keyboard input to the control program, so a wedged scanner fills HMI fields and PC forms while the ladder never sees a character. Nothing is broken; the input simply travels somewhere else.

USB is the correct pick when that somewhere is genuinely the destination: recipe selection at an HMI, quality-lab logging, a PC tool that compares codes. The keyboard wedge guide covers the HMI setup, and the single-character HMI bug is the wedge failure worth knowing before go-live.

Controllers running a real operating system flip the answer. A Linux controller with a USB host port reads the scanner's HID events directly, and the string goes wherever your service sends it — the Node-RED serial port guide shows that path. Where the host port itself needs setup on an embedded controller, the P1AM-100 USB port barcode scanner configuration guide covers the device settings.

Wired USB handhelds that pair with an HMI or a Linux host:

What about wireless and cordless readers?

Wireless changes the radio link, not the PLC interface: a wireless reader still hands its strings to the network by Ethernet, to a base station's serial port, or to a USB host, so the interface decision stays exactly where it was.

A Wi-Fi reader joins the plant network like any other device: give it an address and poll it with the same message, because the radio replaces the cable, not the interface. A cordless reader with a base station is the different case — the base station frequently speaks serial, so the radio link ends at an RS-232 port, and the cordless base station guide walks that wiring.

Choose wireless for the reason it exists: the operator moves all shift, trolleys travel, and a cable would snag. The poll arithmetic from the previous section holds unchanged, and so does the decision rule from the start of this guide.

Wireless packages and readers built for a networked or base-station install:

What do you check before ordering?

Confirm three things before you order: the reader's interface list against your PLC's open ports, the decode symbologies against the codes on your parts, and the mount — gun grip for the bench, fixed mount for a fixture.

PLC side

• An open Ethernet port on the CPU or a switch port in the cell, with explicit-message client support; without it, price the serial module into the project.
• Ladder room for one timed poll, a string buffer sized to your longest code, and a new-read handshake rung.

Reader side

• The interface list in the reader's own data: wired Fast Ethernet for the PLC, USB for HMI and Linux hosts, wireless packages for moving operators.
• The symbologies your parts carry — Code 128, QR, Data Matrix — checked against the reader's decode list.
• The code size and stand-off on your fixture, matched to the reader's optics.

Cable and install

• Clean category cable runs, one segment per hop, a switch where distances add up.
• Strain relief and a mount that leaves the trigger where the operator's hand already is.

The decision, per case

• New install or an EtherNet/IP-capable CPU: wired Fast Ethernet handheld, explicit-message poll on a fast timer.
• Spare serial module and a short run: serial handheld at the default settings with a carriage-return terminator.
• Destination is an HMI or a PC: USB wedge handheld, and the PLC stays out of it.
• Operator who moves all shift: wireless package onto the same poll, or cordless with a serial base station.

Start from the handheld code readers category or filter by interface in the code reader finder; reader accessories cover the mounting and lighting side. More integration patterns sit on the systems topic page, and if the choice is down to two specific readers, send us the codes and the controller model through the contact page and we will work the numbers with you.