Send vision coordinates to a PLC through a register handshake

A vision system that finds the part is half the job. The other half is moving X, Y and angle into the robot's hands without a dropped, doubled or stale result. Most production cells settle this with a PLC in the middle: the PLC triggers the inspection, the vision system writes coordinates into a fixed block of registers, and a handful of handshake bits decide which result is new. This guide gives you the register map, the four-signal handshake and the timing arithmetic to set that up right the first time, whether the vision side is a smart camera writing its own results or a vision controller aggregating several cameras. You finish with a register layout to hand your controls engineer and a cycle budget you can defend in a design review.

The decision: one map, one handshake, one writer

Send every vision result to the PLC through one fixed register map guarded by a sequence counter. The PLC is the only writer of triggers; the vision system is the only writer of results; the robot takes its coordinates from the PLC, never from the vision system directly. A 16-bit command word, a 16-bit status word, two 32-bit reals for position, one scaled integer for angle and one sequence counter cover nearly every 2D guidance hand-off: ten working registers, sixteen reserved.

That split keeps cycle logic, part-present sensing and interlocks in one place, so any device can fail without corrupting the other two. Polling, logging and alarm handling around this handshake are the wider subject of the production-line PLC integration guide. For a bench cell with one camera and one robot the calculus changes; that case comes at the end.

The register map

Fix the map before anyone writes code, and never move it afterwards. Ten registers do the work; reserve sixteen, so a second camera or a quality word never forces a remap.

Ten registers are 20 bytes. On a tag-based fieldbus such as EtherNet/IP or PROFINET the same layout becomes typed tags; on Modbus TCP it lands in holding registers. Nothing else in this guide changes with the transport.

The four-signal handshake

Four signals carry the whole transaction, and the sequence counter arbitrates them:

1. The PLC writes the job number, sets the Trigger bit and holds it.
2. The vision system sees the rising edge, clears Results Valid, sets Busy and runs the inspection.
3. The vision system writes X, Y, angle and score, increments the sequence counter, clears Busy and sets Results Valid.
4. The PLC sees Results Valid and a changed counter, copies the four values, clears Trigger and sets Acknowledge.
5. The vision system sees Acknowledge and clears Results Valid; the PLC clears Acknowledge, and both sides sit ready.

Every arrow costs at most one PLC scan on the PLC side and one fieldbus update on the link. Trigger and Acknowledge are levels, not pulses: a busy vision system simply does not see the edge, so no request is ever lost. An unchanged sequence counter means the data on the wire is a repeat - hold the robot until the counter moves.

Timing: count scans, not hopes

Two scans and two updates move the trigger down and the result back; the vision system's own execution sits in the middle. Worked example with the arithmetic: assume a 10 ms PLC scan, a 10 ms fieldbus update period and 40 ms of vision execution (a 2 ms exposure plus 38 ms of matching - a single-part 2D guidance match on a mid-range controller).

• Trigger written to the vision system sees the edge: 1 scan + 1 update = 20 ms
• Vision executes: 40 ms
• Results Valid to the PLC latching the data: 1 update + 1 scan = 20 ms
• Data in the PLC: 20 + 40 + 20 = 80 ms
• Acknowledge round trip closes the handshake: +20 ms, 100 ms end to end

At a 5 ms scan and a 5 ms update the same formula gives 2 × (5 + 5) + 40 = 60 ms. Push scans lower and the gains stop, because vision execution dominates.

Decisions by case: on a 300 ms takt (3.3 picks per second), 80 ms of transport plus 40 ms of vision leaves 180 ms for part presentation and robot motion, which is workable. On a 100 ms takt this pattern cannot keep up; move the vision onto the robot's real-time bus instead. What the robot does inside its 180 ms is the subject of the pick-and-place grip cycle guide. One related trap: if the job or format selection changes near the trigger, the sequence counter will not save you - the trigger race fix covers that case.

Packing the numbers: reals and scaled integers

X and Y travel as 32-bit IEEE-754 reals, so neither end scales anything. Precision check: a single-precision float carries a 24-bit mantissa, so near 500.0 mm the step is 256 × 2^-23 mm = 2^-15 mm ≈ 0.00003 mm. Hand-eye calibration in a typical guidance cell lands around 0.01-0.1 mm, so the register format never limits the hand-off.

Angle and score travel as scaled integers:

