For about two decades, the machine vision decision on a new line was simple enough that nobody thought of it as a decision. You bought a smart camera, pointed it at the part, wired a pass/fail signal into the PLC, and moved on. The vision logic lived in its own little island — its own IDE, its own processor, its own lifecycle, completely decoupled from the control system’s scan cycle. That default is now genuinely up for debate. Beckhoff’s TwinCAT Vision, Siemens’ vision function blocks in TIA Portal, and Rockwell’s FactoryTalk vision integration have all made it possible to run image acquisition, processing, and decisioning inside the same real-time execution environment that’s already running your motion and sequencing logic. That changes what “good enough” looks like, and it means the build decision deserves fresh scrutiny instead of institutional habit.
My position: PLC-native vision is the right call more often than the marketing suggests, but only for a specific and fairly narrow class of application — one defined by cycle-time coupling, not by inspection complexity. Get that distinction wrong and you’ll either strand a smart camera architecture that can’t keep up with takt, or you’ll cram a heavy vision workload into a control processor that starts dropping scan cycles under load.
The real question isn’t “how good is the vision,” it’s “how tightly is it coupled to motion”
Smart cameras and edge GPU boxes are excellent at vision. Modern smart cameras handle blob analysis, OCR, barcode decode, and even basic deep-learning classification entirely on-board, and edge boxes running GPU inference can chew through defect classification models that would never fit in a PLC’s cycle budget. Nobody should read this as “PLC vision is better vision.” It usually isn’t.
The reason to move vision into the controller is determinism, not accuracy. If the inspection result needs to gate a servo move, trigger a reject pusher within a tight window, or synchronize a trigger to an encoder position with no jitter, then every millisecond spent crossing a network boundary to an external device and waiting for a response is a millisecond of risk. A smart camera on a discrete Ethernet/IP or PROFINET connection typically introduces variable latency — not huge, but not zero, and not perfectly consistent scan to scan. On a slow-moving assembly cell doing a presence/absence check with a half-second dwell, that variability is irrelevant. On a high-speed pick-and-place or a rotary index table running sub-second cycles where the reject mechanism has a narrow physical window to act, that same variability can be the difference between a clean reject and a part that rides through to the next station.
So the actual test isn’t “is this inspection hard.” It’s: does the pass/fail result need to influence a motion command within the same deterministic task cycle that’s already running the axis? If yes, keep it in the controller. If the vision result just needs to land in a PLC input table sometime before the part reaches a downstream gate — with real margin — a standalone device is still the simpler, more maintainable choice.
Where PLC-native vision earns its keep
- Encoder-synchronized triggering on continuous motion, where the image capture itself has to be timed off the same axis position feedback the motion controller already owns — line-scan web inspection and rotary print inspection are the classic cases.
- Tight servo-reject coupling, where a fail decision has to command a diverter or pusher within a window measured in tens of milliseconds.
- Multi-axis coordinated moves that depend on vision-guided positioning — pick-to-orientation robotics feeding off the same real-time bus as the vision function block, rather than a separate protocol hop.
Where it’s the wrong tool
- Complex classification tasks (surface defect grading, cosmetic inspection, deep-learning-based anomaly detection) that need more compute and more frequent model retraining than a control processor’s cycle budget or lifecycle model comfortably supports.
- Stations with real dwell time — anywhere a part sits still for hundreds of milliseconds or more before the next action, which is most manual and semi-automated stations.
- Anywhere your vision engineer and controls engineer aren’t the same skill set and won’t be maintaining the same codebase happily. Vision algorithm tuning and PLC ladder/structured text maintenance are different disciplines, and putting them in one program can create a maintenance bottleneck if only one person on staff understands both halves.
Lighting and lens drift don’t care where the logic runs
Here’s a failure mode that architecture choice doesn’t fix: ambient light contamination and lens fouling across a shift. Whether your vision runs in TwinCAT or on a smart camera, if your lighting isn’t fully enclosed and strobed, you will see threshold drift as sunlight through a dock door changes angle over the day, or as a nearby weld cell’s flash bleeds into frame, or as a lens gradually collects mist from a coolant application three stations upstream. Plants that skip this and rely on “we set the thresholds at commissioning” are signing up for a slow accumulation of false rejects or, worse, false accepts that nobody notices until a customer complaint arrives.
The fix is the same regardless of where the logic lives: strobed, enclosed lighting with a fixed relationship to camera exposure; a documented re-teach procedure tied to shift changeover or a fixed calendar interval; and ideally an automated reference-target check — a calibration plaque or known-good part run through the station at shift start — that flags drift before it becomes scrap. If your vendor’s roadmap sells you on PLC-native vision as a way to simplify the system, don’t let that conversation skip lighting discipline. It’s still the single biggest source of real-world vision system failure, independent of where the pixels get processed.
The handoff to MES is where a lot of otherwise good architectures fall apart
A pass/fail bit landing in a PLC tag is not, by itself, quality data. For genealogy and hold logic to actually work, that result needs context: part serial or lot ID, station and fixture identity, timestamp, the specific inspection parameters that failed (not just a binary reject), and ideally a reference to the image or feature data itself for later disposition review. This is exactly the kind of structured event that ISA-95’s model expects to flow upward as a quality event, not just a discrete I/O point.
Whether the vision logic runs in the controller or on a smart camera, the integration pattern to MES should look the same: the PLC (or the smart camera talking through the PLC) publishes a structured quality result — via OPC UA, a message queue, or a direct MES connector — that includes enough metadata for the MES to make a hold decision without needing to reconstruct context after the fact. This matters more, not less, when vision moves into the PLC, because it’s tempting to treat an in-controller vision result as “just another interlock” and let it stay buried in ladder logic instead of routing it out as a proper quality event. Don’t let the architecture decision quietly demote your genealogy data. The reject bit stopping the conveyor is the easy part; making sure that failure is traceable to a specific serial number, six months later, when a customer return shows up, is the part that actually matters.
If there’s one practical rule to leave with: decide vision placement based on your motion coupling and cycle-time budget, not on vendor roadmaps or what your integrator defaults to. Then build the MES handoff as a first-class structured event no matter which architecture you land on. Get those two decisions right independently, and the rest of the implementation is comparatively easy.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
