Trigger a code reader from a robot program and confirm the scan

Your robot has to command a code read at a fixed point in its program and know, before it grips or processes the part, that the read succeeded. For the controls engineer wiring that link, there are two patterns: discrete I/O, fast and deterministic, and Ethernet, which carries the decoded string at the cost of parsing and latency. This guide walks the I/O handshake end to end - wiring, pulse and latch sizing, the wait-loop with a timeout - then the register-write trap behind Modbus illegal-function exceptions, a retry policy for no-reads, and the checks that prove the link before the first production cycle. It assumes a 24 V industrial robot controller and a code reader with a discrete trigger input and programmable result outputs; filter for exactly that in the fixed code readers category.

How do you trigger a code reader from a robot?

Give the robot one spare digital output and the reader one programmable result output. You pulse the reader's trigger input for 10-50 ms, the reader fires, and its result output tells the arm to move on or fault out.

I/O wins for pass or fail because the chain is hardware end to end: an optocoupler in, a transistor out, nothing to parse and no network stack to time out. A socket round trip adds tens of milliseconds of jitter and a parser that can fail quietly; keep the network for data, not for the go/no-go. The same pattern is what readers use with PLCs, so the advice in planning a reliable reader-to-PLC link transfers directly to robot cells. One distinction matters: the discrete trigger input is hardware and sits outside the reader's software trigger modes - sensor, serial or free-run - which fixed barcode reader trigger modes compares.

What do you need before you start?

You need a code reader with a discrete trigger input and at least one programmable result output, one spare robot output and one spare robot input at 24 V DC, a four-wire I/O cable, and the reader's setup tool on a laptop.

• Reader: global shutter and an Ethernet port if strings will flow later; the code-reader finder filters both.
• Robot controller: one 24 V digital output for the trigger, one digital input for the result, two more if you also want a dedicated no-read line and a strobe.
• Wiring: a shielded I/O cable and a terminal breakout rated for 24 V DC signals.
• Configuration: the reader's setup tool on a laptop, used once on the bench, then disconnected.
• Mounts, covers and light boards live in the code reader accessories range; the accessory finder filters them.

Short stands want short focal lengths with the light built in. The MV-ID813M-05S-WBN-SR combines a 4.9 mm focal length, white light, a 1.3 MP sensor and GigE in an M10-mount body.

How do you wire and configure the handshake?

Wire robot DO1 to the reader's trigger input and the reader's result output to robot DI1, join the 0 V references, set the result output to assert on a match with a 300 ms latch, and give the trigger a 20 ms pulse in the robot program.

Match sourcing to sinking before anything else: most robot controllers source 24 V on their outputs, so the reader's input type must agree or the line sits dead. Current is never the constraint here - a trigger input draws a few tens of milliamps, well inside the 0.2 A rating robot controller digital outputs commonly carry.

1. Confirm the reader input type (sourcing or sinking) in its I/O documentation and set the robot output polarity to match.
2. Wire robot DO1 to the trigger input and the result output to DI1; tie the two 0 V terminals together at a single point.
3. Where separate supplies make a clean common ground doubtful, use isolated inputs instead of chasing grounds. The MV-IDB005EXI-05NRP is the fully isolated version of its family: a 1.3 MP polarized code reader with a 4.63 mm focal length and a 70 mm focus distance.

4. In the setup tool, set the first result output to read success with a 300 ms latch.
5. Set a second output to no-read and wire it to DI2; the no-read section uses it.
6. In the robot program: move to the read pose, set DO1 high for 20 ms, then low.
7. Wait for DI1 with a 2000 ms timeout; on timeout, branch to the fault path.
8. Save the job to the reader's non-volatile memory, power-cycle both devices, and confirm the handshake works with nothing connected but power and I/O.

How long should the trigger pulse and result latch be?

Use a 20 ms trigger pulse and a 200-300 ms result latch as the defaults: short enough to add almost nothing to the cycle, long enough that a robot input polled every 10 ms cannot miss the result, or hold-until-reset if the program can pause mid-cycle.

The mechanism sets the floor. Robot controllers refresh digital outputs on their controller cycle, of the order of 10 ms, and readers filter their inputs for a few milliseconds; a 10 ms pulse risks a partial update, so treat 10 ms as the minimum and 20 ms as the default. Raise it to 50 ms when the same output fires a light controller, which adds its own input stage - see triggering a strobe from robot outputs. Result outputs are configurable across a wide band, typically 10 ms to 9999 ms or latched until reset: take 300 ms when your wait loop is tight, and latched-until-reset plus a reset output when operator pauses can outlast any fixed latch.

Worked example, worst case, with the decode time illustrative: a 1.3 MP global-shutter reader at a short, well-lit standoff decodes in about 15 ms typical and 40 ms worst.

• t = 0 ms: robot sets DO1 high.
• t = 20 ms: pulse ends.
• t = 60 ms: decode ready (20 + 40).
• t = 70 ms: robot input poll, running every 10 ms, sees the latched result (60 + 10).
• t = 320 ms: the 300 ms latch drops (20 + 300).

