USB barcode scanner as a keyboard wedge into your HMI

You plug a USB code reader into the tablet that runs your HMI web client, pull the trigger, and the scan either appears in the wrong place or never appears at all. The reader is almost never at fault. In keyboard-wedge mode it types ordinary keystrokes, and keystrokes land wherever the cursor is. This guide is for engineers and integrators wiring handheld or fixed USB readers into HMI input fields, browser clients included. You will set the Enter suffix, hold focus on the target field, route multi-field forms, and run the character-count test that proves the link before go-live.

What does a keyboard-wedge scanner send to the HMI?

In USB keyboard-wedge mode the reader sends standard HID keyboard keystrokes: one keypress per code character plus the suffix, usually a carriage return, typed exactly as a keyboard would type them, so the HMI cannot tell the reader from a keyboard and focus alone decides where the scan lands.

That is the whole contract. The tablet's operating system enumerates the reader as a standard USB keyboard and loads its own class driver, so no vendor software is installed anywhere. Everything that shapes the scan — interface mode, suffix, prefix, keyboard layout — lives in the reader and is programmed once by scanning setup codes from its manual.

The link is also never your bottleneck. A USB keyboard endpoint is polled typically every 8-10 ms, so a 13-keystroke scan line crosses in roughly 0.1-0.15 s, against an operator cycle of one to two seconds per scan. If a device on your bench only speaks RS-232 while the host only accepts keystrokes, serial-to-USB wedge conversion for devices that only speak serial bridges the gap. The full trade-off between keyboard, serial and network interfaces is in barcode scanner input methods to a PLC: serial, USB and Ethernet, and the HID-versus-serial decision on a PLC HMI specifically in USB barcode scanner on a PLC HMI: HID keyboard mode or serial port.

Decision: with an operator at the screen, HID wedge is the cheapest link that works; with no operator, plan a port-based interface from the start.

How do you set the Enter suffix on a USB barcode scanner?

Scan the setup barcode for the carriage return suffix once, from the reader's programming manual; a large share of readers already leave the factory appending Enter, so read into a plain text editor first and program only what the test shows missing.

The setting is stored in the reader and survives power cycles. A doubled suffix is easy to spot: the code lands, then an empty line follows every scan. Choose one suffix and keep it: Enter commits the field, Tab advances focus to the next control. On an input field that writes a tag when Enter arrives, that commit is exactly the behavior you want — the same flow as barcode scanner to HMI IO field: commit tag data with Enter. Framing choices, prefixes and per-symbology suffixes are compared in prefix and suffix framing for barcode scanner input, and codes whose length varies are covered in variable length barcode scanner input: fix it with a suffix.

Any wired USB handheld in the handheld code readers range behaves as a keyboard on a tablet out of the box:

For a fixed mount at a kiosk, the LS-CRD-0047 reads a label presented at 60-120 mm and connects over USB 2.0:

Decision: test in a text editor first, program only the suffix you are missing, and keep a single Enter unless a multi-field form needs Tab.

How do you keep the HMI input field focused?

Treat focus as the integration: the scan types into whatever control holds keyboard focus, so set focus on the target field when the page opens, restore it after every dialog and button, and require that the first keystroke after any screen change lands in the field.

Two mechanisms carry it. Set focus by script when the display opens: nearly every HMI platform exposes a way to give keyboard focus to a named input field, so wire that call to the page-open event and the field is live before the first scan. Then restore focus after everything that takes it — confirmation dialogs, alarm pop-ups, date pickers, a plain mouse tap.

The acceptance rule is binary: after any screen change, the very next keystroke must land in the target field. If your platform offers no way to set focus from a script or event, the wedge is fragile by construction — every dialog breaks the link until someone taps the field again. That is the moment to change interface, not to tape a note over the screen saying "tap here first".

Decision: put the focus call on page-open and after every modal, then prove it with the screen-change test below.

How does focus behave in a web client on a tablet?

In a browser-based client the wedge behaves as on any desktop HMI, with two tablet traps: the browser chrome and the on-screen keyboard can take focus, so run the client full screen, keep the input clear of the keyboard zone, and re-test after lock and wake.

Run the client full screen — the browser's kiosk or full-screen mode — so the address bar and tabs cannot receive keystrokes. Then two tablet behaviors need a test on your hardware. Script-set focus often does not raise the on-screen keyboard, which is exactly what you want when the reader is the keyboard; some tablets still pop it up over the field, so place the input above the keyboard zone or hide the keyboard from its own control. After a screen lock or a cable unplug, the browser can hold no focus at all, so the first scan after waking goes nowhere until someone taps the field.

A camera widget such as the QRCode_Scanner widget that some web clients ship decodes from the tablet camera, but at a bench a USB reader is faster and steadier; the two can share a page, the widget for one-off scans at a desk, the wedge for the line.

Mind the cable as well: USB 2.0 allows up to 5 m of cable, so keep the reader within reach of the tablet or behind a powered hub; longer runs need an active extension, and short shielded cables are in the cables range.

