The match tool has found the part — score good, pose good — and nothing happens, because the verdict lives inside the camera. The machine only moves when the PLC sees it. Getting a vision match result into a PLC output is a wiring and timing problem, not an image-processing one: pick the transport (discrete pulse, serial telegram or TCP message), size the pulse so no PLC scan can miss it, land the right polarity, and close the loop with a handshake. The numbers you need are below: a 50 ms practical pulse minimum at a 10 ms scan, a two-resistor drop from the I/O supply rail to a 3.3 V microcontroller pin, and a 100-part test that proves the handoff before the line runs.
What you need
- A vision device whose inspection can drive a digital output: a smart camera's I/O or strobe line, or an output on a vision controller.
- A PLC 24 V DC input; optocoupled inputs are the standard choice.
- For a microcontroller or FPGA, one logic pin plus a resistor divider or an optocoupler.
- A supply for the I/O loop at the input card's rated voltage, shielded signal cable, and an oscilloscope (or a PLC that timestamps inputs each scan).
For a new station, start from the smart cameras and vision controllers categories. A vision sensor such as the MV-SC3050XC-16M-ATN-H — 5 MP color, global shutter, Fast Ethernet — judges the part on the device, and the only thing that leaves the station is the signal you wire.
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Sensor format
- 1/1.45"
- Shutter
- Global
Step 1: pick the transport
Match the transport to what the machine does with the verdict:
| What the machine does | Transport | What travels |
|---|---|---|
| Accept or reject each part | One discrete pulse | 1 bit per part |
| Sort, guide a robot, log a grade | Pulse plus message | Verdict with coordinates |
| Feed SCADA or MES as well | TCP or UDP on the plant network | Verdict with data, no extra I/O |
If the machine only accepts or rejects, wire the pulse and stop there: one bit per scan is the fastest, most reliable verdict a PLC can read. Coordinates, angles and grades cannot ride a discrete line — they take the serial and network paths in Step 6.
Step 2: size the pulse to the PLC scan
A PLC samples its inputs once per scan. A pulse shorter than one scan can fall entirely between two samples, and the PLC never learns about a part the camera passed. The working rule:
Three scans: one to notice, one to act, one of margin for scan jitter. At a 10 ms scan the formula gives 30 ms; integration practice keeps acknowledge pulses between 50 and 250 ms, because input filters and busy scans add jitter the formula cannot see. Set the result pulse at 50 ms or more, and under 500 ms so it cannot eat the cycle time.
A latched handshake removes the width limit: the output holds until the PLC acknowledges, so even a 5 ms scan cannot miss it. That takes a second wire — Step 5 builds it. When the same inspection strobes a light, the pulse width you choose decides whether the image catches flicker bands or dark bars; black bars in some camera images: flicker vs exposure shows how to tell the two apart.
Step 3: wire the discrete loop
Follow the input card's common wiring. A sourcing (PNP) output pushes the loop voltage high and pairs with a sinking input whose common sits near 0 V; a sinking (NPN) output pulls to 0 V and pairs with a sourcing input. Most DC input modules accept either — the decision is which common terminal you land, and it must stay one convention across the cell.
Optocoupled inputs isolate the camera's electronics from the PLC ground, so a ground loop through a VFD-driven conveyor cannot corrupt a verdict. Keep signal cable away from motor cables and ground the shield at one end only.
A smart camera exposes this function on its strobe line: the same two wires that fire a light can announce the result once you reconfigure the output — enable a smart camera's strobe output and wire the light shows how. A light that needs more power than that output passes goes on a separate light controller; its trigger wiring is identical.
Step 4: feed a microcontroller or FPGA
Two legitimate paths from a high-voltage result line to a logic pin:
Divider, shared ground. R1 = 10 kΩ from the 24 V line to the pin, R2 = 1.5 kΩ from the pin to 0 V. Loop current: 24 V / 11.5 kΩ = 2.1 mA. Pin voltage: 24 V × 1.5 / 11.5 = 3.13 V — above the roughly 2.3 V high threshold of a 3.3 V input (70% of the rail) and below the rail itself. Keep the ratio near 6.7 : 1 for 3.3 V logic.
Optocoupler, separate grounds. A series resistor sets the LED current: (24 V − 1.2 V) / 2.2 kΩ ≈ 10 mA, comfortable for any common optocoupler. The logic side pulls up to its own 3.3 V rail and the two grounds never touch. Use this whenever the camera and the controller do not share a clean 0 V.
For an FPGA, size for the bank's absolute maximum — most 3.3 V banks tolerate nothing above about 3.6 V.
Step 5: close the loop with a handshake
A free-running pulse works until the first hung inspection. Two extra lines and five steps fix that:
- The PLC or a part sensor asserts the camera's trigger input when the part is in position.
- The camera exposes, transfers and processes; latency is typically 100-250 ms. Measure yours.
- The camera asserts Result, plus Data-valid when a message follows, and holds it.
- The PLC reads Result, acts, and pulses Reset for at least one scan.
- The camera drops Result and arms for the next trigger.
Never re-trigger before Reset arrives: the second result lands while the first is still high, and the PLC counts one part twice. Vendor integration guides formalize the same loop as a four-line status-bit handshake (ready, busy, result, reset); two lines cover most machines. When the data moves as registers rather than text, the pattern is identical — see send vision coordinates to a PLC through a register handshake. Robot controllers consume the same handoff; this worked example sets a digital output straight from a vision result.
Step 6: send the coordinates when they are needed
A pulse says the part passed; a message says where it is. Two transports cover it:
- RS-232 with a fixed-position telegram. The same byte count on every shot, verdict and coordinates at fixed offsets, so the PLC parses by position instead of searching. Build one with a fixed-position RS-232 telegram.
- TCP when a robot, a second PLC or a database wants the data. A short string per part, sent the moment Result asserts — part coordinates over TCP walks the full cycle.
Keep the discrete pulse in both cases: the PLC latches the verdict instantly while the message is still in flight, and the handshake tells it when the bytes are complete.
Verify the handoff before the line runs
- Scope the output at the PLC terminal: measure the high time, confirm 50 ms or more, and look for a second edge after the first.
- Count: run 100 parts past the trigger sensor and compare the PLC's received-result counter with the sensor count. It must read 100 of 100.
- Run the worst case: full line speed, all lights on, guards closed. Vision latency must stay inside the PLC's result window on every cycle.
- Fail a part on purpose — present a known-bad part or block the trigger — and confirm the reject actuator fires on the fail pulse, not only on the pass.
- Power-cycle the camera mid-batch: the handshake must resynchronize without losing the next part.
A counter that lags by exactly one part at full speed is the late-Reset signature; a counter that drops parts at random means the pulse is too short for the scan. Widen the pulse or latch the handshake, then repeat the 100-part count.
Common mistakes
- A 5-10 ms pulse into a 10 ms scan. Losses that move with line speed. Set 50 ms or latch the handshake.
- Re-triggering before Reset. Double counts and a stalled handshake.
- Loop voltage on a logic pin. The Step 4 divider is two resistors; a replaced port is a board.
- Auto exposure left on. Exposure changes shift latency shot to shot — the same drift that moves image brightness over time. Pin the exposure once the image is right.
- Sharing the strobe line without reconfiguring it. The light fires when you expected the verdict.
Which parts fit, and the decision
For a single-camera station, a smart camera with the light built in removes a wiring run: the LS-SMC-0063 pairs a 1.6 MP, 60 fps camera with a 16 mm lens and an integrated white light, so only the result line leaves the station.
- Interface
- GigE
- Resolution
- Up to 3 MP
Multi-camera cells belong on a vision controller. The MV-VC3301H-128G66 runs the inspections on an Intel Core i3 with 8 GB memory and 4 built-in light channels; the MV-VC5525-256G70-NN adds PoE camera ports and 8 built-in light channels, so one cable serves each camera. Verdicts leave as short network messages or a discrete line, and the PLC input stays as simple as Step 2 made it.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
The decision per station:
- Pass/fail only: a vision sensor or smart camera, one 50 ms result pulse, two wires into the input card.
- Verdict plus coordinates: the same pulse, plus an RS-232 telegram or a TCP string with fixed offsets.
- Several cameras and strobed lights: a vision controller with built-in light channels; the PLC still sees one trigger in and one result out per inspection.
Lay out your signal list — trigger in, result out, reset back — and size the widths from Step 2 before ordering. The other systems guides cover the message formats in more depth; the build configurator sequences camera, controller and I/O choices in order, and a quote is the fast path for a multi-camera cell.
Questions
What pulse width should a pass/fail output use?
Work from three scans as the floor: at a 10 ms scan that is 30 ms, but set 50 ms so input filters and busy scans cannot eat the margin. 100 ms is comfortable and still invisible next to a 500 ms cycle. Beyond 500 ms the pulse starts eating cycle time — switch to a latched handshake instead, and set the PLC input filter below a third of whichever width you choose.
Can part coordinates travel over the same wire?
No. A discrete line carries one bit, so it says pass or fail and nothing else. Coordinates, angles and grades need a message — a fixed-length RS-232 telegram or a short TCP string — sent alongside the pulse. Keep the pulse anyway: the PLC latches the verdict instantly and uses the handshake to know when the message bytes are complete.
PNP or NPN for a vision output into a PLC?
Follow the input card's common wiring. A sourcing (PNP) output feeds a sinking input with its common near 0 V; a sinking (NPN) output feeds a sourcing input. Most DC input cards accept either by moving one common wire, and a mismatch shows up as an input that never changes state rather than damage. Pick one convention per cell and keep every station the same.
How long from trigger to result on a smart camera?
Latency is exposure plus transfer plus processing. A 5 MP 8-bit frame is about 5 MB, so over GigE at roughly 100 MB/s the transfer alone is about 50 ms; exposure adds a few milliseconds and processing takes the rest. Total of 100-250 ms is typical. Measure it once on your part, add margin, and keep the result window wider than that worst case.
Does a vision controller replace the PLC?
No, and the split should stay clean. The vision controller runs inspections, drives the lights from its built-in channels and returns verdicts plus data; the PLC keeps machine sequencing, motion and every safety function. The handoff stays one trigger in and one result out per inspection. Never let the vision side hold an interlock: if it hangs, the machine must still stop safely on its own.



