Barcode scanner CR LF suffix: make Enter commit scans in your HMI

You scan the label, the characters appear in the text entry field on the panel, and the value never lands in the PLC register. The field is doing its job: it is still waiting for Enter. The fix is one setting inside the scanner, usually called the suffix or postamble, which appends a carriage return after every decode. This guide walks through setting it, proving the commit with a single scan, choosing CR against CR+LF for each receiver, and deciding when a keyboard wedge is the wrong tool and a serial or Ethernet reader should feed the controller directly.

What you need

• A USB barcode scanner with HID keyboard-wedge support: the manual lists the interface as USB HID Keyboard or Keyboard Wedge, and handheld industrial scanners almost universally offer it.
• The scanner's programming guide or the vendor's configuration utility, where the suffix codes and postamble fields live.
• The HMI screen with its text entry object bound to the controller address, arranged so you can watch that address update.
• A plain text editor for the proof test.

Nothing changes on the PLC side. The register already receives whatever the panel commits; the missing piece is the terminator.

Why the scan shows but never commits

In HID keyboard-wedge mode the scanner is a keyboard. Every decoded character arrives at the panel as a keystroke, in decode order. A text entry object collects those keystrokes in its field and writes the field to its controller address only when Enter arrives. No Enter, no write: the characters sit in the field while the register keeps its old value, which is exactly the scan-shows-but-register-never-changes signature.

Scanners ship in different suffix states per interface: some USB HID defaults append a CR after every decode, others send the data bare. Scan once into a text editor and you know which yours does. A bare line with the cursor still on it means no terminator.

The reverse failure exists too. A panel or scan handler whose input already expects CR and LF will misbehave if the scanner stacks a second suffix on top: you get an early commit or a stray control character inside the string. The CR and LF characters in an HMI text field guide dissects that case.

If no characters arrive at all, the scanner is probably in a USB serial (CDC) mode rather than HID; the USB barcode scanner on a PLC HMI: HID keyboard mode or serial port guide covers that choice. For the wedge concept itself, see USB barcode scanner as a keyboard wedge into your HMI.

Set the CR suffix

The suffix lives in the scanner's own configuration, not on the panel. Programming guides handle it two ways: a configuration bar code you scan with the reader itself, or a postamble field in a desktop utility. The printed names differ — Add CR suffix, CR suffix on, postamble CR — but the setting is one thing: the characters the reader sends after the data.

1. Scan the factory-defaults code from the guide so you start from a known state.
2. Confirm the interface is USB HID keyboard wedge; if the reader sits in another USB mode, scan the guide's HID keyboard code.
3. Scan the CR suffix code, or set the utility's postamble to CR (hex 0x0D).
4. Scan the save or confirm code if the guide uses one; many readers keep nothing until this step.
5. Test in a text editor: scan any label and watch the characters land, followed at once by a line break.

CR is the Enter keystroke. TAB (hex 0x09) moves focus between fields instead of committing, and CR+LF sends Enter plus a line feed — right on serial links, usually wrong at a text entry field, as the worked example below shows.

If you want the same decision walked through for one classic handheld-laser-and-panel pairing, this suffix setup walkthrough covers it end to end.

Point the scan at the right field

The wedge types into whatever object holds focus. A screen can carry several text entry objects, so the panel cannot guess which one takes the scan; the field has to be selected first. That is not a defect you can suffix away — it is how multi-field screens stay unambiguous.

Three patterns work on the floor:

• One scan-entry field per screen, so the operator navigates to the screen and scans. Where the platform focuses the entry object on screen open, no touch is needed.
• Touch, then scan, when several fields share a screen: one tap to place focus, then the scan.
• A script that sets focus, where the panel runtime exposes one, removes the tap and moves the rule into software.

The keyboard wedge readers and focus in your HMI guide details the focus rules, and two barcode scans into separate HMI data entry fields shows a two-field layout. Once Enter lands in the focused field the commit fires and the value writes, which the commit tag data with Enter guide covers from the panel side.

Worked example: a 12-character part number, one scan

Take a typical receiving-station scan: a 12-character numeric part number into a text entry field bound to a controller register, on a panel whose entry objects commit on Enter. The suffix options are CR (hex 0x0D), TAB (hex 0x09) and CR+LF. The 12-character length is this example's variable; the arithmetic scales with whatever your label carries.

The rule, in words: an HID wedge sends every character as a keystroke, so keystrokes per scan = data characters + suffix characters, and the committed string keeps only the data characters.

