Reading a barcode scanner into a PLC CPU module over serial

You have a compact IEC 61131-3 CPU module and a barcode reader that offers RS232 and USB, and you need the decoded value in a PLC variable — not on a PC. The short answer: serial works, USB does not, and the whole receive path on the controller is three library calls. This guide gives the port settings, the wiring, the code that collects and parses the string in the CPU module itself, the parts to order, and the checks that prove the link at line speed.

Can a PLC CPU module read a barcode scanner over RS232?

Yes. A compact IEC 61131-3 CPU module reads a barcode scanner over RS232 by opening the COM port as a data stream, collecting the ASCII characters the scanner sends, and parsing the finished string with a scanf-style call — all on the controller, with no PC in between.

The serial port behaves like a file: one open at start-up, then character reads for as long as the program runs. Structured text is built for this — string variables, character handling and format-driven extraction are standard parts of IEC 61131-3, so nothing outside the CPU module is needed.

The reader does the decoding. Every good scan leaves the port as plain text: the decoded characters followed by a terminator, normally a carriage return (ASCII 13). The PLC never touches bar widths or image data. The same terminal-style link into a controller is described in RS232 barcode scanner connection to an embedded host; here it runs on a PLC CPU module, and compact PLC families have done it for decades — one worked example of scanner data into a compact PLC over RS232 shows the pattern end to end.

Why will a USB barcode scanner not work on this module?

Because a USB scanner is a USB device and the compact CPU module has no USB host connector: a device enumerates only against a host, so without host hardware and a host stack the scanner never appears, and no IEC 61131-3 function can read it.

The reader decision is therefore made for you: order the RS232 version. A USB model is not reachable with a passive adapter either — a USB-to-serial dongle is itself a device, so it cannot become the host the scanner needs.

A compact reader like the LS-CRD-0047 is a 1.2 MP USB 2.0 unit that reads at 60-120 mm — right for a station where a PC or a controller with a real USB host runs the line, wrong for a serial-only CPU module. If your controller does carry a host port, the rules change completely; USB host OTG with a barcode scanner on an embedded controller covers that case.

Handhelds follow the same split: the choice of RS232 or USB for a handheld on a PLC is made on the scanner side of the cable, while the PLC side of this link stays exactly as described here.

Which serial settings must match on both ends?

Match four parameters on both ends — baud rate, data bits, parity, stop bits: 9600 baud, 8 data bits, no parity and 1 stop bit (8N1) is the power-up default on most industrial readers, so set the CPU module's port to that and change both ends together when you deviate.

Wiring is three conductors: the reader's transmit to the module's receive, the reader's receive to the module's transmit, and signal ground common to both. When both ends are wired as DTE you need a crossover (null-modem) cable — suspect that first when characters arrive as garbage or not at all. Leave hardware handshaking off: the link is one-way data, and a dangling control line silences some ports.

Each 8N1 character costs 10 bits on the wire — 1 start, 8 data, 1 stop — so the line time for a message is pure arithmetic:

A reader sending Value:123456 plus CR and LF transmits 14 characters: 12 in the text, one CR (ASCII 13), one LF (ASCII 10). 14 × 10 = 140 bits. At 9600 baud that is 140 ÷ 9600 = 14.6 ms — call it 15 ms from first bit to last; at 115200 baud the same line takes 140 ÷ 115200 = 1.2 ms. On a 500 ms part pitch, 15 ms is invisible, so stay at the default. Raise the baud only when strings or rates grow: five 30-character reads per second is 5 × 30 × 10 = 1500 bits, 156 ms of line occupancy at 9600 baud — it fits, but with little slack for retries.

How do you open the port and collect the string?

Open the port once at start-up with Sysfopen, read one character per program cycle with Sysfgetc, and append every valid character to a string until the terminator arrives — that is the whole receive engine.

1. Declare the receive variables, with types and starting values:

VAR
    Fp          : UDINT := 0;        (* stream handle from Sysfopen *)
    Ch          : INT    := 0;       (* character code from Sysfgetc *)
    InputString : STRING[80] := '';  (* decoded characters from the reader *)
    Variable    : DINT   := 0;       (* value extracted from the string *)
    i           : INT    := 0;       (* converted-field count from SysVarsscanf *)
END_VAR

Fp, Ch, InputString, Variable and i are this guide's own names; Sysfopen, Sysfgetc, SysVarsscanf, COM0 and UDINT_TYPE are the library identifiers, written exactly as the platform defines them.

