Handheld wireless barcode reader to PLC over TCP

Operators scan 2D codes at packing benches, on pallets and at final assembly, and you want each decoded string to land in the PLC as data — not as keystrokes into an HMI field and not through a database. A handheld wireless barcode reader can do that by itself: the PLC runs a socket server on one fixed port, the reader connects as a TCP client at the moment of the scan, sends one terminated message and closes. This how-to sets that link up, budgets its timing so you know whether connect-per-scan is fast enough for your station, and keeps a docked serial fallback ready for the corners where wireless will not settle.

Who connects to whom on the TCP link

Every TCP connection has one listener and one initiator. Put the PLC on the listener side: it opens a socket on a port you choose, for example 5000, and waits. The handheld reader is the initiator: at the trigger it opens a connection to the PLC address and port, transmits the decoded code, then closes. That is the whole pattern — no database, no middleware, no PC in the path.

Connect-per-scan is the right default for a WLAN handheld. A socket held open across access-point roams breaks quietly; a fresh connection per scan makes every read independent of the last one, and battery drain drops because the radio only works when there is something to send.

Check which side your host software can run before you commit: some SCADA and driver stacks only act as the client, which forces the reader into the server role instead. That opposite arrangement is common on lines with fixed readers — TCP client or listener: match your network barcode reader to your host explains the decision, and barcode reader as TCP server: wire your PLC as the client walks that case with models from the fixed code readers category.

What you need

• A handheld reader with an Ethernet interface, wired or wireless. Browse the handheld code readers by interface and connection; the two below cover the wireless and wired placements.
• A controller with a socket-server function. In modern PLCs it lives in the communication settings as a TCP connection or socket object that listens on a port.
• One fixed IP address for the PLC and one free TCP port above 1024 — 5000 in the examples here.
• An agreed message format: decoded string, optional station prefix, and a terminator. CR followed by LF is the dependable default.
• A laptop with a socket test terminal, so you can prove the server before any reader connects.

For a wireless reader that still speaks Ethernet itself, the LS-HCR-0002 pairs an Ethernet interface with a wireless connection and a 1.0 MP global-shutter sensor in a handheld body. Where the reader will live in a dock, the LS-HCR-0001 serves the same client pattern over USB 2.0 with no radio in the link, and the handheld code readers category lists wired Ethernet and PoE models for the socket path as well.

Plan the network path

Keep the reader and the PLC in the same subnet or VLAN where you can: no routing decisions, one policy to check, and the WLAN clients live on the same broadcast domain as the controller port. Give the PLC its fixed address first, because every reader's client configuration points at it. Give the reader a static address or a DHCP reservation so its identity stays stable in logs and access lists.

Open the chosen port on every firewall or access control list between the two. A per-scan connect from a handheld looks like unsolicited traffic to a policy written for client PCs, and ACL drops are silent — the scan simply never arrives.

Walk the shop floor with the reader before mounting anything. WLAN coverage and access-point roaming move the latency far more than any TCP setting: a roam in the middle of a read adds tens of milliseconds on its own. Scan at the worst spot, not the best.

Raw TCP is not the only door. If your controller takes barcode data only through its fieldbus layer, a reader integration over PROFINET goes through a device description instead of sockets — the PROFINET barcode reader integration with GSDML and TCP guide walks that variant. For the link-planning questions that apply to any transport — buffering, retries, polling versus event — barcode reader PLC communication: plan a reliable link is the companion read.

Worked example: per-read connection budget for a 30-character code

The network plan says the path exists; the timing question is whether connect-send-close costs anything at your scan rate. Work one read through.

Inputs, and where each comes from:

• 30 characters of code content — an illustrative payload, in the 20-40 character range typical for a part serial in a Data Matrix.
• 2 bytes of terminator, CR plus LF — the framing chosen in the steps below.
• 40 bytes of transport overhead per segment: a 20-byte TCP header plus a 20-byte IPv4 header.
• Round-trip counts from the TCP protocol itself: one round trip for the three-way handshake before data can go, and about one more for the close.

Arithmetic: the message is 30 + 2 = 32 bytes; on the wire that is 32 + 40 = 72 bytes, a single segment, because 32 bytes sits far below the 1460-byte maximum segment a 1500-byte Ethernet frame carries. The connection adds 1 RTT for the handshake plus roughly 1 RTT for the close, so each read carries an overhead of about 2 to 3 times the network's round-trip time.

RTT is the only number that moves: roughly 0.1 to 1 ms on a switched wired LAN, typically 2 to 10 ms on a lightly loaded plant WLAN. Put the overhead fraction next to your scan rate:

