Route a barcode reader result to robot job selection

You have a 1D reader at a robot cell and one job per part. The question is how the number inside the barcode becomes the number of the job the robot calls. On most industrial controllers the answer is a group of discrete inputs: the reader places its result on eight wires as a binary number, and a master job loop calls the job whose number that group carries. That covers up to 255 part variants with no network. Above that, or when the code also carries data you must log, route the full string over Ethernet and match it against a table. This guide gives the wiring, the arithmetic, the master-job pattern, a worked example and the checks to run before the first label moves.

The decision first

For a 1D code whose only purpose is to say which part sits in front of the robot, wire the result to an 8-bit input group and let the controller's own job-call instruction do the selection. That instruction is a standard controller feature: nothing to load, nothing to enable. Size it before anything else:

Fifteen variants need ceil(log2(16)) = 4 inputs; 255 variants need 8. If your count fits in 8 bits, discrete wiring wins: no network stack, no socket code, no string parsing, and a failure an electrician can find with a multimeter.

Either the reader or a small PLC builds the binary number. Fixed readers with programmable discrete outputs can place the decoded value straight on eight output lines; otherwise a compact PLC reads the reader and writes the value to eight outputs, a two-rung conversion. When a PLC already runs the cell, that is the natural place for it; barcode reader PLC communication: plan a reliable link covers the link layer.

Three routes from code to job number

Read that as a decision, not a menu. At or under 255 variants with pure part-ID codes, take the discrete group. The moment the code carries anything worth logging — lot, serial, timestamp — go Ethernet and keep one source of truth feeding every consumer.

The 8-bit input group and the master job

An input group is a row of consecutive inputs the controller reads as one binary number. Input 1 carries weight 1, input 2 weight 2, then 4, 8, 16, 32, 64 and 128:

Eight inputs give 2^8 = 256 states, 0 to 255. The controller already knows what to do with them: welding-class controllers ship a job-call instruction whose operand is an input group. It reads the group and calls the job with that number — group value 12 calls job 12 — so you write job 12 to build the part whose label reads 12.

The master job ties it together: a short loop, registered as the startup job, that scans forever.

MASTER:                    # startup job
  WAIT IN#9 = ON           # read-valid from the reader
  value = IG#(2)           # the 8-input group, binary weighted
  IF value = 0 THEN ALARM  # no read: do not build
  CALL JOB:value           # value 12 calls job 12
  PULSE OUT#17, 0.5 s      # acknowledge, reader re-arms
  GOTO MASTER

Controllers that boot in single-job mode will not run that loop until the master job is set as the startup job; the single job mode default configuration page shows where that setting lives.

Worked example: 14 variants, code 12, one 8-input group

A cell builds 14 weldments. Each carries a Code 39 label with its two-digit part number, 01 to 14, and the robot holds one job per part, numbered 1 to 14 to match. Takt is 6 s. The reader is an LS-CRD-0028, a 2560 x 2048 fixed code reader rated at 60 codes/s. It mounts over the label station; the robot contributes one 8-input group and one read-valid input.

Sizing the group:

• States: 14 parts plus one no-read state = 15.
• Bits: ceil(log2(15)) = ceil(3.91) = 4. Four wires would carry it; wire all eight anyway, because the group is eight inputs wide and headroom to job 255 costs nothing.
• Code 12: 12 = 8 + 4, binary 00001100, so the outputs weighted 8 and 4 go high and the rest stay low.
• Group value at the robot: 0x128 + 0x64 + 0x32 + 0x16 + 1x8 + 1x4 + 0x2 + 0x1 = 12, and the call fires on job 12.

Timing against the cycle:

• At 60 codes/s, one decode takes 1 ÷ 60 = 16.7 ms worst case.
• Against the 6,000 ms takt: 16.7 ÷ 6,000 = 0.0028, about 0.3 percent of the cycle. The read never sets the pace.
• Read-valid rises after the decode, the master job samples the group on its next scan and makes the call.

A no-read leaves all outputs off: the group reads 0 and the master job alarms instead of building. Values 1 to 14 are real jobs; anything above 14 can only be a wiring error, so trap it the same way.

Decision: this cell takes the discrete route — one reader, ten wires, a six-line master job, no Ethernet and no PLC.

When Ethernet or serial beats eight wires

Eight wires stop being the right answer at three boundaries.

Past 255 variants. Two groups give 16 bits — 65,535 states — but 17 wires and a doubled instruction buy an architecture you will outgrow again. Ethernet carries any variant count.

When the code carries more than the part number. A nine-digit code such as 123456789 cannot ride on eight wires. If the extra digits are a fixed prefix or suffix, strip them in the reader's output formatting and send the meaningful digits. If every digit varies, the job number must come from a lookup: send the string to the robot's TCP socket, the same pattern as send camera part coordinates to a robot controller over TCP. Reader-to-robot links with nothing between them are their own pattern, and barcode scanner robot communication without a PLC covers the handshake. For a complete small-cell example, configuring a barcode reader directly with a robot walks the wiring end to end.

When several consumers want the same read. The robot wants the job number, the PLC wants the alarm, the MES wants the serial logged. One Ethernet reader feeds all three; the discrete group feeds exactly one. For the logging end, Ethernet barcode reader to CSV for watched-folder imports shows a working pattern.

If inspection runs in the same cell, put one of the vision controllers between reader and robot: it parses the string, keeps the lookup table and serves the answer over Ethernet. The MV-VC3301H-128G66 brings 5+ LAN ports, 4 built-in light channels and an Intel Core i3 processor.

For sizing that box against the camera count, start from the standalone machine vision controller selection guide.

RS-232 sits between the two. It works when the controller has a spare COM port and a language that parses strings, but on many cells that port already belongs to the teach pendant or a programming PC — and you still convert ASCII digits to an integer before any job call.

Picking the reader for this job

The routing decision sets the interface; the label sets the optics and the speed. Three readers cover the routes above:

The LS-CRD-0028 reads up to 60 codes/s on Fast Ethernet, fast enough that decode never sets your cycle time. The LS-CRD-0052 takes a 12 mm focal length on a dual aviation plug, the connector you want where the cell vibrates. The MV-ID5120RM-08M-RBN puts 12 MP on GigE for wide labels or several codes in one frame.

Whatever the model, check pixels against the narrowest bar before ordering. Decoders want at least 2 pixels across the narrow module, 3 for margin. Take a 0.25 mm module: 0.25 ÷ 3 = 0.083 mm per pixel on the object. A 120 mm read window then needs 120 ÷ 0.083, about 1,450 pixels across — comfortable for any reader in this class. Run your own numbers in the camera resolution calculator.

Keep the code centered in the reader's field and crossing the scan line cleanly. Setting an ROI for inline code reading buys speed and reliability at once, and barcode reading direction: prioritize left or right settles which orientation to present first.

Checks before you order and wire

Numbers

• Map one to one. Code 12 calls job 12. Any remapping lives in one place — the reader's output formatting or one PLC rung — never inside the robot program.
• Reserve 0. An all-zero group means no read. Never map a real part to job 0.
• Trap out-of-range values. With 14 parts, a group value above 14 is a wiring error or a stale output; alarm, do not build.

Wiring

• Wire read-valid, not hope. Gate the job call on the reader's read-complete output and hold it until the robot acknowledges.
• Share one common. Reader outputs and robot inputs referenced to different supplies produce values that flicker between right and wrong.
• Match sink to source. Confirm output direction against the input card before first power-up.

Program

• Register the master job as the startup job, and re-check it after any controller battery change.
• Count job memory before you count wires. One job per variant is trivial at 14 and painful at 255 on older controllers; job memory expansion for older robot controllers is the route when the jobs will not fit.
• Gate on decode quality, not just decode presence. A marginal read that slips through is worse than a clean no-read: barcode read confidence: how to judge whether a decode is trustworthy gives the numbers to gate on.
• Close the loop after the call. When similar assemblies share a cell, barcode to part verification for similar assemblies confirms the right program built the right part.

Where the plain wiring goes wrong

• Leading zeros. Code 07 must arrive as 7, not 07. The discrete path drops them for free when the value becomes an integer; a serial path leaves you parsing two characters.
• Stale groups. If the reader holds its last value, the robot rebuilds the previous part after a jam clear. Clear the outputs on acknowledge and gate the reader trigger with a robot busy output so it cannot re-read mid-job.
• Quiet growth. The 8-bit group is full at 255 and nobody sends a memo. Buy the reader with Ethernet even on the discrete route — filter the fixed code readers finder by interface — so the string path becomes a cable pull, not a new device.
• Two jobs, one group. If a second station shares the input group, each master job reads the other's part number. One group per consumer, always.

Next step

Size the reading side in one pass — camera, lens, light, controller, trigger — and keep the I/O plan from this page beside it:

Cells that read codes and run inspection in the same frame can start from smart cameras instead. Bring the label samples and the variant list to the contact page and we will mark up your I/O map before you pull wire.