USB barcode scanner input without the on-screen keyboard

You scan a code at a robot pendant and the variable stays empty until someone taps the screen. On the previous controller generation, the same scanner filled the variable the moment it beeped. Nothing is wrong with the scanner: USB keyboard input goes wherever keyboard focus is, and the newer screen stops auto-focusing its input field. The pages below cover why HID keyboard mode behaves that way, why a firmware update can break a workflow that ran for years, and the two ways around it — switch the scanner to USB serial (CDC) mode and read a COM port, or move the scan onto the network — ending with a two-minute test and a pre-switch checklist.

Why does the scanner work only after you tap the screen?

Because a USB scanner in HID keyboard mode is a keyboard: every scan is typed, character by character, into whatever field holds keyboard focus, and until a tap puts the caret into the input field, the keystrokes arrive nowhere.

HID, the human interface device class, is the lowest-common-denominator USB device. Every host that accepts a keyboard accepts the scanner, with no driver and no configuration, which is exactly why scanners ship in this mode. The price is total dependence on the host's focus. The scan arrives as a burst of keystrokes — the code's characters, then the suffix, usually Enter — and the operating system hands them to whichever field owns the caret. There is no addressing and no channel: the scanner cannot say 'put this in the order variable'. If no field owns the caret, the characters die, exactly as typing does when no window is selected.

HMI packages state the same rule for keyboard-wedge input: the scan lands in whatever text box has focus. When focus is under your control, that makes the wedge the easiest input there is — USB barcode scanner as a keyboard wedge into your HMI covers that case. When focus is not under your control, it makes the wedge unusable.

Why did it work on the old pendant but not on the new one?

The older pendant generation opened its string-entry dialog with the input field already focused, so a scan typed straight into it; the newer generation raises the on-screen keyboard first and waits for a touch that places the caret before it delivers keystrokes.

Two entry points on a pendant of this kind take text: the operator-mode assignment screen, and the script call that requests a string from the primary client — request_string_from_primary_client("") in the program. On the older controller, the string dialog gave its field the caret on open; the on-screen keyboard appeared, a scan typed straight in, and the script returned with the code. The newer controller shows the same keyboard and waits: the field takes the caret only after a touch, and keystrokes sent before that touch are discarded.

Nothing about the scanner changed. The host changed what happens to keyboard input while the dialog opens, and a keyboard-wedge workflow inherits that behavior because it has no say in it. A firmware update that alters focus-on-load breaks this kind of station silently, on every machine, the day it installs.

Can you stop the on-screen keyboard from appearing at all?

Yes — take the scanner out of HID mode and put it into USB serial mode, where it enumerates as a virtual COM port (the USB CDC class); the scan becomes data a program reads from the port, and no field, keyboard or tap exists anywhere in the path.

The scanner stops being an input device and becomes a data device. Your program opens the virtual COM port like any serial port — 115200 baud, 8 data bits, no parity, 1 stop bit, no flow control — and reads each scan as one line. The other factory default you will meet is 9600 8N1; either works, as long as both ends match. What you pay is one settings change in the scanner and a short read loop on the host.

For a pendant variable this is the right interface whenever you can run, or add, a program on the host side. The operator scans, the line arrives, the variable updates, and the on-screen keyboard never enters the story. The same holds for kiosks, headless controllers and any screen an operator must not touch. The general HID-versus-serial decision, with the same reasoning for PLC HMIs, is in USB barcode scanner on a PLC HMI: HID keyboard mode or serial port, and it runs through the rest of code reading integration as well.

How do you switch the scanner to serial mode?

Scan the interface-configuration barcode from the scanner's manual, or set the interface in its setup utility, then replug: most industrial handhelds carry a USB serial or COM-port-emulation option next to HID keyboard, and one common manual numbers it 130 and lists it as the only non-HID USB interface.

1. Open the manual's interface section and find the serial-over-USB option. It goes by 'USB Serial', 'USB CDC' or 'COM Port Emulation'.
2. Scan that configuration barcode, or apply the setting in the vendor's utility. The choice persists through power cycles.
3. Unplug and replug the scanner. The host enumerates a COM port where a keyboard used to be.
4. Match the line settings on both ends: 115200 8N1, no flow control — unless the manual fixes 9600 as the factory default, in which case use 9600 or change the scanner.
5. Keep a carriage-return suffix so every scan is exactly one line.

A wired handheld with a plain USB 2.0 interface, such as the LS-HCR-0001, is the class of scanner this change is made on:

