Keyboard wedge barcode readers and focus in your HMI

A keyboard wedge barcode reader — a USB reader running in HID keyboard mode — does not send its data anywhere in particular. It types. The host routes those synthetic keystrokes to whichever control holds keyboard focus, and in many HMI runtimes an Enter commit advances focus to the next control in the tab order. Hence the classic symptom: the first scan lands in the input field, every scan after it lands somewhere else. This page explains what the wedge interface does at the USB level, why focus walks away after Enter, and the two fixes that hold up in production — a dedicated single-field screen with tab index 1, or switching the reader to USB serial (CDC) mode so your code owns the string instead of the screen.

What a keyboard wedge reader really is

"Keyboard wedge" is a survivor's name from the days when readers spliced into the keyboard cable with a Y-adapter. Today it means USB HID. The reader decodes the code, converts the string into keyboard scan codes and sends ordinary HID keyboard reports. To the operating system it is a second keyboard; to the HMI it is indistinguishable from a person typing. Any program that accepts typed text accepts a wedge reader — no driver, no socket, no parsing code.

The cost is built into the interface: the keystroke stream carries no destination. Whatever control has focus receives the string, character by character, followed by the terminator the reader appends — usually Enter, sometimes Tab. If focus sits on the wrong field, the wrong field gets a perfect decode. The reader did its job; the screen was not listening.

Wedge is one of several USB personalities a code reader can present, and the choice is not cosmetic. Switching interface modes changes the reader's USB descriptors, so the host enumerates a different device class each time: an HID keyboard in wedge mode, a communications device (a virtual COM port) in serial mode. The optics and decoder are untouched; only the pipe the string travels down changes. Pick the pipe before the screen design, because it decides whether the HMI or your code owns the data.

Why focus moves after Enter

Most HMI runtimes keep a tab order so keyboard-only operators can work: Enter commits an input field, and focus advances to the next control in sequence. The runtime is behaving as designed — the scanner's Enter is, as far as it can tell, a user's Enter.

Script-side there is often nothing to fight back with. At least one major PC-based HMI runtime exposes no supported function to set a control's focus; the vendor confirmed in the release current at the time that the capability was not implemented, naming a later version as the earliest it might arrive. So "which script call sets focus" frequently has no supported answer. The design task is therefore not scripting focus back into place — it is making focus irrelevant.

Fix 1: one screen, one field, tab index 1

Give the scanner a dedicated screen or popup containing exactly one input field, set it to tab index 1, and remove or disable every other focusable control on that screen: no second field, no buttons the Enter can reach, no table cells that accept the caret. With a single focusable target, an Enter commit either returns focus to the same field or lands nowhere harmful, and the next scan types into the right place again.

Wire the commit, not the keystrokes. When the field's commit event fires, copy the string into the tag or record you actually care about and clear the field. If the runtime still walked focus, close and reopen the screen: a freshly opened screen starts at its first tab index, which is your field. The reader keeps typing regardless.

This fix suits shared terminals: goods-in desks, tool cribs, maintenance logging, any station where scans are human-paced and one screen owns the reader. For what happens after commit, see committing scanner data to an HMI IO field with Enter.

For the terminal itself, one handheld lives at the desk permanently, plugged into the host's USB port and typed into all day. A wired USB handheld such as the one below is built for exactly that seat.

Fix 2: switch the reader to USB serial mode

Set the reader's interface to its USB serial (CDC) mode and the problem dissolves. The host now enumerates a virtual COM port, and at each decode the reader writes the string to that port, framed by the terminator you configure — CR, LF, CR+LF or a custom suffix. Focus becomes irrelevant: the string goes to the port, not the screen. Your code opens the port, reads lines and puts the value where it belongs, whether that is an HMI variable, a database row or a PLC tag.

Two details decide whether this is painless:

• Terminator. Configure a suffix so every code ends cleanly, and make the parser expect exactly that. A CR sent where CR+LF is assumed leaves one stray character per scan, which reads like a hardware fault; the difference is spelled out in CR and LF characters in an HMI text field.
• Variable length. Read to the terminator rather than a fixed byte count, or short codes pad and long codes truncate; the fix is in variable-length scanner input, fixed with a suffix.

