Send vision results to a robot over EtherNet/IP byte mapping

A robot gripper needs two coordinates, an angle and a flag, and a fixed block of bytes on EtherNet/IP is the dependable way to hand them over. Instead of opening a socket and parsing a string each cycle, you agree once on an assembly — 32 bytes carrying a status word, a sequence counter and X, Y, angle and score as 32-bit floats — and the cyclic I/O connection delivers every result on its own. This walkthrough is for controls and vision engineers wiring a vision controller or smart camera into a robot cell. It gives you the byte layout, the adapter and scanner set-up, the decode arithmetic, a handshake that survives a missed edge, and the bench test that catches byte-order mistakes before they reach the gripper.

Choose implicit messaging, not a socket

EtherNet/IP offers two message types. Explicit messaging opens a session and reads or writes one attribute per request — workable for recipe downloads, clumsy for results every cycle. Implicit messaging (a CIP I/O connection) exchanges two fixed assemblies of bytes cyclically at the RPI — the requested packet interval — that the scanner sets, with no connect, parse or timeout per result.

That is the pattern to choose. The vision device runs as the adapter, the robot as the scanner. The adapter owns the input assembly (results, camera to robot) and the output assembly (commands, robot to camera); both sizes are fixed at set-up and must match exactly. A 32-byte input offered to a scanner expecting 24 bytes simply refuses to connect — annoying at the bench, and exactly what you want instead of silent corruption.

It is the same principle as sending pass-fail results instead of images: the receiver gets a compact, fixed telegram it can map straight to registers.

Design the 32-byte result assembly

Fix the layout before anyone opens a configuration tool. This one carries a complete 2D pick result with room to grow:

The output assembly runs the other way at 4 bytes: bit 0 triggers an exposure, bit 1 acknowledges a result.

Thirty-two bytes is deliberate. It is a multiple of 4, so every REAL and DINT sits on a 4-byte boundary, and the spare DINTs let you add a field after installation without changing a single size on a shipped connection — a size change means re-editing the robot's device description, redeploying and cold-starting the controller.

If the vision side prefers integers, substitute one DINT per coordinate at a scale of 0.01 mm per count. The range is ±2,147,483,647 × 0.01 mm ≈ ±21.47 km, so overflow never enters the discussion; a 16-bit INT at the same scale stops at 32,767 × 0.01 mm = ±327.67 mm, which a 900 mm-reach arm crosses easily with the camera mounted off-centre. Take the DINT or the float, not the INT.

Configure the vision device as the adapter

1. In the vision device's communication or fieldbus settings, enable its EtherNet/IP adapter role.
2. Give it a static IP address on the same subnet as the robot's fieldbus port — 192.168.10.20/24 against a scanner at 192.168.10.5 works; no gateway is needed on a direct link.
3. Define the input assembly at 32 bytes and the output assembly at 4 bytes, matching the table above.
4. Accept the scanner's RPI; 20 ms is the usual request interval on a robot connection.
5. In the inspection program, write X, Y, angle and score to the mapped buffer first, then write the status word and the sequence counter last.

Step 5 is the atomic-write rule: the counter always arrives after the coordinates, so the robot never sees a new counter over old values inside one update.

Add a generic EtherNet/IP slave on the robot side

With the layout fixed, the robot sees a generic device, not a brand-specific driver:

1. Open the robot's fieldbus configuration tool and create the EtherNet/IP network on its scanner port.
2. Add a generic EtherNet/IP slave device and enter the vision device's IP address (192.168.10.20 here).
3. Set the input size to 32 bytes and the output size to 4 bytes.
4. Map bytes 0-1 to a status word, bytes 2-5 to a DINT counter, and bytes 6-9, 10-13, 14-17 and 18-21 to four REALs in the field order above.
5. Map output bit 0 to the digital output the robot program pulses to trigger an exposure.
6. Deploy the configuration and restart the controller so the connection comes up clean.

If the robot controller has no generic EtherNet/IP slave, put the cell PLC between them: the PLC becomes the scanner, the vision device its adapter, and the same 32 bytes pass through to the robot on whichever network it speaks. The mapping and handshake are unchanged, and the register handshake pattern applies unchanged at the PLC. On a PROFIBUS cell, the one-byte job change over PROFIBUS slots into the same output assembly as a command.

