Scan a barcode to select a recipe on your HMI

Operators pick recipes from a scrolling list, and a pick made from two screens away loads the wrong parameters into a running machine. A barcode on the job traveler or the part carton replaces that list with one scan: no typing, no searching, no wrong-row picks. The wiring path is the same on any panel: the scan lands in a text-entry object, the PLC compares the scanned string against a short reference table, and the matching recipe index is written into the tag the recipe control already reads. This guide walks through the steps, the register arithmetic and the interlock that keeps an unknown code from starting the machine, plus the checks to run before you go live. You need a handheld code reader at the panel and an hour of ladder work.

Why the recipe control cannot read the code

A recipe control is an index selector. It shows and loads the recipe whose row number matches a tag in the controller. It has no keyboard path and no way to search by the text inside a code, so a scan aimed at it does nothing — the dead end most integrations hit first.

The working route treats the scan as data entry. The reader types the code into a text-entry object, the characters land in a controller tag, and the controller converts content into index. That conversion is the whole project; everything below builds it.

How the characters reach the tag follows the connection. A USB reader presents itself to the panel as a keyboard and types into whichever field holds focus, which is the keyboard wedge path. An Ethernet or serial reader delivers the decoded string as a message the controller reads directly, with no focus to manage. The trade-offs sit side by side in barcode scanner input methods to a PLC.

What you need

• A reader at the panel: a USB handheld that types into the entry field, or an Ethernet handheld that joins the controller network directly.
• Recipe codes printed on the travelers or cartons, Code 128 or a 2D symbology such as DataMatrix.
• A text-entry object on the recipe screen, bound to a tag sized for the longest code you will scan.
• A reference table in the controller, one row per known code, each row carrying its recipe index.
• A recipe-valid bit wired into the machine start circuit.

Both readers below connect over USB and type into the focused field like a keyboard, which is all the wedge path asks of them.

If the panel already sits on the controller network, an Ethernet handheld delivers each scan straight to the controller and skips the wedge altogether.

Step 1: Scan into a text-entry object

1. Add a text-entry object to the recipe screen and bind it to a new tag, sized for the longest code you will ever scan rather than the labels running today. If the panel offers both HID and serial modes on its USB port, the wedge needs HID keyboard mode (HID keyboard mode or serial port).
2. Set the reader's suffix to a carriage return so each scan commits the field on its own. Then confirm what actually arrives in the tag: a stray line feed can split one code across two fields, which the CR and LF characters guide untangles.
3. Tap the field and scan a traveler, then check that the tag holds the complete code, every character, before you write any compare logic.
4. Give the entry field a permanent home on the screen. An operator who leaves for another page and comes back expects the next scan to land; the fixes for lost focus are in the keyboard wedge focus guide, and configuring auto-advance focus after a barcode scan covers the SCADA case.

Step 2: Hold the scan in controller memory

The text-entry object writes ASCII into the tag: one character per byte, two bytes per 16-bit register. Clear the tag ahead of each new scan, or run a length check in front of the compare, so a short code cannot match the tail of the previous one. The register layout, byte order and the clears are laid out in storing ASCII barcode strings in PLC memory.

Step 3: Cross-reference the code to a recipe index

Run this logic on every controller scan cycle, against the entry tag:

1. Length check: leave the valid bit off unless the tag holds exactly the expected number of characters.
2. Compare the tag against each reference code in the table, one row at a time.
3. On a match, move that row's recipe index into the recipe selector tag and set the recipe-valid bit.
4. With no match, write zero to the selector tag and reset the valid bit.

No timer or handshake is needed: the logic runs every cycle, so the index is current within one or two scan cycles of the characters landing in the tag. The string compare itself is a handful of rungs. The pattern in PLC ladder logic to compare barcode strings adds a three-good-reads count before accepting, worth borrowing where a smudged label can flip between values. Where the code carries more than the part number, parse the fields first and compare the field you select on (split barcode string into fields).

Worked example: a five-character code onto recipe 2 of 3

Say the travelers on the line carry five-digit codes — 48215, 48216 and 48300, printed as Code 128 — and the panel holds recipes 1 to 3. That is this article's scenario scaled to three products; substitute your own codes and recipe count.

Inputs, with where each comes from:

• Label content: five characters per code, set by the label artwork (48215, 48216, 48300).
• Entry tag: three consecutive 16-bit registers, bound to the text-entry object.
• Reference table: 48215 → recipe 1, 48216 → recipe 2, 48300 → recipe 3, entered as constants in the ladder.

The rule in words: ASCII stores one character per byte and a 16-bit register holds two characters, so size the tag for the longest code, then compare whole tag against whole reference with the length check first.

An operator scans 48216. The length check passes at five characters, the compare matches row 2, and the ladder moves 2 into the selector tag and sets the valid bit, so the recipe control loads recipe 2 within the next one or two scan cycles. A torn label that decodes as 48299 — five characters, but in no row — matches nothing: the selector tag returns to 0, the valid bit drops, and the start circuit stays open. The acceptance threshold is one line: selector index at least 1 and at most 3, or the machine does not start.

Fixed readers: recipe selection with no operator

On a line where every part or pallet already carries a code, drop the panel entry entirely. Mount a fixed code reader at the infeed, connect it to the controller over Ethernet or serial, and run the same cross-reference on the delivered string — selection follows the part down the line with nobody scanning anything. The label decides the read rate, so check code size, reading angle and distance before the bracket goes on (module size, reading angle and reader distance); codes on shiny film or curved cartons need the lighting treatment in reading QR codes on reflective and curved surfaces. Over EtherNet/IP, map the reader's implicit I/O assembly into the controller (map the implicit I/O assembly); over plain TCP, let the reader act as server and the controller connect as client (barcode reader as TCP server).

The compact reader below pairs a 12 mm focal length with a 1.3 MP sensor on Fast Ethernet and an M12 mount, a fit for a code presented at a line infeed.

Checks before you go live

• Scan every code in the table once and watch the selector tag land on the right index; this proves each mapping row.
• Scan a plausible code that is in no row, same length, and confirm the tag goes to 0 with the valid bit off; this proves the interlock decision.
• Scan a half-covered label and confirm the length check rejects the short string instead of matching anything.
• Scan one good code twenty times in a row and require the same result every time; a marginal print shows up as flapping.
• Leave the recipe screen, come back, and scan; the code must still land in the field, because lost focus is the top cause of works-in-testing failures.
• Stopwatch a scan-to-recipe change; the recipe should switch within a second of the reader's beep, and a sluggish result points at the commit step, not the compare.

Common mistakes

• Aiming the scan at the recipe control itself: nothing happens, because the control takes an index and has no text path.
• No carriage-return suffix: the code sits uncommitted in the field until someone presses Enter, and panels differ in what writes the tag (commit the tag with Enter).
• A second scan appending to the first: clear the tag on every new scan so codes cannot concatenate.
• Scans that vanish over remote desktop: the wedge drops input across RDP sessions; the cause and fixes are in why scans drop over RDP.
• Comparing the raw string when the code carries lot or date fields: the extra characters break the match, so parse before you compare.

Draw the cross-reference table first — one row per code, one index per row — because it is the contract between the label shop and the ladder. Then choose the reader: start from the two code-reader categories above, or filter both by connection in the camera finder. If the mapping or the interlock could use a second pair of eyes, contact us — expert support comes with every order.