Verify scanned barcodes against a PLC lookup table

Your operators scan a part, a fixture and their own badge at the start of every run, and the line must not start until all three scans are values you expected. That is a verification station: one to five scanners, each delivering an ASCII string to a PLC, checked against a table of allowed combinations held in PLC memory. By the end you will have the interface choice per scanner, the register layout, the table sizing with the arithmetic, the compare and latch logic, and the tests that prove the station before the first shift uses it.

The pattern, decided up front

Each scanner writes its decoded string into its own block of data registers and raises a one-shot new-data flag when the terminating carriage return arrives. A table in retentive memory holds one row per allowed combination: part ID, fixture ID, operator ID, each padded to a fixed length. On the new-data pulse the PLC compares the scan against the table, part column first, and a set-dominant permissive coil latches only when one row matches in all three columns. A failed compare latches a reject code instead, and the HMI tells the operator which field to re-scan.

The decision that shapes everything else: compare each scan against the stored table, never against another live scan. Comparing two readers to each other, as in two barcode readers into a PLC: compare strings and flag a match, proves the scanners agree; it cannot prove the fixture on the machine is one this part is allowed to run on. If you already look up parameters by scanned part number, the array search in barcode recipe lookup in a PLC is the same machinery - verification adds the gate.

What each scanner must deliver

Set every scanner to the same output format before any wiring: decoded data as ASCII, terminated with carriage return and line feed, no prefix. Most handhelds take that configuration from programming barcodes, the same route shown for setting an output suffix with programming barcodes, and the Enter suffix described there is exactly the terminator you want here.

Pad every ID to one fixed length. Twelve characters covers part numbers like P-48213-B, fixture tags like FX-07 and badge numbers like OP-2214 with room to spare, and equal-length strings keep the compare simple: no terminators to strip, no length register to check. Shorter IDs pad with spaces.

Keep the beam on parts, not people: mount fixed readers below face height and train operators never to aim a handheld at anyone's eyes.

Interface decision per scanner, committed:

• Within about 15 m of the rack and a serial port free: RS-232 ASCII at 115200 baud, 8 data bits, no parity, 1 stop. The wiring sequence in wiring a barcode scanner RS232 ASCII string to a PLC serial port applies as-is, and that 15 m shrinks as baud rises.
• Stations spread across a hall, or serial ports exhausted: Ethernet readers, one TCP socket each. Barcode scanner interface to a PLC: Ethernet, serial or USB compares the three routes, and multiple barcode scanners on Modbus RTU and TCP shows the addressing when readers must share one converter.
• A serial-only scanner far from the rack: put a serial-to-Ethernet converter next to it, the pattern in a serial-to-Ethernet converter feeding plant data tags.

USB handhelds suit stations that already have a PC or HMI in arm's reach; over a PLC port, the case for serial over USB is worth reading before you choose one. The LS-HCR-0001 is a 1.0 MP USB 2.0 handheld, and the wired USB handheld beside it below suits the same station:

For the Ethernet route, the wired handheld shown below holds one TCP socket on Fast Ethernet, and its PoE sibling runs on the same Fast Ethernet link, so a single cable reaches the station:

If some serial ports sit on cards in an expansion base rather than the main rack, the base-to-base cable is part of the serial path: when only the expansion-base scanners drop characters, reseat and check that interconnect first. The expansion base cable wiring and specifications page covers the connector pin-out.

Land the ASCII in the right bytes

One 16-bit register holds two characters. Whether the first character of a pair lands in the high byte or the low byte is set by the port and the instruction that fills the block, and swapped packing is the classic reason a scan of 3211 appears shuffled after an ASCII-to-hex conversion. Prove your packing in five minutes with a test label printed 0123456789AB: the first register should read 0x3031, which is 01 in arrival order. If it reads 0x3130, the bytes are swapped - fix the packing before any compare logic exists, because a swapped string rejects every valid scan and looks exactly like a compare bug. The byte-level mechanics, including clears between scans, are laid out in storing ASCII barcode strings in PLC memory.

The terminating CR is your completeness signal: raise the new-data flag on it, never on a register-count guess.

Size the table before you write logic

Worked example, the numbers used throughout this article: 12-character IDs, three fields per row, 40 allowed combinations.

• Registers per row: 3 x (12 / 2) = 3 x 6 = 18 registers.
• Table size: 40 x 18 = 720 registers, about 1.4 kB of retentive memory.
• Full-table compare: 40 x 3 = 120 string compares, each over 6 registers.
• Line time per scan at 115200 baud with 8N1 framing, 10 bits per character: (12 + 2) x 10 = 140 bits; 140 / 115200 = 1.2 ms. At 9600 baud the same scan takes 140 / 9600 = 14.6 ms.