• Operator-paced station, one read every 2 s: 2 to 3 × 10 ms = 20 to 30 ms per read, about 1.5% of the cycle. Per-read connect is invisible at this pace — use it.
• Fast station at 10 reads/s: the same 20 to 30 ms is 20 to 30% of the 100 ms period. The 10% overhead line sits near 3 reads/s on a 10 ms WLAN, near 30 reads/s on a 1 ms wired link. Past it, keep one persistent connection, or move the station onto the cable.

Set it up: the eight steps

1. Create the socket server in the controller: TCP, port 5000, receive until the terminator. Note which tag or string variable the message lands in.
2. Prove the server alone. From the laptop, open a socket to the PLC address and port and send a short line such as TEST followed by CR and LF. If the receive tag does not show it, fix the server before any reader is involved.
3. Join the reader to the network: associate it with the WLAN or seat it in its dock, give it the reserved address, and enter the PLC address and port 5000 as its server.
4. Select the client behaviour: connect on scan, send one message, close. In this product class the setting lives in the communication or transport profile as a TCP or socket client entry that takes a server address, a port and a terminator.
5. Build the message: decoded string plus CR and LF, identical terminator on both ends. Add the station prefix here if the PLC must tell readers apart.
6. Scan a real code and watch the receive tag: correct characters, exactly one message per scan, a new connection each time.
7. Repeat at the scan point farthest from the access point. Slower or dropped reads there are a coverage finding, not a configuration error.
8. Set the failure policy on both ends: how many connect retries the reader makes before it discards or buffers a read, and what the PLC does when a connection times out.

Five mistakes that stop the scan from arriving

• Both ends configured as clients. Without a listener there is nothing to connect to; the PLC holds the listening socket, everything else dials in.
• Terminator set on one side only. The PLC waits for CR and LF that never arrive, so scans pile up in a buffer that never commits. This is the most common cause of a link that connects but delivers nothing.
• The PLC address changed. A DHCP-served controller address invalidates every reader configuration that points at it; fixed address for the server, reservation for the readers.
• The port is closed somewhere between. An ACL or firewall silently drops the per-scan connect. The laptop test from step 2 clears or convicts this in one minute.
• A dead read blamed on the socket. At the edge of WLAN coverage the failure is radio, not TCP. Scan once at the failing spot with the reader status screen open before rewriting anything.

Fixed docks, wired readers and the RS-232 fallback

If the reader lives in a dock or cradle at one station, wire it and remove the radio from the problem set. A wired handheld reaches the same PLC socket server over the cable with no roam delay and no coverage survey, and a PoE model draws its power from the switch port so the dock needs no separate supply. Wireless earns its keep where operators move; fixed stations want the wire.

Where the WLAN path cannot be made to settle — dense racking, metal carts, a coverage exception nobody will fund — the fallback is the classic one: a cordless reader whose base station speaks RS-232 into a PLC serial port or a serial communication module. Match baud rate, data bits, stop bits and parity on both ends, and the reader behaves like any other serial device the PLC already knows. Two guides carry that path end to end: cordless barcode scanner to a PLC: base station and serial link, and handheld barcode scanner to a PLC without Ethernet: RS232 or USB? for the wider interface choice.

The two placements map onto the two interface combinations, listed as each data sheet prints them:

All 2 share: Image sensor 1280*800 Pixel Global Shutter CMOS; Max acquisition frame rate 60FPS; Pixel size 3.0 µm; Target size 1/4"; View field 31° horizontally, 20° vertically; Symbol contrast 20%; Depth of field range DM 5mil 10-60 mm / DM 10mil 10-100 mm; Focal length (mm) 6.8. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Before you order: five checks

• Reader side: a communication profile that runs as a TCP client and can open per scan. If the settings list only keyboard, USB-HID and serial profiles, plan the dock path instead.
• Controller side: a socket-server function with a spare connection. Each scanning reader holds one connection for the few milliseconds of its life, so count concurrent readers against the connection budget, not total scans per day.
• Message format in writing: payload, prefix, terminator. Everything downstream — recipe selection, work-order checks — keys off that exact string.
• The port open on every access list between reader and controller, and the PLC address fixed.
• A loss policy chosen before the first missing scan is investigated: retry then discard, or retry then buffer.

Shortlist by interface and connection in the code reader finder, confirm the communication profile on the model page, and bench-test the eight steps before the WLAN survey. If you would rather have the socket settings checked against your controller before the order goes in, contact the applications team — that check is a five-minute conversation.