No suffix: 12 data keystrokes arrive, the field waits, and the operator supplies Enter by hand — 12 + 0 keystrokes from the scanner, plus 1 manual press per scan to commit.

CR suffix: 12 + 1 = 13 keystrokes. Keystroke 13 is the CR, the field commits on it, and the committed string is the 12 data characters. Manual presses per scan: 0.

CR+LF: 12 + 2 = 14 keystrokes. The CR at position 13 commits the field; the LF at position 14 goes to whatever holds focus next, where it can fire an empty commit or do nothing. Manual presses: still 0, but a stray second terminator now exists.

The decision: at a text entry field, set CR alone. Manual Enter presses drop from 1 per scan to 0, the committed value is identical, and no stray terminator exists. If a second commit ever fires or a control character shows up in the stored string, a suffix is doubled somewhere: drop the scanner to CR, or strip control characters in the handler.

CR, TAB or CR+LF: match the terminator to the receiver

The suffix is not a taste choice; the receiver dictates it.

At a text entry field, in doubt, CR alone wins. The prefix and suffix framing for barcode scanner input guide builds full frames, variable length barcode scanner input: fix it with a suffix handles payloads of changing length, and the barcode scanner to an HMI serial port: framing data without headers guide shows a receiver that frames without headers. More receiver-side cases sit on the code-reading topic page.

Verify it, then roll it out

Three checks, in order:

1. Text editor: one line break per scan, never two. Two breaks mean a doubled terminator; no break means the suffix never saved.
2. Live field: focus the entry object, scan, and watch the controller address change in the same second the characters appear.
3. Edge cases: scan a damaged or unreadable label. A no-decode sends nothing, so the field keeps its previous content; give the station a visible way to flag that, or the operator trusts a stale value.

Run at least 20 scans across a couple of operators before calling it done. What remains after that is focus discipline, not configuration.

When the field still will not commit

Work down the list; each cause has a short test.

1. Scanner in the wrong USB mode. A CDC or USB-serial mode sends no keystrokes at all. Test: nothing appears in the text editor. Fix: scan the HID keyboard-wedge interface code.
2. Suffix scanned but never saved. Many readers need a save or confirm code after the setting. Test: no line break in the editor. Fix: rescan the suffix code, then the save code.
3. Field without focus. The scan lands in another object, or nowhere. Test: characters appear somewhere unexpected. Fix: the focus patterns above.
4. Doubled termination. The handler already defaults to CR and LF and the scanner adds CR, so the field commits early or a stray LF lands in the string. Test: empty commits, or a stored string longer than the label by exactly the suffix length. Fix: disable the scanner suffix and strip control characters in the handler.
5. Marginal USB power or a failing hub drops keystrokes mid-burst. Test: partial or intermittent strings. The barcode scanner power and interface checks for USB adapters guide covers the wiring side.

Skip the wedge when the PLC must see the scan directly

The keyboard wedge earns its place at a bench or checkpoint where an operator watches the panel anyway. When the scan must reach the controller with no screen in the loop — a scan gate on a conveyor, a returnable-container point — wire the reader to the PLC or network instead. An RS232 reader talks to a PLC serial port natively, and an Ethernet reader serves the controller over TCP. The barcode scanner input methods to a PLC: serial, USB and Ethernet guide lays out the routes, handheld barcode scanner to a PLC without Ethernet: RS232 or USB? picks between the serial options, and barcode reader as TCP server: wire your PLC as the client covers the Ethernet case.

One bridge does not exist: a USB-to-RS232 converter will not put a USB scanner onto a PLC serial port. As the FAQ above notes, the converter's USB side depends on a host driver the PLC cannot supply, so the scanner must speak RS232 natively. Wiring notes for one common RS232 scanner-to-controller pairing are in this scanner-to-PLC wiring reference.

Both routes exist in the handheld range. USB-wired handheld readers for the bench station:

A Fast Ethernet reader for the controller-direct install:

Rollout checklist

• Defaults code scanned first, so every change starts from a known state.
• HID keyboard-wedge mode proven in a text editor: characters arrive.
• CR suffix set and saved: one line break per scan, never two.
• One scan-entry field per screen, or an explicit focus rule, so the wedge types where you point it.
• Live commit watched once: the controller address updates on the scan itself.
• Terminator matched to the receiver: CR at a text entry field, the receiver's own byte on serial and Ethernet.
• No-read behavior decided: a failed decode sends nothing, and the station says so visibly.

If the panel route fights you at every step, the controller-direct route above removes the focus problem entirely. Tell us the panel, PLC and label format and we will spec the link with you.