For most of the last decade, the machine vision decision was simple: buy a smart camera, point it at the part, wire a pass/fail bit into the PLC, move on. The interesting work happened in the cloud or on a training workstation somewhere, and the plant floor just consumed the output. That division of labor is breaking down. Siemens has vision function blocks in SIMATIC S7-1500 firmware and TIA Portal. Rockwell supports vision-guided motion natively through ControlLogix and Studio 5000. Beckhoff has TwinCAT Vision running inference inside the same real-time runtime that’s doing your motion control. Meanwhile Cognex, Keyence, and Basler keep pushing more edge-AI horsepower into the camera head itself, so the smart camera side of the argument hasn’t stood still either.
So now you have an actual architecture decision, not a foregone conclusion. Where does the model live: in the controller, or in the camera? My position is that this isn’t a technology preference question — it’s a question about who owns the failure mode when the model is wrong, and how fast you need an answer. Get those two things straight first, and the hardware choice mostly picks itself.
Start with the latency budget, not the vendor pitch
The honest first question is: what happens in the milliseconds after the image is captured? If the answer is “a servo has to react before the part moves another few millimeters” — vision-guided pick-and-place, web-guided registration, high-speed reject at the sortation gate — you want inference as close to the motion control loop as possible. That’s the argument for embedding vision in the PLC or motion controller: TwinCAT Vision running in the same task cycle as your axis control, or a Logix vision instruction feeding coordinates directly into a kinematic transform, avoids the round trip to a separate device and back over EtherNet/IP or PROFINET. You’re not paying network hop latency, and you’re not dealing with two separate clocks that need synchronizing.
If the answer is closer to “a human or a diverter has a few hundred milliseconds to a couple of seconds to act,” a smart camera’s onboard latency is almost never your bottleneck — your reject mechanism or your operator’s reaction time is. That covers the large majority of defect-detection stations: surface inspection, label verification, presence/absence, cosmetic grading. In that world, the case for embedding vision in the controller weakens considerably, because you’re not buying back any meaningful time, and you’re giving something up to get there.
What you give up when vision lives in the PLC
What you give up is workflow separation. A controls engineer who is excellent at ladder logic, structured text, and motion sequencing is not automatically good at managing a computer vision model’s lifecycle — and increasingly, they don’t have to be, because that’s a genuinely different discipline. Smart camera platforms from Cognex, Keyence, and Basler have spent years building tooling specifically for that non-controls audience: image acquisition wizards, labeling interfaces, deep-learning defect classifiers with retraining workflows that don’t require touching a line of PLC code. That tooling exists because camera vendors correctly bet that the person tuning a defect model and the person maintaining the safety PLC are usually not the same person, and probably shouldn’t be.
Embed the model in the PLC and you’ve collapsed that separation whether you meant to or not. Now retraining the model — because the product mix changed, the substrate color shifted, a new SKU has different acceptable tolerances — means someone is pushing a change into the same firmware and program that runs your safety-rated motion. Even where the vision function block is logically isolated from the safety task, you’ve still put model lifecycle management inside the change-control process for your control system, with all the validation, versioning, and downtime-for-download overhead that implies. On a line running one product family with infrequent changeover, that’s a manageable tradeoff. On a line with frequent SKU changes or seasonal product mix, it’s a genuine liability.
Who actually owns the model, six months from now
This is the question nobody asks in the demo and everybody fights about a year later. A trained vision model isn’t a static asset — it’s a thing that quietly degrades as your product, packaging, lighting, or supplier substrate drifts, and someone has to notice that and retrain it. If that model lives inside PLC firmware, retraining is a controls-engineering task by default, gated by the same change windows as everything else in the cabinet. If it lives on a smart camera or an edge appliance sitting beside the line, it can be owned by a quality engineer or a manufacturing data-science function with its own versioning and its own release cadence, decoupled from control system change control entirely.
Decide this organizationally before you decide it technically. If your plant doesn’t have anyone besides the controls team who can own a model lifecycle, embedding vision in the PLC just means the controls team owns it by default — which is fine, as long as you’re honest that you’ve made that call rather than backed into it.
Stop treating vision output as a silent bit
Whichever architecture you pick, fix the thing that’s actually broken at most plants today: vision results get reduced to a pass/fail bit and disappear into the PLC’s I/O table, with no trace of what the model saw, how confident it was, or what changed. That’s a quality event, and it should be surfaced as one — tagged with part ID, timestamp, model version, and confidence score, and pushed into MES or a quality data historian as a structured record, not just toggled on a rung.
This matters more as models get more nuanced. A binary reject tells you nothing about whether your defect classifier is drifting toward more borderline calls, or whether a specific defect class is trending up before it becomes a scrap problem. Route vision inference results through OPC UA or MQTT Sparkplug B into your MES quality module the same way you’d handle an SPC out-of-spec event, and you get a genuine early-warning system. Leave it as a silent bit, and you’ve built an inspection station that can’t tell you it’s starting to fail.
The actual decision framework
- Sub-cycle-time motion coupling required: embed vision in the PLC or motion controller. The latency win is real and worth the lifecycle tradeoff.
- Defect detection or grading with human or mechanical reaction time in the hundreds of milliseconds or more: use a smart camera or edge-AI appliance. You’re not buying back meaningful time by embedding it, and you keep model retraining out of your control system’s change process.
- Frequent product mix or SKU changes: weight heavily toward smart camera platforms with dedicated retraining tooling, regardless of latency, because you’ll be retraining often and want that decoupled from PLC change control.
- No dedicated quality/data-science resource on staff: be honest that embedding vision in the PLC puts model ownership on controls engineers by default — plan for that rather than discovering it.
- Either architecture: stop wiring vision output as a bare pass/fail bit. Tag it, timestamp it, version it, and send it to MES as a quality event.
The vendors pushing vision function blocks into PLC firmware aren’t wrong that the technology works — the round-trip latency savings are real, and for motion-coupled applications that matters. But “it works” was never the hard part of machine vision. The hard part was always keeping the model honest six months after commissioning, and that’s an organizational question, not a firmware feature. Answer that one first.
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.