Decode the bytes: worked example

Multi-byte values on EtherNet/IP travel least-significant byte first. Force a test result X = 123.5 mm and the adapter puts the 32-bit word 0x42F70000 on the wire as the four bytes 00 70 F7 42. The robot-side decode for a 32-bit float:

where s is the sign bit, E the 8 exponent bits and m the 23 fraction bits as an integer. For 0x42F70000: s = 0; E = 0x85 = 133, so 2^(133-127) = 64; m = 0x770000 = 7,798,784, and 7,798,784 / 8,388,608 = 0.9296875. Value = 64 × (1 + 0.9296875) = 64 × 1.9296875 = 123.5 mm.

Read those same four bytes big-endian and you get 0x0070F742, a denormal near 1 × 10^-38 — the classic 'coordinates look like noise' symptom. Swap the bytes in the decode or select the little-endian REAL format on the scanner side, then repeat the forced-value test.

The scaled-DINT route skips all of this: bytes 39 30 00 00 make the word 0x00003039 = 12,345 counts, and 12,345 × 0.01 mm = 123.45 mm.

Handshake with the sequence counter

Bit flags alone fail quietly: if the robot misses one update, the flag edge it was waiting for is gone and it holds a stale coordinate. The sequence counter fixes that. Camera side: write the fields, then increment the counter and set bit 1. Robot side: compare the counter with the last-seen value; if it differs, copy the fields, run the pick logic, and set the ack bit. The camera clears bit 1 when it sees the ack.

Timing at a 20 ms RPI: the new counter is visible to the robot within one RPI (20 ms), the ack returns within another 20 ms, so a full handshake closes in roughly 40 ms plus scan time. Against a camera cycle of 100-300 ms, the bus is never the bottleneck. Bandwidth check: (32 + 4) bytes × 50 packets/s = 1,800 bytes/s per direction, noise on any Ethernet link.

The trigger direction works in reverse: the robot pulses output bit 0, the camera sees it within one RPI and starts the exposure.

Bench-test before the gripper moves

1. Write X = 123.5 from the vision side and watch the input assembly in the scanner's diagnostic view: it must read 00 70 F7 42, not 42 F7 70 00.
2. Confirm the robot-side REAL shows 123.5. If it does not, fix the byte order now, before mounting.
3. Pulse the trigger bit from the robot program and confirm the sequence counter increments and bit 1 sets.
4. Run 100 trigger cycles and compare the trigger-pulse count with the counter increment; any difference is a lost result.
5. Unplug the fieldbus cable for 5 seconds, plug it back in and confirm the connection recovers and the counter resumes without a reset.

Four failures this bench hour catches, most likely first: values decoding as near-zero noise (byte order), a connection that never comes up (adapter and scanner assembly sizes disagree), a counter that runs while the coordinates stay frozen (the robot is not comparing the counter), and an occasional stale pick (the vision side wrote the counter before the coordinates).

When a plain socket is the better answer

Keep cyclic I/O for fixed-size results. Reach for a TCP socket telegram when the payload varies in length — a barcode plus coordinates plus inspection text — when one image carries dozens of parts, or when both sides already have working socket code. The discipline is identical: fixed field order, a counter, an ack; only the transport changes. Sending part coordinates to a robot controller over TCP is the socket version of this exact handshake, and if you stay on the fieldbus with strings, packing ASCII strings into PLC memory shows how to lay out fixed-length text.

What the vision side needs

The adapter role is part of the vision software, and the hardware under it needs one spare LAN port for the fieldbus link plus the ports for the cameras themselves.

A single-camera cell with result logging runs on the MV-VC2140-128G40-1T, which has 3-4 LAN ports, 8 GB memory and 4 built-in light channels.

Two or three cameras, PoE sensors and heavier logging point at the MV-VC5525-256G70-NN with its 5+ LAN ports, PoE camera ports, 32 GB memory and 8 built-in light channels.

Browse the vision controllers and smart cameras ranges and filter by LAN-port count on the product pages. If you would like a second pair of eyes on your byte table before you deploy, send it with the robot model through the contact page. More fieldbus and messaging patterns sit on the systems topic page.