Barcode scanner keyboard wedge into an HMI: why scans drop over RDP

You scan a code, the tablet stays silent, and the HMI never receives the part number. The scanner is almost never the culprit: a device acting as a keyboard wedge sends its decode as ordinary keystrokes, and some layer between the scanner and the HMI session swallows them. This guide is for controls and software people connecting an integrated or handheld scanner to an HMI that runs through a remote-desktop session on a tablet. Three Notepad tests isolate the failing layer; then you fix framing, keyboard layout or keystroke timing, or decide that a fixed reader at the machine should carry the decode instead.

Why a wedge scan is only keyboard input

A scanner in keyboard wedge mode enumerates as an HID keyboard, exactly like the one on your desk. A scan types the decoded string and finishes with a terminator keystroke, almost always CR (Enter). The HMI's barcode scanner input component does not talk to a driver; it watches the keyboard event stream, waits for its prefix character, buffers until the suffix arrives, and commits the string. The whole scan has to land as one keyboard event.

That design carries three consequences. Focus decides which field receives the scan. The scanner's preamble and postamble must match the component's prefix and suffix. And every layer that forwards, filters or delays keystrokes, including a remote-desktop session, sits directly in the input path. The wedge basics for an HMI and the prefix and suffix framing rules cover the local case; the session layer adds its own failure modes, and the tests below separate them.

The symptom tells you which layer ate the scan

Match what you see against this table before changing any setting:

Each row is testable in minutes with the three tests below, run in order.

Test 1: scan on the tablet with no session open

1. Close the remote-desktop session and open any text app on the tablet itself.
2. Scan a code you know decodes cleanly.
3. Read what appears.

Clean text ending in a new line means the scanner and its suffix are healthy. Nothing at all usually means the integrated scanner outputs in a mode other than keyboard emulation; switch it to keyboard output in the scanner's own settings, because that is the only mode a remote-desktop session can carry. Text without the trailing new line means the CR suffix is off; turn it on there before blaming anything upstream.

Test 2: Notepad inside the session

1. Reconnect the session, open Notepad inside it, and click into the Notepad window.
2. Scan the same code.
3. Compare the result against the table above.

Nothing arriving here, with Test 1 clean, is the signature remote-desktop failure: the client forwards typed keys but drops the integrated scanner's input. Field reports describe exactly this pattern, including tablets where an older client app passed scans that a newer one drops. If a second client app is installed, test it and keep whichever passes. USB redirection software is the other escape route: it shares the scanner to the remote host as if it were plugged into the server, bypassing the client's input stack entirely. Garbled characters point to the layout fix below; truncated codes point to timing.

Test 3: a different client on the same session

1. Open the same session from a desktop PC.
2. Plug in a USB handheld reader from the handheld code readers range.
3. Scan into Notepad inside the session.

A clean decode here proves the server, the network path and the HMI are healthy, and isolates the fault to the tablet client's handling of its integrated scanner. The practical decision follows quickly: an external USB reader on the tablet restores scanning today while you chase the client app at leisure. A USB handheld enumerates as a keyboard exactly like the integrated one, so every fix in this guide applies to it too. To leave the keyboard path entirely, the HID keyboard or serial port choice explains the alternative and its wiring.

Worked example: delay budget for a 22-character code over a 50 ms link

A session carries each keystroke as a round trip, so characters typed faster than that round trip can overtake and drop. Many scanner configuration tools offer an inter-character delay option; the value comes from a measurement, not a guess.

• Inputs: N = 22 typed characters before the suffix, assumed here and replaced with your code's length; 1 suffix keystroke (CR); R = 50 ms round-trip to the session host, measured by pinging the host from the tablet; d = the inter-character delay set in the scanner's configuration.
• Rule: a keystroke cannot arrive faster than the slower of d and R, so set d ≥ R to keep characters in order. Entry time is T = (N + 1) × d.

• Arithmetic: N + 1 = 23 keystrokes, and T = 23 × 50 ms = 1150 ms ≈ 1.2 s.
• Result: the full code commits about 1.2 s after the trigger pull.
• Decision: hold 2 s per scan as the working ceiling for operator-triggered scanning. At R = 50 ms the budget passes. If the ping shows 150 ms across a remote link, T = 23 × 150 ms = 3450 ms ≈ 3.5 s, past the ceiling. Do not stretch the delay further; move the decode server-side, as the next section describes.

The fixes, in the order that pays

1. Framing first. Set the scanner preamble empty and the postamble to CR unless the component documents a prefix, and configure the component to match. Raw characters appearing as text in the field mean the two sides disagree; configuring a barcode scanner input component to append scans walks through that commit behaviour, and CR and LF characters in an HMI text field explains what the terminator does on arrival.
2. Layout second. Set the client and the session to the same keyboard layout. A wedge types characters for the client's layout, and a session interpreting them with another layout swaps characters.
3. Timing third. Apply the delay from the worked example, measured at the worst spot the operator scans from.
4. Focus fourth. The scan lands wherever focus sits; the focus rules for wedge readers in an HMI cover keeping the input field ready.
5. Then the platform. Plain capture needs no paid barcode module: a text input component plus a script on the committed string triggers the action, and add-on modules earn their cost later, for parsing and lookups on every scan. For the same wedge method on another SCADA platform, barcode reader integration by keyboard wedge shows the pattern end to end. When a scanner types correctly but the HMI still misses keystrokes, a USB keyboard emulation fix for an HMI that drops scanner input documents the remedy.

When to leave the wedge behind

A wedge through a tablet session is right for occasional, operator-triggered scans: walk-around checks, material moves, verifying a bin at a station. It is the wrong path for line-side reading, where every part must decode every cycle. Keystrokes through a session inherit the network, the client app and focus as failure points; a fixed reader at the machine removes all three by sending decodes over Fast Ethernet or serial straight to the PLC or the HMI server. Plan that link with the barcode reader PLC communication checklist, match the reader's client or listener role using the raw TCP connection modes, and compare the physical options in serial, USB and Ethernet input methods.

For line-side points, a compact fixed reader such as the MV-ID3013PM-12M-WBN pairs a 12 mm focal length and a 1.3 MP sensor with a Fast Ethernet interface and an M12 mount, and the finder at fixed code readers filters the rest of the range by interface, resolution and mount.

At a bench or check fixture, close range does the job: the LS-CRD-0047 reads at 60–120 mm and connects over USB 2.0. Mounting brackets, lens covers and I/O boxes for these readers sit in the code reader accessories category.

Walk-around use that must stay on the tablet keeps the keyboard path, but a wired USB handheld replaces the integrated scanner with framing and timing you set yourself.

Keep it working: the go-live checklist

• Run Tests 1–3 and record the outcome at each layer before the station goes live.
• Pin the client app version that passed Test 2, and rerun Test 2 after every client update.
• Set the inter-character delay from a ping taken at the worst scanning spot, and re-measure after any network change.
• Keep client and session keyboard layouts identical, and write the layout into the station's build notes.
• Set the scanner postamble and the component suffix together, and store both values with the station documentation.
• Reserve the wedge for operator-triggered scans; put a fixed reader anywhere the line itself demands a decode.

If you are selecting hardware for the machine-side path, the code reader finder filters both ranges, the system configurator walks through camera, trigger and connection choices, and the code-reading guides collect the rest of the integration topics. For reader selection or an interface question on a specific station, contact us and we will work through it with you.