Vision system to PLC: send pass-fail results, not images

You have a vision system that has judged the part and a PLC that must act on the judgment — divert, reject, count, log. The question is what actually crosses the cable between the two. The answer that keeps both machines honest: the PLC receives a pass-fail verdict, not pixels. One discrete bit covers go/no-go; a result string of a few dozen bytes carries positions and counts. The image stays on the vision side and reaches a screen only through the HMI video link. Below is what each link in the cabinet should carry, the arithmetic that rules out moving frames into a controller, the scene setup that makes a verdict worth sending, and a worked timing example for a conveyor station. It is written for controls engineers wiring inspection into an existing program.

The decision, in one table

Every signal in an inspection station has a natural carrier. Verdicts and numbers belong on the control network; pixels belong on the video network; nothing carries pixels to the PLC. The table is the whole architecture:

The scan-time range is the PLC logic cycle itself; the serial and image times are worked out below.

What the PLC would do with an image: nothing

A PLC runs ladder or function-block logic in 1-10 ms cycles and holds registers, timers and small tracking arrays — memory budgeted in kilobytes to a few megabytes. Its instruction set has no operations for rows of pixels: no thresholds, no edge finders, no ROI geometry. A frame delivered to the controller is data the program can only copy or drop, and every scan that touches it is a scan not spent controlling the line.

The size settles the argument on its own. At 8 bits per pixel, a 1.6 MP gray frame is about 1,600,000 bytes — call it 1.6 MB. Sent over the same 9600-baud port that carries the 20-byte result telegram, that frame would need:

Even a gigabit Ethernet link moves the 12.8 Mbit payload in 12.8 ms — longer than a 10 ms scan, for one frame from one camera. The judgment logic lives where the pixels are, inside the vision device; the PLC sits downstream of the judgment. It is the muscle, not the judge.

The three channels that carry results

Pick the channel per signal, not per project. Most stations end up using two of the three.

Discrete I/O: the handshake

Three wires run most stations: a trigger output from the PLC into the vision device input, and verdict inputs back — pass and fail, or a single verdict line plus busy. Signal at 24 V DC with three-wire devices, matching the vision output type (PNP source, NPN sink) to the PLC input card wiring so an active verdict turns the input on. The verdict then lands within one scan, and the reject gate fires on the part that caused it.

For a single good/bad check at a fixed station this is the entire integration. Compact vision sensors built for exactly this job put sensor, lens and processing in one housing:

The MV-SCB007EC-12S-WBN pairs a 1.6 MP color sensor with a manual-focus 12 mm lens; the MV-SC3050XC-16M-ATN-H steps up to 5 MP when features shrink or ROIs multiply. Both are global-shutter devices on Fast Ethernet.

Serial ASCII: when numbers ride along

Add a serial link when the PLC also wants the position offset for the next pick, or the scene number for the log. The pattern is a fixed-position telegram sent after each inspection — scene, verdict, X offset, Y offset fits in about 20 bytes. Keep the whole string at or under roughly 32 bytes so one telegram always fits a single receive-and-parse pass. At 9600 baud with 8 data bits, no parity, one stop bit:

That 21 ms trails the verdict bit, so give serial the data the control logic can wait for: offsets applied next cycle, counts, traceability. The reject pulse itself stays on discrete I/O. The fixed-position RS232 telegram pattern shows the frame layout end to end, and storing ASCII result strings in PLC memory handles the receive side, including clearing the buffer so stale characters never masquerade as fresh results.

Ethernet: registers, sockets or tags

Above a handful of values per part, move the handshake onto the network. Three shapes, in rising order of setup effort:

• Register handshake — the vision device writes result words into mapped PLC registers and toggles a done bit. The register handshake with vision coordinates walks the done-data-acknowledge cycle.
• Raw TCP socket — the vision device opens a client connection to a PLC port and streams the same ASCII string. Where no register mapping exists this is the fallback, as in sending device data over raw TCP sockets.
• OPC UA — when a SCADA layer already browses tags, expose results as nodes; reading smart-camera results over OPC UA covers the session and namespace work.

A register write completes in a few milliseconds on a clean LAN — the same order as a scan — so this channel can carry verdicts too once discrete points run out. Pin fixed addresses on one subnet and confirm both ends listen before commissioning day.

The video link: pixels to a screen, never data to the logic

The operator needs to see the camera image at commissioning and whenever a part fails review. That is the HMI job through its video path: a video input card in the HMI takes the feed from the vision device, and a video display object draws it on the screen. The path is one-way by design — picture out, no results back. Buttons, lamps and set-points on the same HMI travel over the HMI communications link to the PLC. Three cables, three jobs: vision to HMI for eyes, HMI to PLC for control, vision to PLC for verdicts.

