Trigger a barcode reader from a robot over Ethernet

A robot cell that builds to order needs the code at the moment the part arrives: the robot finishes its approach, asks the reader to read, and gets the string back before the gripper closes. Over Ethernet, that handshake comes down to three decisions: which device opens the connection, which bits carry the trigger, and how long the robot waits before calling it a no-read. What follows are the four routes that work — scanner-to-adapter implicit I/O, raw TCP socket messaging, a PLC scanning both ends, and the discrete trigger fallback — with a timing budget you can reuse and the hardware to hang each one on. It is written for controls and vision integrators wiring a fixed code reader to a robot controller on the same plant network.

What the adapter and scanner roles decide

EtherNet/IP implicit I/O has two roles, and they are not symmetric. The scanner opens and owns the connection; the adapter waits for one to arrive. Industrial code readers are built as adapters: they expose an output assembly for the trigger and reset bits and an input assembly for result-ready, read status and the string bytes, and they never start a connection themselves.

Robot controllers ship either way, and that fact splits the job into routes. A controller with the scanner option plays the scanner and talks to the reader directly. A controller running only as an adapter is itself a slave on the network: something else must scan it, and it cannot open a connection to the reader at all. So: scanner option present, take Route A. Absent, drive the reader through its raw TCP command port (Route B), put a PLC between them (Route C), or pulse the reader's discrete trigger input from a spare robot output (Route D).

Whichever route wins, decide who triggers and who owns the result before you pull cable — the planning sequence in Barcode reader PLC communication: plan a reliable link applies to robot hosts as much as to PLCs.

Route A: reader in adapter mode, robot as scanner

The reader side needs only an Ethernet port and its adapter role; the robot side needs the scanner option in the controller configuration. For a single-code station at arm's reach, a compact Fast Ethernet reader such as the MV-ID3013PM-12M-WBN (12 mm focal length, 1.3 MP) carries the whole job on one network run.

With both ends capable, the set-up is short:

1. Set the reader to adapter (EtherNet/IP target) mode in its network settings and fix its IP address. The assemblies it exposes are listed in the reader's EtherNet/IP documentation.
2. Confirm the robot controller's option list includes the scanner class of EtherNet/IP; it is a controller software option. If the list does not show it, move to Route B, C or D.
3. Create the connection on the robot to the reader's IP address, entering the reader's output and input assembly instance numbers exactly as its documentation prints them.
4. Map the output assembly to a robot output word: one bit triggers the read, one bit resets the handshake.
5. Map the input assembly to a robot input word: result-ready, read-OK or no-read status, and the string bytes if the assembly map carries them.
6. Set the connection's update period. 20 ms in each direction is a common starting value, and it is the figure the worked example below uses.
7. Write the handshake as a level, not a pulse: set the trigger, wait for result-ready under a timeout, read the string, then clear the trigger on the result edge.
8. Prove it before production: run ten consecutive parts with zero missed and zero double triggers, then cover the lens once and watch the timeout branch handle the no-read.

Worked example: trigger-to-result budget for a 30 fps reader in a 4-second pick cycle

The station inputs are yours to substitute: a cycle of 4,000 ms per part as an illustrative typical pace, and the 20 ms per direction update period from step 6. For the reader, the LS-CRD-0028 prints 30 fps and 60 codes/s on its data sheet, so those are the throughput figures used here. The rule, in words: worst-case trigger-to-result equals one update period for the trigger bit to arrive, plus one frame interval for the exposure, plus one decode slot at the rated throughput, plus one update period for the result to arrive back at the robot.

Check the units: 1/30 s is 33.3 ms and 1/60 s is 16.7 ms, so the robot waits about 90 ms — 90 / 4,000 = 2.3% of the cycle. The budget moves with the update period and the frame rate. At 50 ms per direction it grows to 50 + 33 + 17 + 50 = 150 ms (3.8% of the same cycle), and on a 10 fps reader the frame term alone rises to 100 ms.

Decision: under about 100 ms, trigger over Ethernet and let the robot wait synchronously. Set the result timeout at 1,000 ms — 1,000 / 90 ≈ 11 times the expected budget — and allow one retrigger on a no-read; two reads cost 180 ms, still under 5% of the cycle. If the budget ever passes a quarter of the station cycle (1,000 ms here), stop gating the robot: trigger from the part-present sensor instead and let the result wait for the robot rather than the reverse.

Route B: raw TCP socket messaging, no scanner option needed

Most industrial readers also run a plain TCP service alongside any fieldbus personality: the host opens a client socket, sends the trigger command string, and reads the decoded string back. Socket messaging is ordinary TCP from the robot language, so it needs no scanner option and no assemblies — only the reader's IP address, port and command format from its manual.

The trade is handshaking: nothing frames the data for you. You program the open, the trigger write, the read, the timeout and the close, which is the same discipline explicit messaging demands anywhere. Start from TCP client or listener: match your network barcode reader to your host to decide who opens first, and borrow the framing and trigger rules from Barcode reader to PLC over raw TCP sockets without EtherNet/IP; they transfer unchanged to a robot host. The same job done from a collaborative robot — socket open, command string, decode back — is laid out in configuring a barcode reader directly with a collaborative robot.

