Prefix and suffix framing for barcode scanner input

Your handheld scanner types into a plain text field all day, then you point it at the scan-input component in your HMI or web app and nothing arrives. The scanner is not broken and neither is the component: components of this kind frame every scan with a prefix and a suffix character, and they only register characters that arrive as individual key events. Most failures come down to four settings. This guide gives you the decision, the framing rules with real ASCII values, a ten-minute bench test with the arithmetic, and the cases where you should abandon keystroke output for a serial or Ethernet reader.

The decision: stay in keystroke mode

Keep the scanner in keystroke output — the mode where it emulates a keyboard — and make the framing explicit. Turn intent output and broadcast output off. Switch on the keystroke option that sends each character as its own key event. Program one prefix and one suffix character into the scanner, and enter the same two characters in the scan component's properties. That combination fills the component from any handheld that can emulate a keyboard, over a USB cable or a Bluetooth link.

Intent delivery — start-activity or broadcast — is a private channel between the scanner maker's mobile scan service and an app written against that service's API. A browser session and a generic scan component never see those intents, so intent mode can be perfectly configured and still deliver nothing. Intent buys capture with no window in focus; if a station truly needs that, the right move is a serial or Ethernet reader, not more intent plumbing.

A plain wired handheld is enough for the bench work. The LS-HCR-0001 is a wired reader with a USB interface, so every scan lands as keystrokes in whatever window holds focus.

How prefix and suffix framing works

In keystroke mode the host cannot tell the scanner from a fast typist: it receives a stream of characters with no message boundaries. The prefix and the suffix add those boundaries. The component discards characters until it sees the prefix, collects everything after it, and publishes the payload the moment the suffix arrives. Nothing in that mechanism is scanner-specific, which is why hand-typing a framed code fills the component exactly like a scan does.

The one scanner-side subtlety is how characters are delivered at the keystroke layer. The common mobile scan middleware offers a pair of switches: one, usually named "Send Characters as Events", delivers printable characters (ASCII 32 through 126) as individual key events; its sibling does the same for control characters (ASCII 1 through 31). With the switch off, the middleware commits the scan as one whole string. String delivery fills a text editor and nothing else.

How the host application digests keyboard-wedge input has its own pitfalls; USB barcode scanner data capture in your application covers the host side. If your app would rather capture scans with no prefix at all, barcode scanner capture without a prefix covers that pattern with preamble and serial framing.

Choosing framing characters that cannot appear in the code

The framing pair must sit outside the code's data alphabet, or the component will cut a code in half mid-payload. Match the pair to the symbology:

! is ASCII 33 and @ is ASCII 64 — both printable, neither part of Code 39's 43-character set, so a Code 39 payload can never contain its own framing. Full-ASCII codes can, which is why they take the older serial convention of STX and ETX, plus the control-character switch. Do not frame with Tab or Enter; they move field focus as a side effect. If the scanner appends Enter after the suffix, turn that off — it lands outside the frame and is discarded, but it clutters every editor check.

The same rule applies on the display side: suffix characters configured for text entry must stay outside the payload alphabet, and barcode scanner suffix setup for HMI text entry works the same problem from the HMI end.

Symptoms in order of likelihood

Work this list top to bottom; the causes are ranked by how often each one turns out to be the culprit.

1. Typing fills the component, scanning does not. The scan is committed as one string instead of individual key events. Test: hand-type !asdf@ in preview mode — if the component shows asdf, the component and its properties are proven. Fix: enable the send-characters-as-events switch and rescan.
2. A text editor shows the code with no framing. The prefix and suffix are not programmed into the scanner. Test: scan into a plain editor; a 12-character code must appear as 14 characters, framing included. Fix: program the pair in the scanner's output settings — configuration app, USB utility or programming barcodes.
3. Everything works on the desk, nothing on the phone. The mobile session is not receiving injected keys at all: the scan profile is bound to a different app, or the Bluetooth keyboard link re-paired to the bench computer. Test: focus a plain input field on the phone and scan; if nothing types there either, the problem sits below your app. Fix: make the HMI app the profile's target — or the default profile — and re-pair the link. For a USB handheld that goes silent, barcode scanner power and interface checks for USB adapters covers the wiring side.
4. Nothing types anywhere, on any host. Keystroke output is off, usually because intent or broadcast mode is still active. Test: scan into the editor again after switching modes. Fix: keystroke on, intent off, one output mode at a time.
5. The component fills only after you click the window. That is window focus, not field focus: these components listen at the window level, but the window still has to be foreground. Test: one click, then scan. Fix: keep the HMI foreground on that station; for capture that must survive focus loss, feeding a scanner into an HMI without focus is a worked example of the pattern.

The ten-minute bench test

Run this once, in order, and you will know which side of the cable the fault is on.

1. Program the scanner: keystroke output on, intent off, prefix !, suffix @, send-characters-as-events on.
2. Scan a known 12-character code, 4215A7831B22, into a plain text editor. You must see !4215A7831B22@: 1 + 12 + 1 = 14 characters. Twelve characters means no framing — fix the scanner here, before touching the app.
3. Open the view in preview mode and hand-type !asdf@ — 6 keystrokes. The component must show asdf, 4 characters. If it does not, its prefix and suffix properties do not match the pair; fix them and repeat.
4. Scan the real code. The component fills with 4215A7831B22 and the data array goes from length 0 to length 1.
5. Scan three more times. Array length 4; the newest value sits at index 4 − 1 = 3. Your event script reads that index, then clears the array.
6. If step 3 passes and step 4 fails, the scanner's delivery mode is the remaining suspect. The component is proven; work the key-event switch and the profile binding.

With a 10 ms inter-key delay, those 14 keystrokes arrive in 14 × 10 = 140 ms — a burst, not a trickle, so ordinary UI event handling keeps up. If characters drop at 0 ms delay in a web client, set 10 ms and step down; the value where characters start going missing is your floor, and one step above it is your setting.

One array element per scan is by design

A scan-input component of this kind appends each scan to its data array instead of overwriting one value, and that is deliberate: an operator can collect codes while the client is offline and the batch uploads when the connection returns. Fighting the array in the component properties is the wrong move. Handle it in the event script: read index N − 1, act on the value, then clear.

Clearing an array inside the very event that watches it is where update loops bite; barcode scan event handling without recursive updates shows the guard pattern for exactly this case.

If you echo the payload to a numeric or text display, give that display its own formatting fields rather than passing the scanner's framing characters through — resolving prefix and suffix loss on HMI display elements covers why display elements strip them.

Which output mode when

Within keystroke mode, the handheld choice is about operator motion, not framing: wired USB for a fixed bench station, wireless for an operator who walks. The pair lives in the scanner's output settings either way. The LS-HCR-0002 is the wireless counterpart in the same class: a wireless handheld reader that also carries an Ethernet interface. Wired or wireless, pick by how the operator moves:

All 2 share: Image sensor 1280*800 Pixel Global Shutter CMOS; Max acquisition frame rate 60FPS; Pixel size 3.0 µm; Target size 1/4"; View field 31° horizontally, 20° vertically; Symbol contrast 20%; Depth of field range DM 5mil 10-60 mm / DM 10mil 10-100 mm; Focal length (mm) 6.8. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

When keystroke framing is the wrong answer

Keystroke output assumes a human-scale rhythm: one operator, one scan at a time, one window in focus. Three situations break that assumption. A conveyor feeding codes at line rate needs a fixed reader with Ethernet output. An unattended station where nothing can hold focus needs serial or Ethernet framing. A cell with a dozen scanners needs one polled network, not twelve keyboard streams competing for focus.

That is the territory of fixed code readers. The MV-ID3013PM-12M-WBN is typical of the class: a compact fixed reader with a Fast Ethernet interface, a 1.3 MP sensor and a 12 mm focal length, delivering codes as framed network strings. The framing idea carries over unchanged — your prefix and suffix become the preamble and postamble of the reader's output string.

Checklist before you blame the scanner

• Text-editor test passes: the framed scan reads !code@ in a plain editor, framing included.
• Keystroke output on; intent and broadcast off — exactly one output mode active.
• Send-characters-as-events on, and control-characters-as-events on too if you frame with STX/ETX.
• The component's prefix and suffix match the scanner pair character for character.
• Hand-typing !asdf@ fills the component in preview before any scan is attempted.
• On phones, the scan profile targets the HMI app and the keyboard link is paired to that device.
• Inter-key delay starts at 0 ms; move to 10 ms only if a web client drops characters.
• The event script reads index N − 1 and clears the array, with a guard against re-entrant updates.
• One prefix, one suffix, Enter-append off.

Next steps

Pick the handheld in the handheld code readers category or the code reader finder, and run the bench test on the bench before anything gets mounted. If the editor test still fails with the framing programmed, contact us with the exact string you typed and the exact string the editor received — that pair pinpoints the culprit in one reply. Free expert support comes with every order.