The compare waits for the terminator, so line time only delays the flag. With a 10 ms scan the permissive sets within two scans of trigger release: 14.6 ms of line plus up to 20 ms of scans is about 35 ms at 9600 baud, and about 21 ms at 115200. Where the scan-to-flag path must be tighter still, cutting serial scan-to-flag latency breaks down every delay in the chain.

Comparing the part column first shrinks the worst case: if the scanned part matches 8 of the 40 rows, the pass does 40 part-compares plus 8 x 2 = 16 field-compares - 56 compares, not 120. The knob that moves table size is ID length: at 8 characters the 40-row table is 40 x 12 = 480 registers; at 16 characters it is 960.

Steps: from scanner to latched permissive

1. Configure all scanners identically: ASCII output, CR LF suffix, no prefix, 115200 8N1 on serial. Scan a test label at each station and confirm the string on the HMI before touching the PLC.
2. Map one register block per scanner - 6 registers plus a new-data flag each at 12 characters - and one string per block. A shared buffer for five scanners is the fastest way to cross-couple stations.
3. Clear every block and flag at cycle start, so a run cannot inherit the previous run's badge scan. Only cycle start and the timeout clear; the compare routine never does.
4. Build the table as 40 rows of 18 registers of padded strings, with the row count in a register the compare loop reads. Put edits behind a supervisor-level HMI page and bump a version register on every edit.
5. On each new-data flag, walk the table with an indexed pointer: compare the part column first, and only in rows where it matches, compare the fixture and operator columns.
6. Latch a set-dominant coil - call it RunOK - the moment one row matches in all three columns, and latch a reject code when a scan fails:

7. Reset RunOK and the reject codes on cycle stop, never on the next scan: the permissive must survive until the run ends, which is why it is latched.

The one-scan lifespan of a raw scanner string, and the latch that fixes it, are covered in a barcode string that disappears after one PLC scan - the same pulse that latches your data fires the compare.

Rejects, timeouts and re-scans

Hold a matched flag per field. When the fixture compare fails, clear only the fixture block and leave part and badge latched; the operator re-scans one label, not three. Run the partial-set timeout at 60 s from the last accepted scan - long enough to fetch a badge from a drawer, short enough that a half-entered set cannot survive a shift change - and let it raise reject code 4 and clear all three blocks.

Matrix or three lists

Build the row-keyed matrix: one row per allowed part-fixture-operator combination. It is the only structure that rejects a valid operator on the wrong part, which is the failure the matrix exists to catch. Three independent allow-lists - say 20 parts, 8 fixtures and 30 badges at 6 registers each, 58 x 6 = 348 registers - are smaller, but they pass any combination of individually valid IDs, and if any combination truly is allowed you do not need this station at all. Keep the matrix and pay the 720 registers.

Tests that prove the station

• Valid row: scan a known-good part, fixture and badge. RunOK latches within two scans of the last character.
• Wrong fixture: right part, wrong fixture tag. Reject code 2 latches, RunOK stays off, and re-scanning the correct fixture clears only code 2.
• Timeout: scan two of the three fields and wait. At 60 s the blocks clear and code 4 appears.
• Wiring mixup: swap two scanners' cables at commissioning. Each string must still land in its own block - this test catches mislabeled stations in minutes instead of at the first audit.

When the usual answer is wrong

• The two-reader compare answers the wrong question at a run-start station: agreement between scanners is not membership in the allowed set.
• An ASCII-to-integer compare strips leading zeros and rejects letters outright: badge OP-0042 either fails conversion or matches 42. Strings only.
• A prefix compare on the first 6 characters lets P-4821-A pass for P-4821-A2. Always compare the full padded length.
• Table edits from the operator screen: one space typed where a hyphen belongs stops the line on a perfectly valid part. Supervisor page, version register, logged edits.
• A keyboard-wedge feed is not verification: wedge scans go to whatever window has focus and never touch the table.

Commissioning checklist

• All scanners: ASCII out, CR LF suffix, no prefix, fixed 12-character padding
• One register block and one new-data flag per scanner, cleared at cycle start
• Byte-order test label 0123456789AB scanned; first register reads 01
• Table sized at 18 registers per row times the row count, with row-count and version registers
• Compare on the new-data pulse, part column first
• Set-dominant RunOK latch, reject codes 1-4, 60 s partial-set timeout
• Table edits on a supervisor-level HMI page only
• All four commissioning tests logged against the table version that passed them

Scanners for the station

Operators scan by hand, so start in handheld code readers and filter on a wired interface that matches your ports. Where a mid-run part re-check pays for itself, add a fixed code reader at the infeed reading against the same table - fixed barcode reader trigger modes covers triggering it from the PLC. Both families sit in the code reader finder, the scanner-side integration guides are collected on the code reading topic page, and once the scanner count is settled you can walk the system configurator end to end - or send us the station plan and we will check the register layout with you.