Barcode reader sends no data to the PLC COM port

A barcode reader that decodes every code and still leaves the PLC's receive registers at zero is a common serial fault on a bench build. The read indicator proves the optics and the decoder; it says nothing about the port at the other end of the cable. This guide runs the fault in the order that finds it fastest: which port the reader should occupy, how to prove the reader is transmitting, how to tell a framing fault from a bit-timing fault, and how to set the receive buffer so the string lands. The same checks apply to any compact controller with a general-purpose serial port, and to an HMI COM port.

Why does the reader decode fine but the PLC receives nothing?

Because three gates sit between a successful decode and a full receive register, and any one of them failing leaves the buffer empty: the port must be in general-purpose ASCII mode, the framing must match, and the receive condition must complete. A decode lights the reader's indicator and stops there; the transfer happens only when the port accepts arbitrary bytes, the reader's end character is the one the PLC watches for, and the receive instruction has a rule that says 'message finished'.

In order of probability on compact brick controllers:

1. The COM port is still in its programming or fixed protocol. Most common, because the port works fine for upload and download, so nothing points at it.
2. The receive buffer has no termination character and no reachable byte count, so the string never completes.
3. The framing mismatches: the reader terminates with one character, the PLC waits for another.
4. The wiring: transmit tied to transmit, or the line undriven.

Which PLC port should the barcode reader connect to?

The COM port, set to general-purpose mode — not the tool port, which speaks the programming protocol and discards foreign bytes for as long as the programming software owns the link. Compact controllers usually give you one of each: a tool port for the programming socket and a COM port whose protocol you choose. General-purpose mode (some families call it free protocol or general communication) is the one that passes raw ASCII.

The mode lives in the port configuration or in system registers, downloads with the project, and on most compact families is read at power-up. Download the change, then cycle power: a port whose mode was edited but never re-read behaves exactly like a dead reader. Where the tool port can be switched to general communication, the programming software reclaims it the next time you go online — leave the tool port for programming.

If the COM port is committed to an HMI link or locked as a Modbus slave, ASCII will not parse on it. Free the port, or take the Modbus RTU polling route instead. The same three gates apply when the host is a SCADA station rather than a PLC; integrating a serial reader with a SCADA COM port walks that host end.

How do you prove the reader is transmitting before touching the PLC?

Tap the reader's transmit line into a PC terminal at the reader's baud setting and scan a code: a clean string on screen proves the reader side, and every fault that remains lives on the PLC side of the connector. Start the terminal at the reader's settings — most industrial readers ship at 9600 baud, 8 data bits, no parity, one stop bit — and watch the hex view, because the framing characters arrive as 02h, 03h, 0Dh and 0Ah, not as printable text.

A multimeter settles the electrical question in seconds. An idle RS-232 transmit line driven by the reader sits at a negative voltage relative to ground, typically -5 V to -12 V; a line resting near 0 V is undriven, so nothing is transmitting, the conductor is broken, or you are on the wrong pin. Then confirm the crossover: reader transmit to PLC receive, signal grounds common. Reader and PLC are both data-terminal equipment facing each other, so a straight-through cable needs a null modem to cross the pair.

For the bench tap, an integrated reader cable that breaks out to open leads avoids soldering a molded assembly. The MV-IDA-PE-M12A17pF-openRJ45DB9-HF-5m is a 5 m high-flex cable from the 17-pin connector to open leads, RJ45 or DB9.

For the full pinout, shield treatment and PLC-side landing, see wiring a barcode scanner RS232 ASCII string to a PLC serial port.

When should you suspect the serial parameters instead of the wiring?

When the PLC receives wrong characters rather than silence, the bits are arriving but the timing is off: a baud, parity or stop-bit mismatch produces consistent garbage, while port-mode and wiring faults produce nothing at all. That one observation halves the fault tree before you open a configuration tool.

Both ends must agree on four settings: speed, data bits, parity, stop bits. Standardize on 9600 8N1 unless something else owns the PLC setting, and make the change on the reader — its transmit format is set with programming barcodes or its configuration utility, and an explicit setting beats a default you never confirmed. When the terminal shows clean text but the PLC shows garbage, the two ends differ; garbage characters from a barcode scanner on a PLC serial link covers that branch end to end.

What start and end characters should the reader send?

