Barcode job selection on a CNC: symbology and payload format

A CNC that loads jobs from barcodes fails in one of two places: the symbol never decodes, or it decodes cleanly and the machine still sits idle. The second failure is the common one. It is a payload problem, not a scanning problem — the string reaching the job input does not match a job file name, or it lacks the terminator the input waits for. This guide gives you the symbology decision, the terminator to set, the arithmetic that sizes the label, and an eight-step path from print to a working job load with a fixed or handheld code reader.

Which symbology should a CNC job label use?

Print Code 39 when every job file name uses digits, upper-case letters, the space and - . $ / + %. Switch to Code 128 when any name needs lower case or another ASCII character, because Code 39 carries only 43 data characters.

The job input parses plain ASCII text. The symbology only decides which characters that string may contain and how much label they cost. Code 128 carries the full ASCII set, lower case included, at 11 modules per character with no gap between characters, and every symbol ends in a mandatory check character. GS1-128, still printed as EAN-128 on some machine manuals, is Code 128 wrapped in an FNC1-based structure; print it only when the control's software parses that format. A few controls ask for Code 32, a numeric-only Code 39 variant: a reader set for Code 39 reads it, and the host validates the check character.

Width matters only when both symbologies can carry the name. At 10-module quiet zones, an 8-character mixed name costs 164 modules in Code 39 (10 × 13.5 + 9 + 20) against about 143 in Code 128 (start, 8 × 11, check, stop, quiet zones) — 13% narrower. An 8-digit name drops to about 99 modules in Code 128's numeric mode, 40% narrower. Short upper-case names rarely gain enough to matter, which is why Code 39 stays the default for machine job labels.

Why does a reader that decodes perfectly still fail to load a job?

The machine never sees the symbol quality — it sees only the ASCII string. That string must match the job file name character for character, case included, and end with the terminator its input expects.

Three mismatches cause nearly every clean-decode failure. Case: Code 39 cannot carry lower case, and most controls compare the incoming string exactly, so PART01 will not load a job stored as part01. Decide once that machine job names are upper-case, then print exactly what the control stores. Stray characters: a reader prefix, a keyboard preamble or a leftover test suffix adds characters the input never expects, and the match fails character by character. Missing terminator: with no carriage return the input keeps waiting, which from the machine's side looks exactly like no scan at all.

Two things need no worry. The Code 39 start and stop asterisks are stripped before transmission, so they never reach the job input. And the data characters arrive in print order, so field order is whatever you printed. If the scan must also drive a robot or a second process after the job loads, the handshake is the same one described in Route a barcode reader result to robot job selection.

What terminator and prefix does the job input expect?

Set the suffix to carriage return — ASCII 13, written 0x0D — first, because CR is the standard terminator for machine serial and keyboard-style inputs. Try CR plus line feed (ASCII 10) only when the control manual or a captured test string demands it.

Leave the prefix empty unless the control's manual defines a command header for the job input. In that case the reader's prefix parameter reproduces that character exactly — the framing mechanics are laid out in Prefix and suffix framing for barcode scanner input.

On a USB keyboard-style connection the reader's Enter suffix does the same job, and the control receives it as a carriage return. Job file names vary in length, so the suffix is also what tells the input where the string ends; that framing problem is the whole subject of Variable length barcode scanner input: fix it with a suffix.

What print size keeps the label readable at the machine?

Print at an X-dimension of 0.25 mm (about 10 mil) or larger with a 10-module quiet zone each side. A seven-character job name then needs a symbol about 37 mm wide, start, stop and quiet zones included.

Code 39 draws each character from 9 elements with exactly 3 of them wide. At the common 2.5:1 wide-to-narrow ratio that is 13.5 modules per character plus a 1-module gap between characters, and the symbology standard's minimum quiet zone is 10 modules each side:

For a seven-character name the arithmetic runs (9 × 13.5 + 8 + 20) × 0.25 mm = 149.5 × 0.25 mm ≈ 37 mm. Every extra character adds 14.5 × 0.25 mm ≈ 3.6 mm, so a 15-character name spans about 66 mm — too wide for a small label, and the point where Code 128 starts to look attractive.

