USB barcode scanner sends only one character to an HMI

A handheld scanner that decoded cleanly on the bench can arrive at the machine and type the same letter into every input field — often the letter A — no matter which label is under it. The panel is usually innocent and the reader is not broken: its output settings were changed during commissioning and the change survives power cycles. This page is for the integrator or electrician standing at the panel with a scanner, a cable and a few minutes. You will isolate reader from panel with two quick tests, reset the reader with its own programming barcodes, restore plain USB HID keyboard output, and know when a serial or Ethernet scan path is the better fix.

Why does a scanner that reads on a PC send only one character to an HMI?

A reader that types one constant character into a panel is almost always a reader whose output settings were changed at the machine, not a panel fault. This holds even when it decoded correctly on the bench at its last test. Settings barcodes act the instant they are read.

Each programming barcode rewrites a parameter — host type, prefix, suffix, data format — and the reader keeps the result in non-volatile memory. The fault therefore follows the reader between hosts, cables and reboots. Programming "to try things" at the cabinet is the classic way a healthy reader becomes a broken one: a scan interrupted halfway down a page, or two conflicting option barcodes in a row, leaves the output stage half-changed. The PC test passed because it ran before the programming session. The panel is simply the first host to meet the reprogrammed reader.

The constancy is the tell. Decoded payload data varies label by label; one fixed character across different codes is a fixed output artifact. That points at a setting rather than at the imager or the decoder.

How do you tell the reader from the panel in under five minutes?

Two two-minute tests separate the devices: plug an ordinary USB keyboard into the panel and type into the same input field, then plug the reader into the PC and scan three different labels into a plain text editor. Each test clears one suspect on its own.

If the keyboard types, the panel's USB host port, its keyboard stack and the input field all work. If the reader decodes three labels into a text editor on the PC, the imager and decoder are fine. Both passing while the fault persists at the panel means the reader is emitting keystrokes the panel never sees correctly — a configuration problem, not hardware.

Run the arithmetic on what arrived. A twelve-character Code 39 label with an Enter suffix is 13 keystroke events: 12 + 1 = 13. A field showing exactly one character did not truncate the payload — 12 of the 13 keystrokes never reached it. Keyboard stacks do not silently drop 12 characters and keep 1, so the reader is not sending them. The lone survivor is the fingerprint of the setting that did.

Which reader setting leaves one repeated character on every scan?

Three settings produce this exact symptom: a partially scanned settings barcode that left the reader in a mixed programming state, a data-format rule that transmits the symbology identifier instead of the payload, and a USB host type that is no longer plain HID keyboard. The first is the most common by far.

The constant letter is the fingerprint. In the common code-ID schemes, the letter A identifies Code 39 and C identifies Code 128 — the AIM identifiers are ]A0 and ]C0 — so the letter follows the symbology, not the data. Scan one Code 128 label beside the Code 39 labels: if the single character switches from A to C, the reader is transmitting code identifiers and a data-format rule is discarding the payload after them.

If the letter never changes, the likeliest leftover is the interrupted settings scan: one parameter half-written while its neighbours changed, with the USB host type no longer plain keyboard. A host type that streams a vendor protocol shows the opposite extreme — nothing or garbage at the panel — and shares the same cure.

Prefix, suffix and data-format rules are ordinary settings on every industrial reader; the prefix and suffix framing guide shows what each stage adds to or removes from the string before it leaves the reader.

How do you reset the reader and restore plain USB keyboard output?

One programming barcode resets the reader to factory defaults and a second selects the USB HID keyboard host; both come from the reader's own programming guide, and the whole fix takes about five minutes at the machine. Work in this order:

1. Get the programming guide for your reader model from the maker's support site or your distributor — not from a third-party mirror — and print the factory-defaults page and the USB HID keyboard host-type page.
2. Scan the factory-defaults (reset) barcode once. Wait for the reader's programming confirmation beep or LED flash before touching anything else.
3. Scan the USB HID keyboard host-type barcode. On most general-purpose readers this is the default the unit shipped with.
4. Unplug and replug the USB cable so the panel re-enumerates the device with its fresh settings.
5. Scan three labels into the panel field, about one scan per second. All three should arrive complete, with whatever suffix the application needs.
6. Add back exactly one option at a time — usually the carriage-return suffix — scanning, testing and watching the field between each change.
7. Save the configuration the way the guide prescribes: some readers write every change to non-volatile memory immediately, others need an explicit save barcode as the last scan of the session.