Margin = 300 - 70 = 230 ms, more than 23 poll periods of slack. The read costs 70 ms worst case; on a 3000 ms arm cycle that is 70/3000 = 2.3%. Timestamp trigger and result in your own program to replace the assumed 40 ms with a measured figure.

Latency is not throughput. The LS-CRD-0028 is specified at 30 fps and 60 codes/s with an 8 mm lens on a 2560 x 2048 global-shutter sensor - continuous-decoding numbers, not a trigger-to-result time.

When do you need Ethernet instead of digital I/O?

Move to Ethernet only when the robot must know what the code said - job selection, model mix, traceability - not just whether a read passed; keep the I/O trigger even then, because a 20 ms pulse starts the read faster and more predictably than a socket write.

Three patterns cover the string cases:

• Raw TCP socket: the reader listens, the robot connects, the string arrives with a terminator. Which end listens is a real decision - TCP client or listener roles - and a full walk-through with no PLC is in barcode scanner to robot communication without a PLC, with framing details in reader to PLC over raw TCP sockets.
• Modbus TCP: the robot polls the result register with function 03 while the trigger stays on I/O.
• Status gating: many readers prefix the string with a result code, and in a common convention bit 0 of that code is 1 = read, 0 = no read - gate on that bit before parsing so a garbled frame cannot read as a serial number.

When a PLC also consumes results, split the consumers instead of daisy-chaining: robot on I/O, PLC on Modbus or socket, using a barcode routing setup between a PLC and a robot as the reference pattern. Turning the string into action at the arm is covered in routing a reader result to robot job selection. An entry Ethernet reader carries this: the MV-ID3013PM-12M-WBN pairs a 12 mm focal length with a 1.3 MP global-shutter sensor on Fast Ethernet over an M12 mount.

Why does a register write come back as an illegal-function exception?

Because most code readers implement Modbus as a server you read from, and a write to a register their map does not expose as writable is answered with exception code 01, illegal function - which many pendants abbreviate to E1 on the error line.

The symptom is unmistakable: the fault appears the instant the write instruction executes, while reads of the same register return data all shift long. The test takes one line: read the register with function 03. If data comes back and the write (function 06 or 16) returns exception 01, the register is read-only in this reader's map.

The fix is structural, not a workaround: keep the trigger on discrete I/O, poll results with reads only, and write nothing except registers the reader's integration manual lists as writable command registers. Job changes and tuning belong in the setup tool on the bench, not in runtime writes from the arm. If several clients need the reader, some Modbus servers accept one client at a time: let the PLC own the connection and hand the string onward, or give each consumer its own result bits.

How do you handle no-reads and retries?

Wire the reader's second programmable output as a no-read signal to a second robot input, retry exactly once after 200 ms, and fault the cell if the retry fails too, because two failures in a row mean a label or presentation problem, not timing noise.

The no-read output is a standard condition: it asserts when the read window closes without a decode, which is exactly the signal a retry needs. Do not infer it from the timeout - a timeout fires on wiring faults and missing power just as readily as on a missing label. Separating the two inputs makes the alarm self-explanatory: jitter shows up as timeouts, label faults as no-reads.

For early warning instead of per-part faults, most readers can assert an output on a run of failures - the documented pattern is N no-reads within M triggers, for example 4 within 25, a 16% no-read rate (4/25 = 0.16). Route that to a beacon or the PLC so print drift is caught before it stops the cell.

One setting bites exactly here: 'Never Read Same Code Twice' suppresses the same string within a single trigger or twice in a row. On a retry loop it can swallow a genuine second read of the same label, so if a retry returns no-read right after a pass, check that suppression first.

Which checks prove the handshake before production?

Run 100 triggered reads at the production standoff with a known-good code and require 100 results, then soak 500 cycles unattended; a handshake that misses once per 100 is a wiring or timing problem, and the fix belongs in pulse width, latch time or grounding, not in software retries.

• Pulse width: 20 ms measured at the terminal, with the 10 ms floor respected.
• Latch margin: 300 ms against the 70 ms worst-case result above, 230 ms of slack.
• Timeout path: cover the code and confirm the arm faults within the 2000 ms timeout instead of waiting forever.
• No-read path: remove the label and confirm DI2 and the fault branch, not just the timeout.
• Grounding: 0 V tied at one point, or isolated inputs in use.
• Soak: 500 unattended cycles, zero missed handshakes and zero wrong strings.
• Light: if exposure is short, fire the light from the same trigger pulse.

Contrast problems - shiny or dark labels - are where blue light earns its place: the MV-IDA-L-8-47-41-B is an 8-LED blue light board from the ID2000 accessory series.

The decision in one line: bits for motion, Ethernet for the string, and the 20 ms pulse stays either way. With the handshake proven, size the rest of the station in the configurator below, browse more systems guides, or reach the team through the contact page.