Keep the bars at least 10 mm tall and print on a flat clean patch of the label. Treat 0.25 mm as the floor rather than the target: doubling the quiet zone costs 5 mm and rescues more marginal scans than any reader setting.

Which reader suits the machine's job input?

Match the reader to the machine's physical input. Use a USB reader for a control that takes a keyboard-style input, an Ethernet reader where a PLC triggers the scan and forwards the string, and a handheld when one scanner serves several stations.

The fixed code readers cover the panel-mounted case and the handheld code readers the shared-scanner case; the code reader finder filters both by interface, and Barcode scanner input methods to a PLC: serial, USB and Ethernet explains how each connection reaches the host.

USB panel reader. The LS-CRD-0047 is a compact fixed reader with a 1.2 MP sensor, USB 2.0 interface and a 60-120 mm reading distance; bracket it beside the control so the label sits inside that band at scan time.

Ethernet triggered reader. The MV-ID3013PM-12M-WBN pairs a 1.3 MP sensor and 12 mm focal length with a Fast Ethernet link, so the PLC can request a scan each cycle and forward the job string onward. Where the machine exposes only an RS232 port, the reader-to-serial wiring is laid out in Handheld barcode scanner to a PLC without Ethernet: RS232 or USB?.

Handheld for shared stations. The LS-HCR-0001 is a wired handheld with a 1.0 MP sensor over USB 2.0; the operator scans the label on the traveler or the part, and the string lands in the control like typed text.

Protective covers, light boards and I/O modules for these reader families sit under code reader accessories; on a dusty floor a cover is the difference between monthly and weekly window cleaning.

How do you set it up and prove the job loads?

Follow eight steps: define the exact job names, pick the symbology from the character set, size and print the label, configure suffix and symbology on the reader, connect to the input, capture the string at the host, scan for the job, then grade the label.

1. Export or print the machine's job list and record the exact file names: case, punctuation, length.
2. Choose the symbology from the character set: Code 39 if every name fits its 43 upper-case characters, Code 128 the moment one name does not.
3. Size the label at 0.25 mm X-dimension or larger, bars at least 10 mm tall, quiet zones 10 modules.
4. Print the payload as the job file name and nothing else — no part description inside the symbol.
5. Configure the reader: enable only the symbology you printed, suffix carriage return (0x0D), prefix empty.
6. Connect to the machine's input; on a serial input, match the baud rate, parity and stop bits to the control manual's list.
7. Capture the string before blaming the machine: a terminal program on serial, a text editor on USB, then compare byte for byte against the job name plus terminator.
8. Scan for real and watch the control load the job; then grade a sample label with the routine in Barcode reader verification for label inspection and reprint anything that fails.

If step 7 shows the correct bytes and the machine still ignores the scan, the input is not armed for external job selection — that switch lives in the control's parameters, not in the reader.

When is Code 39 the wrong choice?

Code 39 is the wrong choice when the machine's software demands GS1-128, when job names carry lower-case letters, or when a name grows past what fits the label. Each of those breaks either the match or the layout.

Lower case forces Code 128 subset B. A GS1-128 requirement comes from the control manual, and the FNC1 mechanics behind it are the same ones explained for GS1 codes in GS1 QR code FNC1 separators: encode and verify data. Long names belong in Code 128 as well: 11 modules per character with no inter-character gap beats 13.5 modules plus a gap, and digit pairs halve the cost again.

Where the control imposes a format of its own — a GS1 string, a fixed length, a check character — its manual is the authority, and the rules above still hold throughout: payload matches the stored name, terminator at the end, nothing else transmitted.

Which combination should you commit to?

Commit to Code 39, upper-case job names, a 0.25 mm X-dimension and a carriage-return suffix as the default job label. Move to Code 128 only for lower-case names, a GS1-128 format the software demands, or names that no longer fit the label.

Ship that default and you hold one label template, one reader profile and an input that either loads the job or shows you the exact byte that failed. If the control's manual specifies a payload your label software cannot reproduce, send the format through the contact page and we will match a reader and a template to it.

To spec the whole station — reader, light, controller — in one pass, start here: