Two barcode scans into separate HMI data entry fields

The operator scans a part label, then a lot label, and both values must land in two separate ASCII fields on the same HMI popup. In practice the first scan fills its field and the second either overwrites it or vanishes, because an entry object consumes every character that arrives while it is enabled and does no routing of its own. The fix is architectural, not a buried setting: arm one field at a time through its enable bit, terminate every scan with a programmed suffix, and let the PLC interlock the two arms. The procedure works with a wired handheld reader, needs no vendor-specific trigger feature, and takes about an hour to configure and prove. It is written for controls engineers and integrators wiring a reader into an operator data-entry screen.

The rule: the enable bit routes the scan, the suffix commits it

An HMI ASCII data-entry object is a receiver, not a router. It takes characters from the scanner while its input is enabled and stores what it gets in its own address. Where the screen software offers bit control, the object's manual describes it plainly: data entry is enabled by turning a designated bit ON, and the entry ends when the bit goes OFF. That bit is the routing mechanism.

The workflow therefore reduces to four states: arm the part field, scan, arm the lot field, scan again. The suffix does not choose the field — a reader sends the same string on every trigger. Its only job is to end the entry at a known point, so the object commits the payload instead of waiting for more characters. Enter, the carriage return (ASCII code 13), is the terminator to program for HMI entry fields.

The decision in one line: arm, scan, commit, arm the next field. If both labels are always presented together, skip to the one-scan set-up near the end.

What you need

• A handheld code reader with a programmable suffix and an output the panel accepts — USB or Ethernet. Browse the handheld code readers by interface and resolution.
• An HMI project with two ASCII data-entry objects whose input can be enabled by a bit address.
• Two arming sources: touch buttons on the popup or physical selector inputs writing PLC bits.
• One target tag per field, sized with the formula below, plus a done flag and an unclaimed-scan counter.
• Interlock logic in the PLC, or in panel-local logic, that keeps one arm bit ON at a time.

Wired handhelds from the shop fit this pattern:

The LS-HCR-0001 is a 1.0 MP handheld reader with a USB 2.0 interface.

Program the suffix before anything else

Set the reader so every symbology it decodes sends Enter after the payload. You program this once, in the reader's setup tool or by scanning the configuration codes printed in its manual. The prefix and suffix framing guide shows how the suffix frames the payload on the wire. The HMI side must expect the same terminator: the commit-with-Enter pattern walks that handshake for one field, and nothing changes here except that two objects share it.

Keep Tab out of the panel. A Tab suffix belongs to PC hosts, where it moves focus: in a spreadsheet data-entry flow a Tab-terminated scan really does jump to the next column, as in adding a Tab function for spreadsheet data entry. A panel entry object has no focus order to jump through, so the Tab arrives as ordinary data and lands inside your string.

Wire the two-field sequence

1. Assign each code to a field, and to its own symbology if the two labels differ.
2. Place two ASCII entry objects on the popup and set each entry length to payload + 1 characters — 9 and 13 in the worked example below.
3. Bind each object to its own tag, packing two ASCII characters per 16-bit register; the ASCII string storage guide walks the byte and word layout.
4. Enable each object's input by bit: one address for the part field, one for the lot field. The entry opens when the bit turns ON and ends when the bit goes OFF.
5. Drive the two bits from the touch buttons or the selector inputs, and hold each pulse for at least 200 ms. Panel and PLC task cycles run in the tens of milliseconds, so a shorter pulse can be missed entirely.
6. Where the screen software offers an after-write action on entry objects, put the data transfer to the final tag and the done flag there. Where it does not — a few panel families reserve that trigger for their newer series — let each object write its final tag directly and set the done flag from the PLC when the terminator lands.
7. Interlock the arms in the PLC: only one arm bit ON at a time, the second arm blocked until the first done flag sets, and every character received with no field armed counted as an unclaimed scan with an alarm.
8. If you took the symbology route, send the reader the symbology-select command at each arm so only the expected code type decodes.

The worked example: part number plus lot code

Set-up: the part number is a Code 128 symbol of 8 characters, the lot code is a DataMatrix symbol of 12 characters, and the reader appends Enter (CR) to both.

Entry lengths: part field 8 + 1 = 9 characters; lot field 12 + 1 = 13 characters.

