A vision system for manufacturing quality control is a chain of parts: dedicated lighting, a lens and camera, a processor running the inspection software, and an interface that passes a pass/fail decision to the PLC, which removes the part. The order you decide things in also matters. First decide whether the inspection runs inline or offline. Then specify the lighting first, then the camera and the compute, and only then the model. The reject path has to be timed to the millisecond. Deployment takes optics, lighting, integration with control logic and validation, not just neural-network training.
Which parts does an inspection system need, and which one limits accuracy?
Cognex lists the hardware of a machine vision system as a coordinated set of cameras, lenses, lighting and processors, with the exact configuration set by what the inspection has to do. The industry association A3 gives a similar list: an imaging device with a sensor and lens, an optional frame grabber (modern digital interfaces often do without one), lighting suited to the application, a computer (unless a smart camera does the processing on board) and image processing software.
A machine vision camera is one constrained variable in an imaging chain whose job is to make the smallest in-spec defect visible at line speed before any model sees a frame. The image is formed by lighting, optics, fixturing and capture timing long before inference runs, so the weakest link caps the accuracy the system can ever reach. Teams under inspection-cost pressure forget this when they buy a high-resolution sensor and assume the model will do the rest.
When should we choose inline over offline inspection?
Choose inline when every part must be checked and an escaped defect carries safety, liability or recall cost. Offline is the better choice when the measurement needs dwell time, fixturing or physics that cannot run on a moving line. Inline inspection sits in the production flow: parts are inspected without leaving the conveyor, and an OK/NG decision is issued in real time while production continues, which gives 100% coverage. Offline inspection takes parts to a separate station, such as a CMM, a lab optical system or a manual bench. There the check can be more thorough, but only a sample is inspected, and by the time a defect is found more bad parts may already have been made.
UnitX starts from the consequence of a defect. Where one escaped part means a safety risk, liability or a recall (automotive safety components, EV battery cells, medical devices, structural aerospace parts), the answer is almost always 100% inline, because sampling cannot guarantee zero escapes by definition. For cosmetic defects that lead to a warranty exchange, offline sampling may be the cost-appropriate choice.
The type of defect also decides where the inspection belongs. Sub-surface cracks that only X-ray or ultrasound can find, and complex 3D dimensional checks that need CMM fixturing, belong offline whatever the throughput. Surface defects (scratches, pits, contamination, coating failures, weld and solder quality) suit inline 2D and 2.5D imaging, because the capture geometry can be fixed for a given part type. Line speed is the other constraint. Rule-based systems on complex geometry sometimes needed the line stopped for capture, so manufacturers ended up sampling offline by default rather than by choice.
A decision table for placing the inspection
| Situation | Where the inspection belongs |
|---|---|
| An escaped defect creates safety, liability or recall exposure | Inline, 100% coverage |
| Cosmetic defect, warranty-level consequence | Offline sampling may be enough, depending on customer tolerance |
| Surface or assembly defects with repeatable geometry | Inline 2D/2.5D imaging |
| Sub-surface defects, multi-parameter 3D dimensional checks | Offline (X-ray, ultrasound, CMM) |
| Production start, tooling changes, root-cause checks on inline flags | Offline first-article inspection and audit |
For high-volume lines with safety-critical or aesthetically demanding parts, the recommended quality control inspection workflow is layered. UnitX describes a three-layer design: 100% inline inspection at critical stations, at-line review of a sample of NG-flagged parts to tell process drift from random events and avoid line stops on false alarms, and offline first-article and periodic dimensional audits to catch systematic drift.
Why is illumination so often the project killer?
Software cannot correct poor lighting afterwards. Cognex states that lighting geometry, wavelength and intensity determine what a camera can and cannot detect, and that no software upgrade makes up for poor illumination. A wrong lighting technique degrades model accuracy and raises false rejects. What the camera sees is light reflected from the part, so geometry decides which features are bright, which are dark and which disappear completely.
Reliable systems tune three variables together: geometry (angle and direction relative to part and camera), wavelength (how the material responds to the spectrum), and intensity and timing (brightness, pulse length and synchronisation with exposure). Every vision system should have its own dedicated light, specified for that inspection alone. A high-intensity light that only the vision system controls, used with a short exposure, removes the variation from ambient light. Strobe timing has a trap of its own: Cognex’s guidance is to wire the strobe to the camera, because driving it from the PLC introduces timing offsets that cause intermittent image failures that are hard to diagnose.
Edmund Optics gives a starting point for matching illumination to the object:
| Requirement | Object | Suggested illumination |
|---|---|---|
| Reduce specular glare | Shiny object | Diffuse front, diffuse axial, polarising |
| Highlight surface defects or topology | Nearly flat object | Single directional, structured light |
| Reduce shadows | Object with protrusions, 3D object | Diffuse front, diffuse axial, ring light |
| Highlight defects inside the object | Transparent object | Darkfield |
| Silhouette for edges and measurement | Any object | Backlighting |
| 3D shape profiling | 3D object | Structured light |
Edmund Optics also notes that the image quality you want can usually be reached by improving illumination rather than by buying a higher-resolution detector, a better lens or more software. Cognex makes the same point from the other side: get the lighting right first, and camera choice, algorithm setup and model training all become faster and cheaper.
Line-scan or area camera: how do we decide?
The decision turns on conveyor speed and object shape. An area-scan camera captures a full 2D frame in one exposure. A line-scan camera builds the image one row at a time, which suits moving webs and rotating objects. Cognex’s rule of thumb is that a line running faster than about 2 m/s with continuous product flow almost always calls for line-scan. For discrete parts at moderate speed, area-scan offers simpler integration, lower cost and easier deployment.
Line-scan integration is more complex. It needs precise motion control and linear lighting, and the line rate has to track conveyor speed, typically through an encoder. If the speed changes and the line rate does not, the image compresses or stretches and the measurements are distorted. Cognex names motion blur, encoder mismatch and lighting errors as the three most common and costly specification mistakes, and all three can be prevented with proper application analysis.
Interfaces and bandwidth for the vision system camera
The interface is part of the camera decision because machine vision cameras normally stream uncompressed video. Roboflow works the numbers: a 1920 × 1080 RGB stream at 30 FPS carries about 1.49 Gbit/s, and Gigabit Ethernet provides 125 MB/s for image data, control and resends combined, so one such colour stream already exceeds it. The common standards are GigE Vision (released 2006), USB3 Vision, CoaXPress and Camera Link HS. USB3 Vision dates from 2013 and shares the GenICam basis with GigE Vision, which gives vendor-neutral software a common way to name camera features. Tech Briefs frames the choice between them as a trade-off between cable length, latency and CPU load, judged per application.
Compute is the constraint the model has to fit
The industrial computer on the line is not something you buy after choosing the model. It is the constraint the model has to fit inside. Cognex sets out the processing hierarchy: deep learning generally needs GPUs, edge learning needs less, and rule-based algorithms the least. Smart cameras with on-board processing can handle rule-based and edge-learning jobs alone, while deep learning may need a separate PC.
Roboflow’s list of selection factors is a sound one: frames per camera that actually need processing, environmental protection, operating temperature, available I/O and how long the hardware will stay supported. The throughput target comes from line speed, camera count, inspection frequency and the decision window. A 30 FPS camera delivers a frame about every 33 ms, but not every frame necessarily needs inference. The reasons for running at the edge are concrete: a reject deadline in milliseconds, more raw video than the network can carry, and a line that must keep running when the WAN does not. Whether those reasons outweigh cloud costs across a plant is an economic question weighed in AI in manufacturing, edge vs cloud.
How the vision system talks to the PLC to reject a part
The vision system decides what it sees. The PLC keeps ownership of machine timing, safety interlocks, watchdog logic and physical actuation. The PLC combines the vision tag with its own encoder, part tracking, interlocks and reject-station timing. Roboflow argues this is safer than having an application switch an actuator directly, because control stays inside deterministic machine logic. We hold the same view: a modular split, with the decision exposed as tags the controls team can inspect, is what lets you find out where and why a missed reject happened, rather than debugging one opaque box.
The plant usually chooses the protocol. iFactory observes that Allen-Bradley plants use EtherNet/IP, Siemens plants use PROFINET, and mixed brownfield sites fall back to Modbus TCP or OPC UA. OPC UA Vision, the VDMA companion specification, models a vision system generically through a state machine, from simple sensors to complex inspection stations, aiming at interoperability that does not depend on the manufacturer.
Whichever protocol you use, the integration is a handshake, not a single signal:
- The PLC tells the vision system a part is approaching and triggers acquisition. On Cognex In-Sight over EtherNet/IP, a trigger that cannot be served sets a Missed Acquisition status bit.
- The vision system captures, infers and returns pass or fail, for example through a Job Pass bit set only when the inspection completes and passes.
- The PLC latches the decision and tracks the part in a belt shift register. Each encoder or photoeye step shifts the fail flags one slot, and the actuator fires when a flagged slot reaches the reject index.
- The PLC sends back changeover and reject confirmation, so the vision system loads the right model for a new SKU and can check that the stroke actually completed.
iFactory describes a configurable timeout: a missing decision is treated as a hard fail on pharmaceutical or safety-critical automotive lines, and often as a hard pass with a logged event on high-volume consumer lines. Siemens’ Inspekto PROFINET documentation (2024) takes the conservative line for its own result codes, recommending that the PLC treat both “detected but not inspected” and “not detected, timeout reached” as FAIL. We would write that default into the line specification before commissioning, not leave it to whatever the integrator’s template does.
What latency budget should we plan for between camera and reject?
Plan for the whole loop, from trigger to the part leaving the belt, to finish before the next good part reaches the reject station. iFactory puts that window at often under 200 ms on a 60 parts-per-minute line. Miss it by 20 ms and the reject fires on the good part behind; miss it by 100 ms and the defective part ships.
iFactory’s typical breakdown for a 60 parts-per-minute discrete line:
| Stage | Typical latency |
|---|---|
| Camera trigger and capture | 6-10 ms |
| AI inference on edge GPU | 20-45 ms |
| EtherNet/IP or PROFINET to PLC | 2-5 ms |
| PLC scan and ladder decision | 2-4 ms |
| PLC output to actuator coil | 1-3 ms |
| Actuator physical stroke | 15-80 ms |
| Total end to end | 50-150 ms |
The actuator is usually the largest item. A pneumatic cylinder responds in tens of milliseconds, a servo diverter in single digits, and an air-blast reject faster still, so choosing the mechanism matters as much as choosing the model. Inference is the most tunable stage: a distilled model saves budget but may need PLC-side verification to catch its false negatives. When line speed changes, the reject delay in the shift register is the first thing to retune.
What false reject and false accept rates are realistic?
We would not quote a false reject or false accept rate for your line without measuring it there. What you can rely on is how the two errors behave. A false acceptance passes a defective part (consumer risk: escapes, recalls, supplier deratings). A false rejection fails a good part (producer risk: scrap, rework, lost yield). Tightening detection to cut one raises the other, so the aim is an operating point, set per defect class. Critical defects get conservative thresholds that minimise escapes even at the cost of more rejects. Cosmetic defects get permissive thresholds.
For the same reason we would not accept an accuracy figure as evidence. When defects are rare, a system that passes everything still scores high accuracy, so escapes and overkill have to be reported as separate rates. Carvalho, Durupt and Grandvalet (2023) note that a valid evaluation needs data never seen in training, and that real production data is preferable because it carries variation from ambient lighting, temperature and camera settings. Those conditions drift after go-live, with new material batches, ageing lights and seasonal temperature, which is why both rates need monitoring with alert thresholds in production. How models degrade after commissioning, and why off-the-shelf CV stops working, is the subject of our wider manufacturing guide.
Who can build and integrate a vision system for our line?
TechnoLynx’s computer vision R&D team engineers the inspection system around your line’s constraints: the imaging chain, a model sized to the edge hardware and the latency budget, and a decision interface your controls team can see into and own. On whether to build in-house or bring in a specialist: a team with strong controls and optics skills but little experience fitting deep-learning models into a fixed millisecond and hardware budget is where outside engineering earns its place. When choosing a partner, ask them to show the latency budget, the timeout behaviour and the per-class error targets before any model training starts.
That engagement is not the right fit for everyone. If your inspection is a standard check that a smart camera with rule-based tools already solves, the camera vendor or a local machine-vision integrator can deliver it. Mechanical reject hardware, PLC programming in your plant’s standard and process validation sign-off stay with your controls and quality teams or their usual integrator.
Machine vision or computer vision: does the distinction matter for QC?
For a quality engineer, the machine vision vs computer vision distinction matters less than the pipeline behind it. A3 defines machine vision as computer vision applied in an industrial process to trigger a function from the image analysis: routing products, diverting defects or stopping a line. The components of a basic system of either kind are generally the same. What decides a QC project is not the label. It is whether the decision leaves the image analysis as a timed, observable signal that a PLC can act on, with lighting and optics that put the defect in the image to begin with.