2. Open the stream once, on the first scan:

Fp := Sysfopen('COM0', 'rw');

Guard the returned handle: an unsuccessful open must raise a visible fault, not a silent read loop.

3. Read one character per cycle:

Ch := Sysfgetc(Fp);

Append the character to InputString whenever the call reports one arrived.

4. Close the line on the terminator: when the received character equals CR (ASCII 13), mark InputString complete for parsing and clear the buffer for the next scan.

5. Age the buffer: count cycles since the last character, and past a few hundred, empty a half-built line so a broken message cannot glue itself to the next one.

The test that proves the engine: connect a PC terminal emulator at 9600 8N1 in place of the reader, type Value:1234, press Enter, and watch InputString on an HMI or trace — it must show exactly those characters, complete, once.

How do you extract the numeric value from the string?

One call does it: SysVarsscanf with the format 'Value:%d' converts the digits that follow the prefix into an integer variable, and its return count tells you whether the line matched — one converted field accepts the line, zero rejects it.

i := SysVarsscanf(ADR(InputString), 'Value:%d', UDINT_TYPE, ADR(Variable));

The format string and the reader's transmitted line must agree, so configure the reader's prefix and suffix to send exactly Value:, the digits, then the terminator; prefix and suffix framing for barcode scanner input covers that configuration. The call is scanf-style: it reports how many fields it converted. On zero, keep the last good value in Variable and set a quality bit for the line controller. Payloads with several fields per scan call for pattern matching instead — regex parsing of prefix, suffix and capture groups shows that build.

Test: send Value:1234 and Variable must read 1234 with the count at 1; send a line with a corrupted prefix and the count must stay at 0 with Variable unchanged.

Which reader and cable should you order?

Order a serial-interface reader for a direct link, an Ethernet reader when distance or reader count rules serial out, and the matched code reader cable rather than a hand-wired DB9 — the integrated cable exists for exactly this wiring.

The direct fit for a CPU-module COM port is a reader that speaks serial from the factory. The MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a Serial interface and a C-mount lens mount, so the field of view can be re-glassed as the line changes.

The cable matters as much as the reader. The MV-IDA-PE-M12A17pF-openRJ45DB9-HF-5m is a high-flex code reader cable, 5 m long, 17-pin at the reader end, with open leads, RJ45 or DB9 at the host end — order the DB9 and your crossover becomes a terminal assignment instead of a soldering session.

To browse: fixed code readers with their camera finder, then code reader cables and reader accessories — covers, light boards, I/O boxes — in the accessory finder. When the station also needs a lens, a light and a controller, build the reading station in the configurator.

How do you verify the link before production?

Three passes, in this order: a loopback on the module's port, one terminal echo of a real scan, then 100 scans at line speed with a rejected-line counter that must still read zero at the end.

• Loopback first. Bridge transmit to receive at the module's connector; every character you write must return immediately. This proves the port, the settings and your code before the reader is involved.
• One real scan. Connect the reader, trigger once, and read the terminal: the decoded text, then the terminator, nothing else.
• One hundred scans at line speed. Trigger at production rate and count rejected lines, where the converted-field count reads 0. Zero rejects passes; one reject stops the check — look at print quality and contrast before touching the code.
• The trigger path is separate. A reader that stays silent when the module sends its command has a command problem, not a data problem; diagnosing silent host trigger commands walks that fault.

When is a serial reader the wrong choice?

Past 15 m of cable, past one reader per COM port, or past a few codes per second, serial stops being the right answer and an Ethernet reader takes over.

Three limits decide it. Distance: the classic TIA-232 limit is 15 m at up to 20 kbps, and USB 2.0 allows 5 m per cable segment — neither spans a plant aisle, while Ethernet reaches 100 m on Cat5e. Port count: one reader per COM port, and a compact module has few. Rate: past a few codes per second, or across several stations, the network reader wins outright.

Two readers that drop straight into that last row: the LS-CRD-0052, a 1.2 MP reader with a 12 mm focal length and dual aviation plugs, and the MV-IDS006M-12C-C, a 6 MP logistics code reader on GigE.

Moving to Ethernet brings its own planning: start with planning a reliable barcode reader to PLC link and matching your reader's TCP role to your host. And when the module's only serial port is already spoken for, placing an RS232 reader behind a gateway keeps the scanner serial and hands the PLC a fieldbus message instead.

If your module, port count or reader list sits between these cases, send the set-up through the contact page and we will size the link with you.