Your PLC Ethernet card may not support ASCII from a code reader

You wired the reader, configured its TCP telegram, pointed it at the PLC's Ethernet option card — and the string never arrives. The programming software connects, the HMI polls the same card all day, so the network is healthy. The card simply has no function that hands your program the bytes of a raw TCP stream, and option-slot Ethernet cards on compact PLC CPUs are often tag-protocol slaves only. This explainer gives you the decision rule, the five-minute manual check that settles it, five routes that do work, and the arithmetic for the serial fallback. It is written for controls engineers pairing fixed code readers or smart cameras with a PLC.

Only socket services accept the string

A fixed code reader with an Ethernet port does not speak PLC protocols. It opens a TCP connection and writes ASCII bytes — start character, code string, terminator — and whatever hosts the far end has to run that socket. On the PLC side that function set is called socket services: callable open, listen, send and receive functions over TCP or UDP. Where the card offers them, the reader's telegram is bytes in a receive buffer and the remaining work is framing, the job covered in ASCII telegrams in the PLC receive buffer. Where the card does not, the connection is refused, or accepted by firmware your program cannot reach. No setting on the reader changes that, and neither does a different cable, a switch or a second IP address.

Smart cameras that push result strings over Ethernet sit in exactly the same spot. The walkthrough of vision camera to PLC over Ethernet ASCII strings covers the PLC end of that exchange once the port can host the socket.

What the reader puts on the wire

The telegram is small and fixed: one code, framed. The role split matters more than the model. The reader is configured either as a TCP client that dials the PLC's address on every read, or as a listener the PLC connects to once and holds open. The PLC socket side must take the opposite role — accept when the reader dials, dial when the reader listens. The TCP client or listener match walks that choice end to end. Reads fire on a sensor input, a serial command or free-run, as the reader trigger modes guide explains, so settle the trigger before the transport.

Readers that put their result on the wire as an ASCII telegram over an Ethernet interface include:

The row spans Fast Ethernet and GigE interfaces; the LS-CRD-0028 reads up to 60 codes/s. Every one of them still needs the same thing from the PLC: a socket on the far end.

Why a slave-only card cannot receive it

An option-slot Ethernet card built as a protocol slave answers exactly one arrangement: the PLC maker's own tag protocol — FINS is the one in this failure class — serving programming software, HMIs and SCADA that poll registers by address. The card's whole job is to be found and polled. Nothing in its function list opens a socket for the user program, so a reader set as a client gets a refused connection, and a reader set as a listener never hears from the card at all. Working through configuring FINS Ethernet tag mapping to a compact PLC's option card is the contrast: every step in that job is an HMI or programming function, and none of it exposes raw TCP bytes to the ladder program.

The generation matters more than the slot. Newer CPUs in these families carry Ethernet on the CPU itself, with socket services in the port's function list; the slave-only behaviour concentrates in the older option-card generation.

The five-minute manual check

Settle the card's class from its own documentation before any hardware decision:

1. Open the option card's operation manual and find the communications functions list, usually the first pages of the communications chapter.
2. Search the PDF for the word socket. On a socket-capable card it returns a chapter: TCP and UDP sockets with open, accept, send, receive and close functions, plus a simultaneous socket count. On a slave card it returns nothing.
3. If the list stops at the tag protocol, programming and an optional HMI or SCADA service, the card is a slave. Stop planning around it.
4. Where sockets are listed, check the mounting prerequisite: some Ethernet units for compact CPUs fit only through an expansion interface unit, so the two parts are ordered together.
5. Write down the reader's role and port number before writing PLC code, because the receive logic differs between accepting and dialing.

Five routes that work

The socket route keeps your architecture. Once the card hosts sockets, the receive side follows the barcode reader to PLC over raw TCP sockets pattern, and socket communication with a vision camera on a PLC CPU shows the same job on a CPU with built-in Ethernet.

The tag route removes sockets entirely — but only if the PLC side can act as client or scanner. Many smart cameras and some fixed readers serve results as tags over an industrial protocol; mapping smart camera tag data into PLC memory over EtherNet/IP and polling several devices on Modbus TCP from one PLC are the two working patterns. A slave-only option card cannot poll either, so this route still points at the CPU's built-in port or a scanner-capable card. Polling also has a ceiling: Ethernet option card crashes under network overload is the failure mode when tag traffic piles up.

The serial route is the quiet winner at string sizes; the arithmetic follows. The gateway route works when nothing else fits: a small box speaks raw TCP to the reader and Modbus TCP to the PLC, and any tag-capable port polls the string out of registers.

The arithmetic of the serial fallback

Example line, with round numbers: one 20-character code per container, 160 containers per minute, and a telegram of 20 data bytes plus a two-byte CR/LF terminator.

• Telegram: 20 + 2 = 22 bytes, or 220 bits on the wire.
• Time on wire at 115,200 baud: 220 / 115,200 = 0.0019 s, about 1.9 ms per read.
• Port load: 160 × 22 = 3,520 bytes per minute, against 115,200 × 60 / 10 = 691,200 bytes per minute of capacity — 0.5 percent.

At half a percent of capacity, the serial port is not the bottleneck and never will be at barcode string sizes. The wiring for that route is covered in wiring a reader's RS232 ASCII string to a PLC serial port. Ethernet earns its place when the same wire carries images — a 5 MP mono frame is about 5 MB, over 200,000 of these telegrams — or when the reader has no serial port at all, which sends you back to the gateway or the CPU route.

Checks before you order

• The reader's role, IP address and port number are written down, and the PLC logic takes the opposite role.
• If the tag route is in play, the reader's protocol options are confirmed on its interface page, and the polling port can act as client or scanner.
• If serial is in play, both ends have the port, and baud, data bits and terminator match.
• The socket budget holds: the reader takes one connection, the HMI and programming tools take theirs, and one stays spare.

When the usual answer is wrong

"It has an RJ-45, it will take the string." A port that only answers a tag protocol never gives the program raw bytes; connector count proves nothing about sockets.

"The HMI works on that card, so the reader will too." The HMI speaks the card's tag protocol — exactly what the card was built to serve. That success is evidence the card is a tag slave, and therefore the wrong port for the reader.

"A gateway is the smallest fix." Often the serial port already on both devices is smaller: a cable versus a powered, configured box with panel space and a failure mode of its own.

"Any CPU with built-in Ethernet solves it." Current-generation compact CPUs list socket services on the built-in port, but the qualifier is the function table, not the connector. The same one-minute check applies.

The decision, case by case

• Card lists socket services: keep everything, match roles, and go straight to the raw-TCP receive pattern.
• Card is a tag slave and the CPU stays: socket-capable Ethernet unit plus its expansion unit, or the gateway if the reader is Ethernet-only.
• CPU refresh acceptable: current compact CPU with built-in Ethernet, sockets confirmed in its function table.
• Reader serves an industrial protocol and the PLC port can poll: tag route, no sockets.
• Reader has RS232 and the line reads a few hundred codes per minute or fewer: serial link — the port sits at a fraction of a percent of capacity at the rates above.

Once the string lands, verify scanned strings against a lookup table closes the loop on the PLC side. To pick the reading end, browse fixed code readers or smart cameras, filter the reader finder by interface, or start building the reading station. If the card's manual table is ambiguous, send that page and the reader's interface list through the contact page — free expert support with every order covers exactly this pairing.