If the reader publishes no TCP command service, this route is closed — check the manual before you commit to it.

Route C: the PLC scans both ends

When the robot is adapter-only and the reader speaks only implicit I/O, a PLC with a scanner role closes the gap: it scans the reader and scans the robot, copies the trigger bit from the robot's input assembly into the reader's output assembly, and copies the result assembly back. The robot never talks to the reader; it just sees result bits arrive in its own adapter connection.

Map both implicit assemblies as the EtherNet/IP barcode reader to PLC: map the implicit I/O assembly guide shows, then pass the string onward with the routing a barcode reader result to robot job selection pattern. Where the PLC takes the socket role instead of implicit scanning, sending and receiving barcode data on a PLC over raw TCP shows the send/receive block pair doing the identical job.

The cost is one extra hop. The trigger now crosses two implicit connections, so the worked example's two 20 ms terms become 40 ms each and the budget grows to 40 + 33 + 17 + 40 = 130 ms — still far under the 1,000 ms decision threshold.

Route D: the discrete trigger fallback

When neither Ethernet route can be set up, spare discrete I/O closes the loop: a robot output drives the reader's trigger input, and the reader's result outputs — read-OK and no-read — land on robot inputs. The trigger and the pass/fail travel on wires; the decoded string still leaves on the reader's own Ethernet or serial channel to whatever host stores it. So Route D answers the request 'read now, tell me pass or fail', not 'give me the payload'; a job selector downstream still needs the string over the network. The program-side handshake, including how to confirm the scan, is the one in Trigger a code reader from a robot program and confirm the scan.

Check the reader's trigger input before wiring: opto-isolated inputs expect a defined voltage and current, and 24 V into a pin the connection diagram rates for less ends the input stage. On the arm, use drag-chain-rated cable — the cables category groups the high-flex runs — and let one integrated cable carry the Ethernet line and the I/O leads down together:

The 17-pin connector on that cable breaks out to an RJ45 plug and open/DB9 leads, so the string and the discrete handshake share one 5 m high-flex run instead of two cables taped to each other.

Handshake rules that stop missed and double triggers

• Trigger as a level. Set it, hold it until the reader raises trigger-acknowledge or result-ready, then clear it. A one-scan pulse can fall between update periods; an uncleared level triggers the next part by accident.
• Read the string only after result-ready. The decoder writes that buffer asynchronously, and a read in flight returns torn data.
• Gate on one edge. AND the handshake with the part-present bit or the robot's in-position bit and act on the rising edge, so one part produces exactly one trigger.
• Timeout from the worked example: 1,000 ms, then one retrigger, then a reject flag to the job logic rather than an endless retry loop.
• One writer per reader. If a PLC shares the same device, arbitrate with a permissive bit so two masters cannot pull the trigger together.

Checks before you order

• The reader data sheet lists a Fast Ethernet or GigE interface — the entry ticket for Routes A and B. A USB-only reader such as the LS-CRD-0047 (USB 2.0, 60-120 mm reading distance) belongs on the USB route instead.
• The robot controller option list shows the scanner class of EtherNet/IP if you plan Route A; an empty list means Route B, C or D.
• The reader manual publishes what your route needs: assembly instances and byte layout for Route A, the TCP port and command format for Route B.
• Spare discrete outputs on the robot and trigger/result inputs on the reader, as insurance even when Route A is the plan.
• High-flex, drag-chain-rated cable for anything mounted on the arm; static cable only at a fixed pedestal.
• Codes under shrink wrap or on shiny film read better with a polarizing cover or an added light board — the code reader accessories page groups both.

The handshake itself is interface-agnostic — it runs the same on bigger pixels or longer stand-offs. These three Ethernet readers span the common range: 5 MP Fast Ethernet, 12 MP GigE, and a 1.3 MP GigE with a 4.9 mm wide-angle focal length:

When the usual answer is wrong

• High-rate lines: once the cell reads hundreds of codes per minute, keep the read out of the robot's cycle entirely. The reader runs continuously and the robot consumes results, and the real question becomes communications capacity — the same one posed in Choosing barcode scanner communications for 2,000 reads per minute.
• Unpredictable part arrival: when parts reach the station whether or not the robot is there, auto-trigger on the part-present sensor and queue the results. Gating every read on the robot wastes reader throughput and adds latency to the cell.
• Pass/fail is genuinely enough: two discrete wires beat any Ethernet handshake for simplicity. Just remember the payload never reaches the robot that way — the moment a downstream job selector needs the string, the network route comes back.

Pick the route that matches the controller's option list, time it against the worked example, and only then order parts: the code reader finder filters by interface and resolution, and the companion how-tos sit on the systems topic page. If the option list is ambiguous, send the reader model and controller generation through the contact page and we will help you size the route. When wiring is the open item, start the configurator at the cable and trigger step: