Barcode scanner send only codes with a specific prefix

You want the scanner to act as a gate, not a pipe: codes that start with SK go to the host as 1SK12345678 followed by a carriage return, and every other code vanishes. The first attempt most engineers make — one formatting rule with a begins-with-SK criterion — fails in a specific way: the first SK code arrives correctly, then every code scanned afterwards reaches the PC, rejects included. A criterion never discarded anything; only an action can. If you feed an HMI, PLC or MES from handheld or fixed code readers, this guide gives you the two-rule setup, the reason a single rule leaks, the exact rule table for the SK case, and the go-live test that catches the leak before your MES does.

Two rules, and the discard rule goes last

Formatting rules on an industrial reader have two halves. Criteria decide which codes a rule applies to; actions decide what happens to the data, including whether it is transmitted at all. That split is the whole trick.

The job takes exactly two rules:

• Rule 1 — keep and transform. Criteria: data begins with SK, set as a data-match pattern of the literal SK plus the any-remainder wildcard. Actions, in order: insert 1 at the front, append a carriage return, send the data.
• Rule 2 — discard the rest. Criteria: any symbology, any data. Action: send nothing.

Rule lists evaluate from the top, and the first rule whose criteria match is applied; processing stops there. The catch-all must therefore be the last rule — placed above the keep rules, it swallows every code, SK ones included.

Guides name this feature differently — advanced data formatting, data editing, formatting rules — but it is always a numbered rule list built once in the maker's configuration utility, or written to the reader as documented configuration strings.

Why one rule works once, then leaks

Rule evaluation is stateless. Every scan starts again at rule 1; nothing carries over from the previous scan.

With only the SK rule loaded, a matching code triggers the actions and transmits transformed. A non-matching code triggers no actions — and no actions means the reader falls through to its default behavior: transmit the data unchanged. Your first scan happened to be an SK code, so the filter looked correct. The first reject went straight through, and so did everything after it. Nothing wore out and nothing needed re-arming; the rule set never contained a discard. The fix is the catch-all rule, not a fresh configuration.

Build the rule set

1. Start a new configuration file for the reader in the maker's configuration utility, a free download from its support site. If your fleet is configured with strings from the programming guide over USB or serial instead, the same rules appear there as numbered entries.
2. Open the formatting or data-rules page.
3. Create rule 1. Leave the symbology criterion at any, or narrow it to the symbology your labels use. Set the data criterion to a begins-with match on SK.
4. Give rule 1 three actions, in order: insert prefix 1, append suffix CR (ASCII 13, hex 0D), then send the data. The send action commits the transmission; a matched rule without one transmits nothing.
5. Create rule 2. Set criteria to any symbology and any data, with the single action send nothing (some guides call it discard).
6. Confirm the order on screen: rule 1 above rule 2. Re-check after every edit, because utilities renumber rules when you duplicate or move them.
7. Write the configuration to the reader and save the profile file with the station documentation, so a replacement scanner loads identical rules in a minute.

A global prefix or suffix is not a filter — it adds characters to every scan. If all you need is an Enter key after every scan, that is a suffix job, covered in adding an Enter key with programming barcodes; a preamble prepended to every scan, as in the preamble and serial capture guide, cannot suppress anything either.

Worked example: SK12345678 in, 1SK12345678 + CR out

Inputs, and where each comes from: the station forwards codes starting with SK as 1SK12345678 terminated by a carriage return, because the host field commits on Enter; the sample code SK12345678 is 10 characters; symbology stays at any because the line mixes 1D and 2D labels. The wanted transmission is the 11-character output string plus one CR byte.

Trace of three scans:

The third row is the regression case: stateless evaluation sends the same code down the same path every time, rejects in between included. Decision: an SK code must produce exactly 12 bytes and every other code none. Bytes after a reject mean the catch-all is missing or mis-ordered.

One terminator, one owner

Decide once who appends the carriage return. If rule 1 appends CR, remove any global Enter or CR suffix from the same configuration — scanner guides warn against setting the same terminator through both mechanisms, and the host would see the string closed twice. If the line already commits scans with a global suffix everywhere else, keep the suffix and drop CR from the rule; rule 1 then only inserts the 1 and sends. The CR LF suffix guide covers the suffix side in detail.

If the reader has no rule feature

Entry-level handhelds often expose only a global prefix and suffix, with no rule table. Then the gate moves to the first host that sees the data. In a PLC, compare the first two characters of the received string with SK and branch — the same leading-character compare pattern as a numeric range match on leading digits. In an HMI script or PC service, a start-anchored pattern such as ^SK.* does it, as in regex parsing with capture groups. Keep exactly one filter in the chain — scanner or host, never both — or you will chase prefixes applied and stripped twice. When the cleanup has to live in an HMI entry field, this prefix-strip walkthrough in an HMI data-entry dialog shows the pattern end to end.

Pick the reader by the host it feeds

With the gate logic settled, the remaining decision is the interface, and it follows the host:

• HMI or PC at a bench: a wired USB handheld types the filtered text into the focused field. The handheld code readers category filters by interface.
• PLC tags over the plant network: an Ethernet handheld or a fixed code reader sends the filtered string as a TCP payload, commonly with the reader as TCP server and the PLC as client — wiring the PLC as the client steps through it. If the controller also drives the reader with trigger or job-select strings, the frame format matters; a TCP/IP send-string walkthrough from a compact PLC to a code reader works one end to end.
• Legacy serial line: one reader per RS-232 port still suits a single bench; the serial, USB and Ethernet input overview compares all three.

Above the line, a fixed reader holds the same job permanently:

For bench-scale short-range reading, the compact reader below prints a 60-120 mm reading distance and connects over USB 2.0:

Protective covers, light boards and I/O boxes for these readers sit in the code reader accessories category.

Go-live test

Run this sequence before the station goes live, watching the raw receive buffer rather than the formatted HMI field:

1. Scan SK12345678. Expect 1SK12345678 followed by CR — 12 bytes if you can count them on the port.
2. Scan a code without SK. Expect silence: no bytes, no terminator. The receive-buffer framing guide shows quiet versus a stray null.
3. Scan the SK code again. Expect the same 12 bytes — this step reproduces the works-once-then-leaks symptom if the catch-all is missing.
4. Scan every symbology the station accepts, matched and unmatched, plus one with SK mid-string such as 123SK456; a start-anchored criterion discards it.
5. Scan a short SK partial such as SK9 and decide whether it should pass. Begins-with matches pass it; add a length criterion to rule 1 if partials must be rejected.

If a serial link delivers garbage instead of clean text, fix framing first — the serial-link garbage guide covers the usual causes.

When the scanner is the wrong place for the gate

Three cases argue for moving or extending the filter:

• The operator must see why a code was rejected. A silent discard gives the host nothing to display. Surface rejects where a message can be shown, or build a proper check station — the pass/fail match verification build makes the good/no-good decision explicit.
• The accepted prefix changes with the recipe. A rule table is static. Filter in the PLC against the active recipe instead; the recipe lookup with UDT arrays pattern keeps the accepted list where the recipe lives.
• The code must equal an expected value, not merely start with a prefix. Prefix gating is a coarse filter; equality checking belongs to the verification layer above it.

Standardizing readers for this job starts with the host interface: USB for bench HMIs, Ethernet for PLC tags. Both categories link from the code reader finder, and the code-reading topic page collects the integration guides. For a review of your rule table before roll-out, send the code format and host type through the contact page.