Angle at 0.01° per LSB: a part rotated 47.35° stores round(47.35 ÷ 0.01) = 4735, and the PLC reads 4735 × 0.01 = 47.35°. Range check: ±180.00° needs 18000 counts, inside a signed 16-bit integer's 32767 with 1.8× headroom. Resolution of 0.01° is ten times finer than the 0.1° a gripper pose typically needs.

Score at 0.01 % per LSB: 97.4 % stores 9740. Keep the threshold in the PLC - accept at 9500 and above - so a quality tune never touches the vision job.

Who owns the map: smart camera or vision controller

One camera: the smart camera writes the results

When the cell needs one camera and one inspection, delete the box between them: a smart camera runs the match on the sensor and exchanges the same handshake with the PLC. Trigger, Acknowledge, sequence counter and status word stay exactly as designed; only the vision execution moves into the camera housing. Shortlist by resolution, sensor format and lens mount in the camera finder:

The MV-SC5060XM-08M-WBN is that pattern in one housing: 6 MP mono, GigE and an 8 mm M12 lens, with matching and the PLC exchange both running on the camera.

Two cameras or more: a vision controller holds the map

From two cameras up, or whenever lights need strobing and jobs need switching under PLC command, a vision controller owns the cameras, the lighting and the register map, and speaks one protocol to the PLC. Built-in light channels remove the separate light-controller wiring, and the LAN port count sets how many cameras attach before a switch appears.

The MV-VC3301H-128G66 pairs 5+ LAN ports with 4 built-in light channels, 8 GB of memory and an Intel Core i3.

Where cameras multiply, PoE removes a cable per camera. The MV-VC5525-256G70-NN adds PoE camera ports, 8 built-in light channels and 32 GB of memory.

Size in this order: LAN ports first (cameras plus one spare), then light channels, then memory for image buffers.

Status and fault bits the PLC actually needs

Keep the status word boring and never reuse a bit:

• bit 0 Ready - handshake idle, accepts a trigger
• bit 1 Busy - inspection running, further triggers ignored
• bit 2 Results Valid - data fresh since the last Acknowledge
• bit 3 Job Loaded - the loaded job matches the requested job number
• bits 8-11 fault code - 0 none, 1 no find, 2 score below threshold, 3 timing fault, 4 trigger while busy

A no-find is a normal production event - part missing, flipped or wrong in the fixture - so route it to the reject path, not to a fault horn. The alarm layer, operator text and logging around these bits are worked through in the vision diagnostics-to-PLC mapping guide.

Checks before you commission

Run these in order; each catches a failure the next stage would bury:

• Word order. Write 123.456 as a REAL and read it back; a wrong value means swapped words, not a broken vision job.
• Echo. Trigger once and watch Ready fall, Busy rise, then Results Valid with a new sequence number.
• Repeat. Read the status twice between triggers: the counter must hold still, proving nothing fresh arrived.
• No-find. Remove the part, trigger, and confirm fault code 1 with Results Valid set - a miss is still a result the PLC must consume and acknowledge.
• Timing. Timestamp trigger-write and data-ready over 100 cycles; the worst case must sit inside the 80 ms transport budget, and the spread reveals the real scan jitter.
• Wrap. Force the counter to 65534 and run three inspections; the compare must survive 65535, 0 and 1.

When routing through the PLC is the wrong call

Three cases break the pattern, each with a better answer:

• Bench cell, one camera, one robot. Let the vision system speak the robot's own protocol directly and delete a link; the camera-to-robot TCP exchange guide shows the message format. You accept interlocks living in two places, which a bench can tolerate.
• No controller box at all. A smart camera plus the robot covers simple guidance end to end; the pick-and-place without an external PC guide lays out that architecture.
• Serial-only legacy PLC. Same map, same handshake, different transport: a fixed ASCII telegram over RS232, covered step by step in the fixed-position RS232 telegram guide.

Everything else - conveyors, fixtures, multiple robots, an HMI that must show why a part failed - keeps the PLC in the path.

Next step

Draft the sixteen-register block, agree the handshake with your controls engineer, then choose the hardware path by camera count. The build-a-system configurator steps through cameras, lights and controller as one system, and the systems topic page collects the surrounding guides on calibration, diagnostics and the robot side of the cycle. If the cell mixes fieldbuses nobody in the room has run before, the contact page reaches the applications team before you order.