Two barcode readers into a PLC: compare strings and flag a match

A verify station that reads the same code twice and switches an output only on a match catches mislabels, swapped cartons and duplicate prints at the point they happen. The controls job is small: two readers, two receive buffers, one compare instruction. The details decide whether the match output is trustworthy, so this guide covers the interface choice with catalog numbers, the wiring, the reader configuration, the buffer layout, the compare itself, a freshness guard, and a timing budget that tells you whether the link keeps up with your line speed.

Choose the interface before you buy the wiring

A compact PLC CPU with a two-port serial communication unit is the classic home for this job: one slot, two independent RS-232 ports, one reader each. That architecture works, and everything below builds on it. Before you commit, weigh the catalog: the fixed code readers category lists 365 Fast Ethernet and 126 GigE models against 28 serial ones — 365 + 126 = 491 Ethernet-interface readers to 28 serial. Serial makes sense when the PLC side already carries the ports; Ethernet wins on distance (100 m per run against the 15 m at 20 kbit/s that RS-232 is specified for), on cabling, and on serving both readers from one PLC port through a switch. The barcode scanner input methods to a PLC guide weighs all three interfaces; the rest of this article walks the serial path first, then shows the Ethernet swap.

What you need

• Two readers of the same model and firmware options, so both can take an identical recipe. Buying now? The code reader finder filters by interface, resolution and shutter first.
• One serial port per reader: the two ports of one serial communication unit, or two serial cards.
• One cable per reader carrying transmit, receive and signal ground, crossed to match which side is DTE and which is DCE; the reader's interface sheet names its side.
• Mounting, splitters and spare cabling come from cables and code reader accessories. Where a reader terminates in a single connector, a breakout cable does the split without a junction box: the MV-IDA-PE-M12A17pF-openRJ45DB9-HF-5m lands a 17-pin M12 on open leads, RJ45 and DB9 in a 5 m high-flex GigE run.

The serial-interface logistics reader in the catalog is the MV-ID6200PM-00C-NNG: 20 MP, Serial interface, global shutter, C-mount.

Step 1: make both readers emit identical bytes

The comparison is only as good as the two streams, so configure both readers from one recipe:

1. Enable exactly the symbologies the line prints — and nothing else — identical on both units.
2. Clear prefix and suffix on both, or set the same ones on both.
3. Choose one terminator: CR, LF, or CR and LF together, the same on each reader.
4. Set identical framing. Most industrial readers default to 9600 baud, 8 data bits, no parity, 1 stop bit; keep both alike and write the value on the drawing.
5. Bench-proof the pair: aim both readers at the same label, capture the raw bytes from each in a terminal program, and diff them. Byte-identical, or fix the recipe.

A 20-character part number with CR and LF is a 22-byte message — that figure drives the timing budget below. For the grounding, shielding and retry decisions around the link, see barcode reader PLC communication: plan a reliable link.

Step 2: receive each reader into its own buffer

Give each port a receive instruction that pulls bytes into memory and raises a done flag; PLC manuals group it under the serial communication instructions, and one common compact PLC names the send/receive pair TXDU and RXDU.

1. Aim each port's receive at its own 32-word buffer and its own done flag.
2. End each message on its terminator character or its received-byte count, never on a fixed scan delay.
3. Clear the buffer and the done flag every time you re-arm; a leftover string from the previous part is the classic phantom match.
4. Keep the two readers' traffic independent to the last byte: no shared scratch memory between ports.

Size each buffer for the worst label, not the average: a GS1-128 logistics label carries up to 48 data characters, so 48 + 2 terminator bytes = 50 bytes = 25 sixteen-bit words, and a 32-word reserve absorbs the occasional longer code. The word-level layout, clear patterns and addressing details are in storing ASCII barcode strings in PLC memory.

Step 3: strip terminators and run the compare once

On a fresh pair of reads (next section), strip the terminator bytes from both buffers and run one string-compare instruction — the manual's text and string group sets an equality bit when length and bytes both match. Check length first in your own logic so a 19-byte string against a 20-byte string fails fast.

Use your own names for the pieces and map them to your CPU: R1_LEN and R2_LEN are integers holding received byte counts, cleared to zero on every re-arm; R1_BUF and R2_BUF are the two 32-word buffers; MATCH_OK is the output coil. The match logic is MATCH_OK = (R1_LEN = R2_LEN) AND (R1_BUF = R2_BUF), evaluated only while both fresh bits are set. For that compare written out rung by rung, the ASCII string-compare walkthrough for a barcode match follows the same length-then-bytes order.

Step 4: compare only a fresh pair of reads

Two flags make the pair honest. FRESH1 and FRESH2 are booleans: each port's receive-done sets its flag, the compare runs only when both are set, and it clears both after latching the result into MATCH_OK and NO_MATCH. Wire the same presence-sensor pulse to both readers' trigger inputs so each pair describes the same carton; if you trigger readers by serial command instead, the silent serial trigger diagnosis covers the case where one unit quietly ignores the command.

Worked example: does the serial link keep up with the line?

Take a 0.6 m carton pitch on a 0.5 m/s conveyor, 22-byte messages at 9600 baud 8N1, and a reader rated 60 codes/s:

• Part window: 0.6 m ÷ 0.5 m/s = 1.2 s.
• Serial transfer: 22 bytes × 10 bits/byte = 220 bits; 220 ÷ 9600 bit/s = 22.9 ms, call it 23 ms.
• Decode: 1 s ÷ 60 reads = 16.7 ms per read.
• PLC scan: take the pessimistic end, 10 ms.
• Budget: 16.7 + 23 + 10 = 49.7 ms, which is 49.7 ÷ 1200 ≈ 4% of the window.

The serial link is nowhere near the bottleneck at carton rates; decode rate and trigger alignment are. Double the speed to 1.0 m/s and the window halves to 0.6 s — the budget still fits with a factor of twelve in hand.

When Ethernet is the better two-reader link

For a new station, two Ethernet readers replace the serial unit: one PLC port serves both through a switch with two socket connections, runs reach 100 m, and the same compare logic runs on the two received strings. Write the readers as TCP clients against a listener in the PLC — or the reverse, per TCP client or listener: match your network barcode reader to your host — or map them as implicit I/O assemblies if the PLC speaks EtherNet/IP, as in mapping the reader's implicit I/O assembly. Other decode-side patterns sit on the code reading topic page.

For the hardware, the MV-ID3013PM-12M-WBN is a compact 1.3 MP reader with a 12 mm focal length, Fast Ethernet interface and M12 mount, the LS-CRD-0028 pairs a 2560 × 2048 sensor with an 8 mm lens at 30 fps and 60 codes/s, and the LS-CBL-0117 supplies a locking RJ45 camera data cable in 15 m.

Start-up checklist

Run these before the first production carton:

• Both readers byte-identical on one test label, captured in a terminal — the compare inherits every difference upstream.
• Two 32-word buffers, cleared on every re-arm — stale strings fake matches.
• The fresh-pair guard ahead of the compare — part N against part N-1 looks like random mismatches.
• Terminators stripped before the compare — invisible CR and LF bytes defeat equality.
• A receive timeout (500 ms after trigger is a workable start) drives a fault output — silence becomes a state the line can act on.
• Match and no-match outputs timed against the reject mechanism — 50 ms of logic budget is easy; the diverter's response is not.

Send the label symbology, line speed and host interface through the configurator and we will size both readers and the link for your pitch.