Bare code data terminated by a single CR (0Dh) is the right default: it satisfies almost every PLC receive instruction, and you add STX (02h) and ETX (03h) framing only when electrical noise on the line is real. The transmit format is a configured pair, a prefix and a suffix; the classic full frame is STX, data, ETX, CR. Match the suffix to the PLC's end character exactly. A reader appending CR+LF against a PLC that terminates on CR leaves the LF (0Ah) in the buffer, where it becomes the first byte of the next string — set CR only and the problem never appears.

Set the format with programming barcodes, the same mechanism that adds an Enter key to a barcode scanner, or with the reader's utility. Termination faults are host-agnostic: an RS232 barcode reader framing fix on a PC-based controller is this same diagnosis in a different shell.

A serial-interface reader sends that frame straight down the line. The MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a Serial interface.

What is the receive buffer and how do you set it?

It is the PLC's serial input area, and its condition is the rule that ends a receive: set a termination character of CR (0Dh) rather than a fixed byte count, because code lengths vary and a count that is never reached leaves the buffer empty forever. The receive instruction accumulates bytes until its condition completes — end character seen, byte count met, or timeout. A port with no character and no count configured still shows nothing even when mode and wiring are correct, which is the signature of this fault on a bench that has cleared the first two gates.

Work the numbers for a 12-character code:

Ten bits per byte is 8N1 with no parity. Terminating on CR completes the receive 15.6 ms after the first bit, so a 500 ms message timeout gives a 30-fold margin over any handling delay; set the gap timeout near 10 ms so a broken frame reports instead of hanging, with the abort logic in aborting a serial barcode read when the scanner reads nothing. Clear the buffer after every copy — residual bytes prepend to the next frame and shift the alignment, the failure traced in clearing residual data from a PLC receive buffer. Word-addressed controllers pack two bytes per register, so the 15-byte frame occupies 8 words; storing ASCII barcode strings in PLC memory covers the packing and the length bytes. The deeper traps — nulls, races between the read and the copy — are laid out in ASCII barcode data framing in the PLC receive buffer.

When is a serial COM port the wrong answer?

Move the reader to Ethernet when any of these holds: the run is longer than 15 m, the only COM port is committed to an HMI or a Modbus master, or several readers must report to one controller — none of those is worth fighting with RS-232. RS-232 is a short-haul link; once the cable leaves the cabinet, distance and ground potential take over. RS-485 carries the same ASCII to about 1200 m with biasing and termination, at the cost of a converter at each end and a shared discipline on who drives the line.

An Ethernet reader removes the constraint. The LS-CRD-0052 is a 1.2 MP fixed reader with a 12 mm focal length and an Ethernet interface, and its dual aviation plug holds the connection through vibration.

On the controller side you then read results over an industrial protocol — reading fixed code reader results into a PLC over EtherNet/IP — or send ASCII over TCP where no serial port exists at all, as in vision camera to PLC over Ethernet ASCII strings. One caution before you commit: your PLC Ethernet card may not support ASCII from a code reader, so check the card's socket support, not just its port count.

What should you settle before ordering the reader and cable?

Four decisions up front: which port carries ASCII, which reader interface matches it, the cable length with slack, and the framing standard — data plus CR — written into both the reader configuration and the PLC receive condition before commissioning day. Settled early, they also make the parts list exact: one reader, one cable, one port, no bench improvisation.

• Reserve one COM port in general-purpose mode; programming stays on the tool port.
• Set both ends to 9600 baud, 8N1, configured explicitly on the reader.
• Frame as data plus CR (0Dh); add STX/ETX only if the environment is noisy.
• Receive on the termination character, buffer 256 bytes, cleared after each copy; 10 ms gap timeout, 500 ms message timeout.
• Keep the RS-232 run under 15 m on shielded cable, grounded at one end.
• Match the interface to the host: Serial for the COM port, Ethernet for a long run or a taken port.
• Size the reading distance from the code width — matching a fixed focus code reader's field of view to its sensor gives the arithmetic.

For the tap and the PLC-side run, the LS-CBL-0224 is a 7 m cable from a DB9 female to open leads.

Start the reader side from fixed code readers or the code reader finder, and the accessories finder for cable types and lengths. If your controller's port is unusual, send the port and reader pairing through the contact page before you wire, or begin with the system configurator; more serial integration guides sit under code reading.