Decision: full-screen client, input placed clear of the on-screen keyboard, and a lock-wake-rescan check added to the commissioning list.

How do you route scans to several fields on one form?

Use a Tab suffix when the form's field order is fixed and one scan fills one field; embed a field number in the barcode data and parse it when scans can arrive out of order or different codes must reach different fields.

With a Tab suffix, one scan fills one field and focus walks the form in order: part number, then lot, then quantity. That holds while the operator fills fields in sequence and never skips one. Once order breaks down, embed the field number in the barcode data — a documented pattern is a leading digit that names the destination field — and parse it before it reaches the control. Barcode scanner regex parsing: prefix, suffix and capture groups shows the capture-group mechanics. Many platforms can also advance focus automatically when a field receives its Enter, so the operator never touches the screen; where a SCADA client fights wedge input altogether, a keyboard-wedge integration method for a SCADA host documents the field-by-field focus pattern.

Decision: fixed field order takes a Tab suffix; out-of-order or mixed codes take field numbers and a parser; never rely on a tap to pick the field.

Why does a scan arrive with missing or wrong characters?

Start with focus and keyboard layout, not the reader: characters missing means focus moved mid-scan, characters wrong means a layout mismatch between reader and host, nothing at all usually means the reader is in serial mode rather than HID, and flaky behavior points at USB power.

Work down the list; each cause has a one-minute test:

1. Focus moved mid-scan. The line transmits in roughly 0.1 s; a pop-up or timer that steals focus inside that window sends the tail of the code into the new control. Test: scan with your worst pop-up armed and nothing else changed.
2. Keyboard layout mismatch. Readers default to a layout that may not match the host's; digits survive, punctuation and shifted characters do not. Test: scan a code containing dashes; fix by setting the same layout on reader and host.
3. Reader is in serial, not HID mode. No keystrokes arrive and nothing is electrically wrong. Test: scan into any text editor; in serial mode it stays empty until software opens the port.
4. Power or adapter trouble. Intermittent disconnects and garbage point at the USB link; the checks in barcode scanner power and interface checks for USB adapters sort adapter-powered setups out fast.
5. A stray prefix. One character precedes every code, usually left from an earlier setup. Test: the character count in the next section exposes it immediately.

Some Windows SCADA clients also drop wedge keystrokes on particular controls; a documented USB keyboard-emulation fix for a Windows SCADA client covers one such case.

Decision: characters wrong, suspect layouts; characters missing, suspect focus; nothing at all, suspect mode; flaky, suspect power.

How do you test the wedge link before go-live?

Prove the link in a plain text editor before touching the HMI: a 12-character code must produce a line of exactly 13 characters — 12 data characters plus the Enter suffix — with the cursor on line 2; then repeat the same checks inside the real HMI field.

Then run six checks:

1. Editor baseline. Scan one code into a plain text editor 10 times; require 10 identical lines.
2. Character count. For the 12-character code, the line must hold exactly 13 characters and the cursor must sit on line 2. Fourteen means a prefix is programmed, twelve means the suffix is missing, symbol soup means the layout mismatch above.
3. Focus-loss test. Tap a neutral area and scan. The correct result is that nothing happens — proof you can see a stray scan instead of writing it into production data.
4. Screen-change test. Walk three screens away and back, then scan; the first scan must land in the field, not in a search box.
5. Rate test at the real pace. Scan 20 codes at shift pace — one every 20 s, which is about seven minutes of running. Intermittent focus losses appear here, not in a burst test.
6. Tablet traps. Rotate the tablet, sleep and wake it, unplug and replug the reader once; re-run the editor test after each.

Decision: go live when all six pass on the hardware you ship, not on a desktop PC standing in for the tablet.

When is a keyboard wedge the wrong interface?

Choose the wedge when an operator stands at the screen and one field is always active; choose USB serial, Modbus, EtherNet/IP or a raw socket when scans arrive unattended, when the host is a PLC, or when the rate exceeds anything a person types.

A PLC has no keyboard to receive keystrokes, an unattended gate has no operator to hold a field, and no focused field keeps up with machine rates. Those stations want data over a port: Modbus RTU as in read a barcode reader into a PLC over Modbus RTU, implicit I/O over EtherNet/IP as in Ethernet IP barcode reader to PLC: map the implicit I/O assembly, or a raw socket as in TCP client or listener: match your network barcode reader to your host. Mountable readers for those paths sit in the fixed code readers range; for an unattended gate a Fast Ethernet reader such as the LS-CRD-0028 decodes up to 60 codes/s with no focus to manage:

Decision: attended screen work takes the wedge; anything a PLC or an empty room has to read takes a port.

Start from the interface, then the reader: if operators work at the screen, the camera and code reader finder lands you on wired USB models, and the rest of the work is the suffix, focus and the six tests. The systems topic page collects the companion guides on serial, Modbus and EtherNet/IP links, the station configurator sizes the rest of the set-up, and if a station design keeps fighting you, contact the applications team.