Barcode reader to PLC over raw TCP sockets without EtherNet/IP

When the PLC has no EtherNet/IP scanner and the reader has no implicit I/O assembly to map, a raw TCP socket still closes the gap. Most fixed code readers with an Ethernet port answer a short ASCII command and return the decode result as one text line, and most PLC CPUs or Ethernet modules with socket services can open a client connection and exchange that text with a handful of rungs. This guide gives you the whole link: the trigger-reply pattern on the wire, the timeout and buffer numbers to size before you write ladder, the steps from power-up to a parsed string, and the failure modes that produce empty or stale strings. It ends with the decision per case: keep implicit I/O, drop to serial or Modbus, or flip the roles and let the reader push.

When a raw socket is the right path

Implicit I/O is the cleaner integration when both ends support it: you map the reader's assembly once and the values cycle into PLC memory with no code, which is the path in the Ethernet/IP implicit I/O assembly guide. Many cells cannot take it. A compact CPU may ship without a scanner, an older Ethernet card may offer raw socket services only, or the reader may expose a command/response TCP port but no assembly. There the socket path is the supported method, not a workaround: open a client connection, write the trigger, read the reply.

The trade-off between raw TCP sockets and EtherNet/IP implicit I/O comes down to cyclic versus event-driven data. Sockets read on demand, assemblies update every scan; for a part-linked read between machine cycles, on demand is what you want. If the architecture is still open, the reader-to-PLC communication plan settles the link choice before any cable is cut.

What you need

Five things, all confirmed before the first rung:

• A fixed barcode reader with an Ethernet interface and a command/response mode; the command table in its manual prints the trigger string, the terminator and the TCP port number.
• Static IP addresses on both ends, on the same subnet.
• A PLC side that opens TCP client sockets: a CPU with socket services or an Ethernet module that provides them.
• One industrial Ethernet run from the reader to the switch or PLC port.
• A laptop on the same subnet for bench tests.

Start from the fixed code readers category or the camera finder and filter on an Ethernet interface. Compact readers with Ethernet interfaces that fit the pattern:

For wiring, the cables category and its accessories finder cover both runs. Closest to the reader, one integrated cable carries the Ethernet plug and the power and I/O leads in a single high-flex drop:

Its 17-pin M12 connector lands on open leads in the cabinet, with the RJ45 for data. For a longer run to a distant panel, an RJ45 data cable with a locking stud and an upward bend keeps the connector seated — the LS-CBL-0117 spans 15 m:

The trigger-reply pattern on the wire

In command mode the exchange is three messages deep. The PLC holds one TCP client connection open to the reader's command port for the whole shift. On the part-present sensor it writes the trigger string from the command table, byte for byte and terminator included — many command tables end with CR, the 0x0D byte. The reader scans once, or for the trigger window you configured, and writes one reply: the decoded characters, then usually a separator or grade byte, closed by CR, LF or CR plus LF. A no-read arrives as an error string, or not at all, which is why the receive timeout rather than the reply is the no-read signal you design around.

UDP would drop the connection setup, but then nothing tells you the link died mid-shift. The TCP client versus listener guide covers the other topology, where the reader pushes and the host listens.

Size the receive timeout and buffer first

Two constants in the ladder come from arithmetic, not habit. Example line: a tote every 1.2 s, a part-present sensor that starts the read, and a PLC that must hand a part number or a no-read flag to the diverter within 500 ms of that sensor.

Decode time: a reader in this class is rated 60 codes/s — the LS-CRD-0028 prints that rating alongside 30 fps, a 5 MP sensor and an 8 mm lens. One decode therefore takes 1 ÷ 60 s ≈ 17 ms.

Network: a switched Fast Ethernet hop or two adds about 2 ms of round trip. PLC: with the socket calls polled once per 5 ms scan, sending the trigger and collecting the reply costs about 30 ms across six scans. Worst-case reply: 17 + 2 + 30 = 49 ms, call it 50 ms.

Receive timeout: 4 × 50 ms = 200 ms. The reasoning: the first attempt fails after 200 ms, the retry answers at 200 + 50 = 250 ms total or times out again at 200 + 200 = 400 ms — both inside the 500 ms deadline with at least 100 ms of margin. Cap the ladder at one retry and raise the no-read flag at the second timeout.