One program holds a COM port at a time, so decide up front whether the HMI script or a background service owns it. The wider trade between serial, USB and Ethernet paths is in barcode scanner input methods to a PLC, and the HID-versus-serial call for a PLC HMI specifically in HID keyboard mode or serial port.

Both readers below are wired USB models that suit a desk seat or a point-of-use mount.

Where the part comes to the reader instead, the LS-CRD-0047 is a compact fixed model: it reads at a 60-120 mm reading distance, with its 1.2 MP sensor carried over USB 2.0 — a reach sized for a label printer outfeed or a bench fixture, not a long throw. It does the same job with no operator's hand.

Worked example: when does the string arrive?

Take a Code 128 label carrying a 20-character serial number, read by a wedge reader that appends Enter.

• Events: 20 characters + 1 Enter = 21 keystroke events.
• A full-speed USB HID keyboard is conventionally polled on an interval of about 1 to 10 ms, so the string lands in 21 × 10 ms = 210 ms at the conservative end, or 21 × 1 ms = 21 ms where the reader bursts at the host's fastest rate.
• Add a decode in the tens of milliseconds and the whole code is on screen within roughly a quarter of a second of the trigger pull.

Those are the fast numbers. The slow number is the person: budget 1.5 to 3 s for an operator to notice that focus has wandered, grab the mouse and click the field back — longer with gloves on. The wedge interface is never the bottleneck; the human repairing focus is.

Decision from those inputs: at human pace — a scan every few seconds — a well-built single-field screen keeps up with room to spare. Once scans arrive faster than a person can rescue focus, or the station runs unattended, the serial path stops being the tidier option and becomes the only one that works.

Wedge or serial: which station gets which

Choose the wedge when one screen owns the reader and one field owns the screen: it works anywhere typed text works, with no code to maintain. Choose serial for everything faster or less supervised — production lines, unattended stations, HMIs that raise alarm popups, remote-session terminals, or any screen layout you cannot promise to keep simple.

When the usual answer is wrong

A multi-window runtime. An alarm popup or confirmation dialog can take focus between two scans, and the wedge types the next code straight into it. If the station shows alarms, this is not a tuning problem; use serial.

A script-triggered refocus. Some integrations give the reader a function-key prefix so a hotkey fires before the data (a function key sent before the data), hoping to run a script that selects the field. That only works if the runtime lets a hotkey start a script able to move focus — which, as shown above, many cannot. Ask that question before building a station on the idea.

Double-counted scans. An operator re-scans the same label and the log records it twice. A prefix only the reader sends lets the code tell scanner input from typed input; the framing options are in prefix and suffix framing for barcode scanner input.

A code longer than the field. A 24-character code into a field capped at 12 truncates or beeps, and the decode itself was fine. Size the field for the longest code you ship, or take the string in code.

Checks before you order

• Confirm the reader offers both USB personalities — HID and serial CDC — before planning a station around the serial path. Industrial readers commonly ship with both as a standard configuration item, set by setup code or utility.
• Size the cable run: passive USB 2.0 tops out near 5 m, so a terminal across the hall needs an active extension or a networked reader.
• Fix the terminator in writing — CR, LF or CR+LF — and make the reader and the parser agree before the first bench test.
• Draw the screen plan: which single field holds focus, what the commit writes, and how the screen regains its first tab index.

The decision per station

One operator, one screen, a scan every few seconds: a wedge reader plus a single-field screen at tab index 1 — nothing to script, nothing to parse. Unattended, multi-window, or scanning faster than a human can rescue focus: put the reader in USB serial mode, let your code own the string, and focus stops existing as a problem. The optics are identical either way; you are choosing the data pipe, not the reader.

If you are equipping a station now: handheld code readers for the desk seat, fixed code readers for the point of use. The plumbing from reader to host, screen by screen, is walked through in a USB barcode scanner as a keyboard wedge into your HMI, and more reader-and-code answers sit on the code-reading topic page. To pull a reader into a full station with trigger and cabling, start here:

Anything unresolved — mode lists, terminator choices, focus behaviour in your runtime — goes to the contact page and we will work it through with you.