Truncate 2D barcode data output: send only the digits you need

You scan the label, the reader beeps, and 35 characters land in a field that has room for 18. The fix does not have to live in the PLC or in a spreadsheet cleanup step: a formatting rule inside the code reader selects the window of decoded data you want to transmit and suppresses the rest. This guide is for anyone wiring a fixed reader or a handheld scanner into a PLC, HMI or database. It builds the send-first-18 rule for a 35-character GS1 DataMatrix, adds the skip-the-leading-010 GTIN variant, shows where fixed offsets break, and finishes with the checks that prove the rule before it runs on the line.

Can a code reader send only part of a 2D barcode's data?

Yes. Most industrial fixed readers and handheld scanners carry a formatting stage between the decoder and the transmit buffer, and its rules can send a fixed window of the decode: for a 35-character string, a rule that sends the first 18 characters and suppresses the rest does exactly that.

Vendors name the stage differently, and the name you will meet most often is Advanced Data Formatting (ADF). Each rule pairs criteria — symbology, data length, sometimes a required prefix — with actions: move the cursor forward a set number of characters, send a set number, send all that remain, suppress the rest. The configuration utility on your PC writes the rule set into the reader, where it survives power cycles and applies to every scan. The same criteria logic that lets a reader send only codes with a specific prefix lets it edit only the codes you want and leave every other label alone.

What is inside the 35-character GS1 DataMatrix string?

GS1 packs the label as fixed application identifiers: AI 01 with the 14-digit GTIN fills characters 1-16, AI 17 with the six-digit expiry date fills 17-24, and AI 10 with the batch number fills 25-35 — 2 + 14 + 2 + 6 + 2 + 9 = 35 characters in the example below.

Write the captured string with its field boundaries and the windows become obvious:

01 04030539042024 17 220331 10 191828131

• Characters 1-2: AI 01, the GTIN marker.
• Characters 3-16: the 14-digit GTIN, 04030539042024.
• Characters 17-18: AI 17, the expiry-date marker.
• Characters 19-24: expiry 220331, in YYMMDD order.
• Characters 25-26: AI 10, the batch marker.
• Characters 27-35: batch 191828131 — variable length, whatever the lot needs.

Two things follow for the rule design. The requested first-18 window ends on the 17 marker, not on a data field — worth knowing before you ship it. And every position after character 26 depends on the batch length, which is the one part of the string that changes from lot to lot.

How do you build the send-first-18 rule?

Create one rule whose criteria match only this symbol — symbology Data Matrix, data length 35 — and whose actions send the first 18 characters and suppress everything after them, so the host receives 010403053904202417 and nothing else.

1. Scan a production code into a plain text editor and count what the reader transmits today. In this example that is 35 characters with no separators; if your capture shows a prefix, a suffix or GS characters, the offsets below shift — read the failure section first.
2. Open the reader's configuration utility, create a profile for the device and add a data formatting (ADF) rule.
3. Set the criteria: symbology Data Matrix, data length 35. This keeps the rule away from every other label the reader sees.
4. Set the actions: send the first 18 characters, then suppress all characters that remain. If the utility offers a send-N-characters-from-position action instead, one entry does the same job.
5. Write the profile to the reader and scan the test code again. The output must be 010403053904202417 — 18 characters plus whatever terminator the suffix setting adds.

How do you skip the leading 010 and send only the GTIN?

Swap the send action for a move-then-send pair: move the cursor forward 3 characters to step over 010, send the next 13, suppress the remaining 19, and the host receives 4030539042024 — the GTIN without its leading zero.

The same 35 characters give you every other useful window, and the row you pick should be whatever the receiving program actually expects:

AI 01 carries a 14-digit GTIN, and the leading zero is part of the number: keep it when the host stores GTIN-14, drop it only for a system that wants the 13-digit form. It is the same leading-zero decision that UPC-A and EAN-13 handling covers for 1D codes.

Why does the rule fail on the next lot number?

A fixed window only survives while the transmitted string stays exactly 35 characters: a batch number of 8 digits instead of 9 shifts every position behind it, and one extra transmitted separator shifts everything from that character onwards.

Three causes account for almost every break. First, the batch: AI 10 is variable length by design, so 191828131 (9 characters) on this lot could be 8 or 12 on the next. In this layout nothing follows the batch, so the GTIN rules above survive; a batch-only rule or any rule reading after the batch does not.

Second, separators: a GS1 DataMatrix starts with FNC1, and a reader can transmit it as a literal <FNC1> or as the GS character (ASCII 29), plus a GS between variable-length fields — every transmitted separator pushes the window one character to the right. Count positions on the capture from step 1, never on the artwork under the symbol, and strip separators in the reader where the setting exists. The FNC1 separator behaviour article shows what these characters look like on the wire.

Third, the criteria: when a label revision makes the string 34 or 36 characters, the length criterion stops matching and the full string passes through unedited. That is the safe failure mode — extra characters arrive and someone notices, instead of digits disappearing silently.

What if the truncation cannot live in the scanner?

Move the truncation to a place you can program: keep the first 18 characters in the receiving program with a left-string instruction, or put a configurable fixed code reader at the station and run the same send-and-suppress rule in its formatting stage before the string reaches the PLC.

Host-side trimming is a few lines — take the leftmost 18 characters of the received string — and the substring-trimming example shows the pattern. It is the right answer when the scanners are already installed and their profiles are frozen.

When you are adding or replacing reading hardware anyway, a fixed code reader does the decode and the edit in one box, then talks Ethernet, serial or USB to the host: browse the fixed code readers or filter by interface, resolution and mount in the code reader finder. The three readers below suit a fixed station over a label.

The MV-ID3013PM-12M-WBN pairs a 12 mm focal length with 1.3 MP resolution on an M12 mount over Fast Ethernet. The LS-CRD-0028 captures 2560 x 2048 at 30 fps and decodes 60 codes/s through its 8 mm lens. The LS-CRD-0047 works at a 60-120 mm reading distance over USB 2.0, which suits a mount close over the label.

Where the scan moves with the operator — goods-in, service carts — the same rule belongs in a programmable handheld instead: see the handheld code readers for wired USB and Ethernet units.

The LS-HCR-0001 reads at 1.0 MP resolution over USB 2.0 with a wired connection.

How do you prove the rule works before it goes on the line?

Scan at least ten production labels — different lots, not ten copies of one code — into a plain text editor and count what arrives: 18 characters, the expected window, on every single scan.

1. Ten different lots through the rule: each output must be 010403053904202417. An output that comes out short or long means the capture from step 1 was not the real transmission.
2. One scan of a different symbology — a 1D barcode from the same line — to confirm the criteria leave it untouched, or suppress it if that is the design.
3. The terminator: confirm the suffix the host expects still follows the data.
4. On a fixed reader connected over USB, run the first-connection readback checks so the profile in the device is the profile you wrote.

Write the AI table for your label before you touch the utility: decode one label, mark the field boundaries, and the actions fall out of the table on their own. The code-reading topic page collects the receive-side fixes that pair with this one, and the contact page is the straight line to an applications engineer when a rule set refuses to behave.