Tag sizes: one ASCII character is one byte. The lot payload needs 12 bytes, which is 12 / 2 = 6 sixteen-bit registers with two characters packed per register, or 12 registers at one character per register. The part payload needs 8 bytes = 4 registers packed or 8 unpacked.

Delivery time, serial case: at 9600 baud with 8 data bits, no parity and one stop bit, every character costs 10 bits on the wire. The lot scan puts (12 + 1) × 10 = 130 bits on the link, and 130 / 9600 ≈ 13.5 ms. The part scan is 9 × 10 = 90 bits ≈ 9.4 ms.

Delivery time, USB case: the same 13 characters travel as keyboard reports, roughly one per millisecond on a full-speed USB port, so the string lands in about 10-15 ms.

Commit and operator cycle: once the CR arrives, the object writes its tag within a panel task cycle or two — tens of milliseconds. The operator presses the part button, pulls the trigger, presses the lot button, pulls again. A handheld decode typically takes a few hundred milliseconds, so the whole two-field entry lands in 3-5 s including handling. The decode figure moves with code size and presentation; the delivery figures move with the port and its settings.

Verify it worked

Run four tests with the real production labels before the screen goes live:

• Single arm. Arm the part field only and scan the part label. The value appears in the part object and nowhere else.
• No arm. With both bits OFF, scan anything. No field changes and the unclaimed-scan counter increments.
• Character for character. Compare the PLC tag against the printed code, length included. A missing or doubled terminator shows up as a truncated string or as leftover characters at the end.
• Pacing and order. Two scans 1 s apart, armed in sequence, must both commit. Then arm the lot field first and scan the part label: without the symbology command it files into the lot field, which is the system working as designed — and the reason the interlock and the symbology select exist.

If the pacing test swallows the second arm, lengthen the pulse to 200 ms and repeat.

Common mistakes

• Both fields armed. The panel assigns the characters; the operator cannot. One arm ON, always.
• No suffix programmed. The entry waits for its terminator, never commits, and the next scan appends to the same string. Program Enter on every symbology the reader outputs.
• Entry length set to payload only. If the object must hold the terminator as well, a 13-character entry truncates a 12-character lot code plus CR. Size fields as payload + 1 unless your object strips the terminator itself.
• Tab-based routing. Focus tricks are PC habits; on a panel the Tab becomes data inside the string. Route with the arm bits.
• Arm pulse shorter than the logic cycle. A one-cycle pulse is easily missed; hold 200 ms.
• One field permanently enabled. Both scans then land in that field and the second overwrites the first. Sequence the arms.

When one scan should carry both fields

If the operator always presents both labels together — a completed assembly shown to a station camera — drop the sequencing. Frame a fixed reader so both codes sit inside its field of view: it reads them in one presentation and reports both values, and the PLC splits the string by separator or fixed position. Sort the two values by symbology or by a fixed index in the message, never by read order, because the order in which codes report from a single frame is not deterministic. The field-splitting guide shows the parse and the TCP client or listener choice covers the Ethernet link to the host. Start from the fixed code readers or from these two:

The MV-ID3013PM-12M-WBN combines a 12 mm focal length with a 1.3 MP sensor on a Fast Ethernet interface. The LS-CRD-0047 reads at 60-120 mm over USB 2.0, close-range work at a bench fixture.

Before you go live

• Suffix programmed on every symbology the reader can output — the missing one is the scan that never commits.
• One arm bit ON at a time, enforced in the PLC, not just by the screen layout.
• Entry lengths at payload + 1 and tag sizes matched to the objects, so a long scan cannot drop characters silently.
• The unclaimed-scan counter and alarm routed to something an operator actually watches.
• Arm bits defined to start OFF after a panel reboot or a power loss, so a stale scan cannot file at start-up.
• All four verification tests run with worn, glossy or slightly skewed production labels, not fresh test printouts.

Next step

Pick the reader by interface and reading distance from the two categories above, then check the input methods overview for how the characters reach the host. The camera finder filters code readers by interface, resolution and shutter type.

For more wiring at this level, the systems topic page collects the guides. If your routing is unusual — a proprietary host, mixed symbologies on one label, or a tight cycle — describe the sequence on the contact page and we will help you spec the reader and the data path.