Distinguish a scanned barcode from typed entry: prefix or timing

A shared text field cannot tell keystrokes from scans. A handheld code reader in keyboard mode and the operator's keyboard both deliver plain characters to the HMI. A 4-digit code keyed by hand looks identical to the same code scanned — until the wrong number reaches the record. The fix that holds up on the floor is a sentinel prefix: program the reader to prepend one character that never appears in your codes, then let the field reject anything that arrives without it. The steps below set the check up on a 4-digit station code, show the field logic, and work out the timing threshold that keeps getting proposed instead — with the arithmetic that shows why it cannot carry the decision on its own.

Why the field cannot tell a scan from typing

A reader in keyboard-wedge mode sends every character as HID keystrokes. The browser or HMI client that owns the text field sees key events and nothing else: no device name, no port, no marker saying where the characters came from. That is also why scans drop over remote desktop sessions: the client only ever sees keyboard traffic, and it handles that traffic on its own schedule.

Two properties can still separate the sources — the data itself and its timing. A character travelling inside the payload is a fact; the gap between characters is a probability. Serial and network readers escape the ambiguity because they never enter a text field at all, as the serial, USB and Ethernet input routes to a PLC show. What a keyboard-mode reader can frame around its payload — a prefix before, a suffix after — is covered in prefix and suffix framing for barcode scanner input. A browser text field receives all of it as one string, so the data has to carry the proof.

Set a sentinel prefix on the reader

One configurable handheld per station is the whole hardware list, and for a text-field workflow wired USB units are the straightforward pick:

1. Pick the sentinel. Tilde (~) is the usual choice for numeric codes: printable, outside the digit set, and it takes two keys on a standard keyboard, so nobody lands on it by accident. Any printable character your payloads cannot contain works as well.

2. Program the prefix. Open the vendor's setup utility or scan its programming barcodes and find the framing settings. Vendors name the field prefix, preamble or pre-character — the same mechanism under different names — and you enter ~ there while leaving the payload untouched. If the reader also sends an Enter suffix to commit the field, keep it: the logic below reads the front of the string and ignores the tail. Adding that suffix works exactly like adding an Enter key with programming barcodes, and the field side of the commit is the CR LF suffix setup for HMI fields.

3. Prove it in a plain text box. Scan into any unformatted input before touching the HMI. For a code 4711 you want exactly ~4711: one sentinel at the front, no stray characters, identical from every reader at the station. A reader that differs has a stale configuration — re-program it before any field work.

Validate and strip the prefix in the field

4. Put the check first. In the field's change event, test the value before any other script reads it. Three branches cover everything; value and payload are text strings, and the calls stand for whatever your platform calls clearing, committing and showing a message:

on change(value):                                    # value: text from the field
    if value == '':
        pass                                         # cleared between entries
    else if value starts with '~':
        payload = value without its first character  # payload: text
        commit(payload)                              # scanned code
    else:
        clear the field
        show 'Scan the code - typed entry is not accepted'

5. Strip the sentinel before the write. The record must store 4711, not ~4711, because downstream matches and check-digit routines compare the 4 digits. If your platform supports regular expressions, ^~(\d{4})$ validates the shape and captures the payload in one pattern; the capture-group mechanics are in barcode scanner regex parsing. The HMI side of the same framing — what arrives, what gets trimmed — is walked through in scanner suffix setup for HMI text entry.

6. Log every reject with a timestamp. After a week you will know whether typed attempts are fat-fingered digits or a missing scanner at that bench. The same timestamps feed the scan timestamps that track part cycle time per workstation, so the log does two jobs.

Verify it end to end: scan a known-good code and the record gains 4711; key those digits by hand and the field clears, shows the message and adds one reject entry.

Worked example: the timing window for a 4-digit code

Timing filters compare how fast the field fills. Here is the arithmetic for this station's layout.

Inputs. The code is 4 digits plus one Enter — 5 characters, the field layout this workflow uses. A keyboard-mode reader sends a short code back-to-back, so the whole payload lands in tens of milliseconds; 25 ms from first to last character is the representative mid of that range. For typing, 200 ms between keys is a deliberate pace, about 5 keys per second, and 125 ms is a rehearsed burst — the pace of an operator who keys the same code every cycle. The two typing figures are illustrative assumptions for a practiced line operator.

Rule. Measure the time from the first character landing in the field to the last; everything below a threshold counts as a scan.

Result. 250 ms sits ten times above the scan burst and half of the fastest typing, so on paper the filter separates the two, with a 2:1 margin on the typing side.

Decision. That margin lives on arrival times you do not control. The field measures when the client delivers characters, not when the reader emitted them: input queues, remote-session scheduling and wireless-dongle retries stretch the measured window, while a rehearsed operator shrinks the typing side toward it. A 2:1 margin misclassifies now and then in both directions, and each miss either blocks a good scan or admits a wrong digit. Keep timing as a soft warning — flag sub-250 ms fills as probable scans in the reject log — and let the sentinel carry the gate, because one character inside the data has no margin to erode.

When typing must be impossible

If the process rule is scans only, hardware beats field logic. Take the keyboard off the bench or fit a keypad without digits, and the 4-digit code cannot be mistyped at all — no sentinel, no filter. Mount the scanner at the station, so picking it up beats hunting for a keyboard.

Where the value must land in a database or a PLC, move the reader off the keyboard path entirely. A serial or Ethernet reader feeds the control system, which writes the accepted code to its own tag and hands the HMI a read-only display, so typed characters never enter that path. The TCP server route, with the PLC as the client, is the usual Ethernet pattern, and serial scan-to-flag response time shows the latency to expect once scans arrive as messages instead of keystrokes. For a text-field workflow that still wants the network, the wired Fast Ethernet handheld below connects to the plant network instead of a USB port:

Data identifiers: the standardized prefix

If you print the labels yourself, promote the sentinel to a standard. Data identifiers under the ANSI MH10.8.2 convention and GS1 application identifiers put defined leading characters in front of the payload, so the first characters tell every consumer — this field, the MES, the warehouse system — what follows. The field logic stays identical: check the front, route or strip. When one physical code serves several systems, the path-splitting pitfalls are in barcode reader module confusion across vision, MES and web paths, and routing two scanners into separate fields by their leading characters is in two barcode scans into separate HMI fields.

Checks before you roll it out

• Same sentinel on every reader. A stale unit without the prefix sends payloads the field rejects, and the first suspect will be the network, not the reader.
• Sentinel absent from every symbology at the bench. One 2D label that can carry a tilde and the field will eat a valid code.
• Reject clears and refocuses. Half a typed code left in the field merges with the next scan — the previous-value append failure is the classic result.
• Stored value re-checked. After stripping, validate length and any check digit, so a misread scan fails validation even though it passed the sentinel test.
• Reject log reviewed weekly. A rising typed-entry count usually means a dead or missing scanner, not worse operators.
• Shared readers planned. A reader carried to another station takes its prefix along; agree whether that station's fields accept or strip it.

Start from the handheld code readers category for configurable wired units, and code reader accessories for the covers, light boards and I/O parts that finish a bench. If the station has to prove data origin to a quality system, ask through the contact page with your field layout. More scanner-integration patterns sit on the code-reading topic page.