Interface is a filter, not a hunt: the handheld code readers category and the code reader finder both narrow by USB, Fast Ethernet and wireless. For a controller-side walk-through of the same cabling and enumeration, see configuring a barcode scanner on a controller USB port.

How do you read the code once it is a COM port?

Open the port, read to the carriage return, trim the suffix, write the string to the variable: at 115200 8N1 a 30-character code crosses the wire in about 3 ms, so a 100 ms poll with a 500 ms timeout sits far below the operator's scan rhythm.

Ten bits per character — one start, eight data, one stop — so even 9600 baud finishes the line before the beep does. Open the port once at startup and keep it open; opening per scan adds delay and can eat the first characters. In the loop: read what is available, split on carriage return, trim, write the trimmed line to the variable.

Two details finish the job. The suffix that frames the line is a scanner setting — prefix and suffix framing for barcode scanner input covers what to use and why. The read loop itself, in a host program you own, is shown end to end in USB barcode scanner data capture in your application; a worked C# version is at reading a USB barcode scanner in C# with the SerialPort API.

What if you cannot add a program to the host?

Then keep HID mode and remove the tap instead: auto-focus the input field when the screen loads, if the screen software offers that property, or take the pendant out of the data path with a networked handheld or a small fixed reader at the station.

The screen route costs nothing. Some HMI and pendant screens expose a focus-on-load property on text fields; set it on the scan field and the wedge works again even if the keyboard still appears. Some screens also accept a focus command from a script — look in the field object's properties for either.

The network route changes the hardware, not the workflow. A Fast Ethernet handheld pushes each scan onto the network as text, and the robot controller or PLC consumes it directly; barcode scanner robot communication without a PLC covers that wiring. The same handheld body usually comes over either interface:

And if the operator presents parts at a fixed spot anyway, mount a reader there instead of aiming a gun. The fixed code readers category filters by interface the same way; a Fast Ethernet fixed model such as the LS-CRD-0028 — 2560 x 2048 pixels, 30 fps, 60 codes/s, an 8 mm lens — is built for that post:

If the host has no USB at all but exposes a serial line, the same framing applies over RS232: RS232 barcode scanner connection to an embedded host.

How do you prove the fix in two minutes?

Run three tests in order: scan into a plain terminal to confirm port and framing, watch the variable update without any touch on the screen, then scan the longest code the line will ever print and confirm its final character arrived — three passes and the fix holds.

1. Terminal test. Open the COM port in a terminal program at the agreed baud and scan: the code plus a carriage return should appear. Garbage means a baud mismatch; nothing means the scanner is still in HID — proof: it still types into a text editor.
2. Hands-off test. Start the host program and scan without touching the screen. The variable must carry the code within about a second of the beep.
3. Longest-code test. Scan the longest code production will ever print. A dropped tail in HID mode is what the scanner's intercharacter delay setting fixes; in serial mode the frame arrives whole or not at all.

One failure mode hides in the host rather than the link: a variable that updates on 'value changed' and starts as null swallows the first scan. Barcode scanner first scan ignored: fix the null previousValue shows the one-line fix — initialize the variable to an empty string.

When is keyboard mode still the right answer?

Keep HID keyboard mode whenever a human-controlled text field is already on screen and focused: an HMI login box, a weigh-station form, a PC data-entry page — it needs no drivers, no code and no port management, which makes it the most dependable input path you can ship.

Its two weaknesses are rate and layout. Keystrokes go one at a time, so a very long code can outrun a slow field and lose its tail. And HID maps through the host's active keyboard layout, so a host set to a layout the scanner does not expect can mistype characters. Serial mode has neither problem: the bytes arrive exactly as decoded, in one frame, with no translation and no focus dependency — which is also why it survives screen and firmware updates that change focus behavior.

What should you check before you switch?

Run this list before touching a running station: the scanner must offer a serial interface option, the host must be able to open a COM port, both ends must agree on 115200 8N1, and the longest production code must decode end to end with its final character intact.

• The manual lists USB Serial, USB CDC or COM Port Emulation — without it, the fix is a different scanner, not a setting.
• The host can open and hold a COM port — a program you own, or the pendant's serial-input capability.
• Line settings match on both ends: 115200 8N1, no flow control, carriage-return suffix set in the scanner and trimmed by the host.
• The port opens once at startup — per-scan opening loses the first characters of a fast scan.
• The variable starts as an empty string, not null — a null start makes the first 'changed' event vanish.
• The longest production code passes the terminal test — the tail is what framing errors eat first.

If the scanner, the screen and the network still refuse to cooperate, lay out the host and the scanner model on the contact page and the interface gets picked with you.