What a smart-camera image actually shows in a PLC HMI untangles which path a given screen uses, and vision-sensor results to an HMI over EtherNet/IP covers the case where the display must also carry the numeric verdicts.

Set the scene before the handshake

A verdict is only as good as the image behind it, so sequence the work lighting first, logic second, comms last:

1. Fix illumination and exposure manually. Auto modes chase ambient light, and brightness that drifts over time turns a stable threshold into intermittent failures. Where hall lighting changes through the day, control ambient variation at the station or strobe a light through a light controller to freeze the look of the part.
2. Define one scene per part presentation: its ROIs, thresholds and pass criteria. The device processes one scene per trigger; switch scenes with discrete select bits or a serial command when the line changes product.
3. Enable position compensation when parts arrive un-oriented, so the ROIs follow the part instead of demanding mechanical alignment.
4. Map results onto I/O or registers last, once a thousand consecutive images inspect the same way.

The order is not ceremony: valid results exist only downstream of controlled images, the same chain described in why controlled images come before valid results.

A worked timing example

Belt at 6,000 parts per hour — 100 per minute, one part every 600 ms. The station checks a 10 mm logo on a label and diverts misses.

• Exposure: 1 ms strobed flash. Blur = belt speed × exposure = 1,000 mm/s × 0.001 s = 1 mm, small against the 10 mm feature.
• Processing: 25 ms for a two-ROI check on this class of vision sensor; budget 25-50 ms and read the real figure off the tool at commissioning.
• Verdict over discrete I/O: one PLC scan, 5 ms here.

Trigger to reject-ready: 1 + 25 + 5 = 31 ms. That is 31 ÷ 600 ≈ 5% of the part pitch, leaving about 569 ms of margin — the verdict is not the bottleneck, the divert mechanics are. Adding the 20-byte telegram over serial contributes 21 ms, still inside the margin. Trying to deliver the 1.6 MB frame instead would have cost about 28 minutes over the serial port, or 12.8 ms even on an idle gigabit link — beyond the 10 ms scan budget. The channel choice decides whether the verdict beats the part to the gate.

Which channel when

Per case:

• Go/no-go at a gate: discrete I/O, nothing else.
• Verdict plus X/Y correction: discrete verdict plus a register handshake for the coordinates.
• Several cameras, or NG images kept for review: a vision controller runs the tools and talks Ethernet to the PLC while discrete I/O still carries the verdict. This is the point where a sensor gives way to a controller:

The MV-VC2140-128G40-1T brings 4 built-in light channels and 3-4 LAN ports, so lights and cameras hang off one box; the MV-VC3301H-128G66 adds PCIe expansion and ships with the VM6200Pro vision runtime licence.

• Yield trends and measurement history: OPC UA tags or a database write from the vision side — keep bulky history out of PLC registers.

Checks before you wire

• Count the points: trigger in, pass out, fail out, busy out — 4 discrete points per vision device, plus 2 scene-select bits if the line changes product.
• Match polarity: PNP source with sourcing inputs, NPN sink with sinking; a mismatch reads as an input permanently on or off.
• Reserve buffer: serial receive space for one full telegram plus terminator, cleared after every read.
• Pin the network: fixed addresses, one subnet, both ends listening — proven with a raw send before any handshake logic exists.
• Give the operator eyes: a video input on the HMI if the image matters, a verdict lamp on the gate if not.

When the usual answer is wrong

• A person reviews failures: NG images leave the vision system over FTP to a file server or HMI archive, as in pushing NG images to an HMI over FTP — still never through PLC memory.
• The historian wants every measurement: write rows to a database from the vision side, as in sending vision results to a database as ASCII. The PLC keeps the last part, not the last million.
• The controller running the line is a vision controller: it is the one device allowed to hold images, because its tools consume them. Anything downstream of it still receives bytes.
• Someone proposes mapping pixel data into PLC arrays for analysis later: that analysis lives on the vision side or in a historian, and the mapping is the project risk, not the analysis.

Where to go next

Size the station from the verdict backwards: choose the channel, count the I/O points, then pick hardware. Start in the smart camera and vision sensor category for single-check stations, the vision controller category for multi-camera cells, and the camera finder when resolution and interface filters do the narrowing. The systems topic page collects the integration guides around this one, from register handshakes to HMI displays; for a second pair of eyes on the handshake map before you cut wire, contact the applications team.