If the fault survives a clean reset — both barcodes confirmed with beeps — stop programming. The decode stage is damaged or the unit is not the keyboard-class device you think it is; swap in a spare reader or move interfaces. When you re-add options, watch for stray leading characters creeping back in; the guide on capturing scans without a stray prefix covers that failure.

What should you check on the panel before you replace the reader?

Any panel that accepts a USB keyboard accepts a correctly configured reader, because the reader presents itself to the system as the same HID device; if a plain keyboard types into the field and the reader still fails, the reader's settings are the problem.

Two details still deserve a look once the reader types sensibly. The keyboard layout comes first: the panel's control settings define a country layout, and a reader programmed for a different one scrambles special characters — the keyboard-side cousin of the garbage-character fault on serial links. A mismatch produces wrong letters, though, never one constant letter, so treat it as cleanup after the reset, not as the cause.

The input field is second: a field with a key filter, or the on-screen keyboard left open, can swallow or redirect keystrokes. Close the keyboard and test into a plain entry field before judging the reader.

The panel maker also publishes a compatibility entry naming the scanner models it has tested on its USB ports. Read it as a hotline list, not a whitelist: a reader in plain HID keyboard mode is a keyboard as far as the panel can tell, which is the starting point of the HID keyboard versus serial-port comparison for PLC HMIs. If the scan should reach the panel as characters into a serial point-to-point port instead of keystrokes, the panel-side integration walkthrough for USB versus serial input lays out both paths.

When is a serial or Ethernet reader the better fix than USB?

A serial RS-232 or Ethernet reader removes the keyboard-emulation layer entirely, and it is the faster path when a panel refuses a USB reader that every PC accepts, because the panel reads the characters from a port you configure instead of from a keyboard stack you cannot inspect.

Ethernet also buys reach and logging: a standard copper run reaches 100 m per segment, well beyond the customary 15 m guideline for RS-232 at modest baud rates — and note USB caps a passive cable at about 5 m before you add an active extension. The decoded string travels to the panel or PLC as network data instead of keystrokes. The input-methods comparison for PLCs ranks the interfaces by wiring effort and failure modes. If the receiving end is the PLC itself, the PLC-side barcode integration overview compares network and USB approaches.

Where USB remains the right tool — short runs, one operator station, plain keyboard semantics — pick a reader whose default state is plain HID keyboard so commissioning starts from a known point:

This general-purpose wired handheld code reader connects over USB, the plain keyboard-class interface this page's reset restores.

This Fast Ethernet wired industrial handheld comes from the same family, for scan points the USB cable cannot cover. Both sit in the wider handheld code readers range, which also includes serial-interface models for hosts without usable USB ports.

How do you keep the settings from drifting again?

Ten minutes of discipline prevents a repeat: perform one programming session, save the configuration where the reader supports it, keep the two setup barcodes filed with the machine documentation, and stop scanning barcodes from random printouts at the line.

Print the factory-defaults page and the host-type page, sleeve them inside the panel door, and write the date of the last programming session on the sleeve. Anyone reprogramming scans from that printed set, listens for the confirmation beep after every scan, and tests into a plain field before closing the cabinet. Where the maker offers a configuration tool, keep the exported settings file next to the PLC program: both change together or not at all.

When a reader drifts again — a partial scan, a conflicting option, a colleague's experiment — the reset above is the same five minutes, and it ends the same way, with three clean scans into the field. If the fault ever survives a confirmed reset, swap interfaces or readers; that is the boundary between configuration and hardware. To pick a replacement, the code-reader finder filters wired USB, serial and Ethernet handhelds, the contact page reaches the applications team for integration questions, and more commissioning faults sit on the code-reading topic page.