Buffer: the longest label here is a 32-character Code 128 part number, so with CR and LF the message is 32 + 2 = 34 bytes. Set the receive buffer to 128 bytes, leaving 128 − 34 = 94 bytes of headroom for a grade byte, a prefix or a longer label on a future product. In PLC memory that message is 34 ÷ 2 = 17 words of ASCII; the bytes, words and clears of ASCII string storage shows how to lay it out and clear it at trigger time.

Bandwidth never becomes the problem: at 1 ÷ 1.2 s ≈ 0.83 reads/s, the traffic is 0.83 × 34 ≈ 28 bytes/s ≈ 226 bits/s against a 100 Mbit/s link.

Ladder steps from power-up to a parsed string

1. Commission the addresses first: static IPs for the reader and the PLC port on one subnet — 192.168.0.10 and 192.168.0.1 with a 255.255.255.0 mask are the textbook example values; use your plant plan — then ping both ways from the laptop.
2. Copy the command table into your notes: TCP port, exact trigger bytes, terminator, and the reply layout — data characters, separator, grade byte, no-read string.
3. Switch the reader to command or trigger mode and switch continuous or auto-read off.
4. Fill in the PLC socket parameters: TCP, client role, remote address = reader, remote port = command port, any free local port, receive timeout 200 ms from the sizing above.
5. Open the connection once at lines-running and hold it for the shift; reopen only after an error.
6. On the part-present sensor edge, write the trigger string exactly — bytes and terminator together.
7. Poll the receive function every scan and append bytes to the buffer until the terminator byte appears or the timeout fires, tracking the running byte count.
8. On terminator: clear the 17 string words, then parse with the string instructions — a FIND-style search locates the separator, a MID-style copy lifts the data — and check the grade before you trust the string. The read confidence guide gives the trust criteria, and field splitting handles the payload.
9. On timeout, resend the trigger once; a second timeout raises the no-read flag, bumps a counter the MES can read, and releases the part to the reject path. On a socket error, close, wait 1 s, reopen.

Test the link before the line runs

Three bench stages, in order. Laptop to reader: a raw TCP test tool sends the trigger and prints the reply, so you see the exact bytes, terminator included, before the PLC is in the picture. PLC to reader: force the trigger bit, watch the buffer fill, and confirm the string registers hold the expected 34 bytes for the test label. Failure paths: five reads over a blank area must raise the no-read flag inside the 400 ms worst case, and pulling the Ethernet run must produce a socket error plus a clean reopen a couple of seconds after replug.

Finish with label stress: rotate the label, dim the light slightly, and watch the grade byte fall before decodes actually fail — that gap is the margin, and the verification guide for label inspection turns it into a pass/fail routine.

Common failures and the fix

• Timeout on every read: the trigger terminator is missing or the reader is still in continuous mode. Send the command with its CR and re-check the mode.
• Connection refused: wrong port number, or the bench tool still holds the reader's single connection. Close the laptop session before the PLC connects.
• Garbage in the buffer: a second trigger went out before the first reply drained. Gate the trigger on the receive-complete bit.
• A stale part number after a no-read: the registers were cleared only on good reads. Clear them at trigger time instead.
• Works on the bench, drops on the line: check the link LEDs and swap in a known-good industrial cable before touching the ladder.

The decision per case

• PLC and reader both speak EtherNet/IP and the application wants the last value present in memory every scan: map the implicit I/O assembly, per the guide in the first section.
• The PLC talks Modbus only: keep the reader on serial and follow the Modbus RTU integration.
• The reader pushes and one host collects: that is the listener role from the client-versus-listener guide linked above.
• No socket services anywhere: add raw socket support with an Ethernet module for the PLC rack, fit a serial/IP converter, or let a vision controller decode and forward the result as a fixed-position telegram.
• Still choosing the interface: the serial, USB and Ethernet input comparison shows what each port type can carry before you commit.

Everything else — one reader, part-linked reads, any PLC with socket services — is the raw TCP pattern of this guide. The system configurator pairs reader, cable and controller in one pass, and the code reading topic page collects the remaining reader-integration guides.