Engineering
System Architecture & Reducing False Rejects
False rejects are usually an architecture symptom, not a threshold problem. Tightening software last is the point.
Direct answer
How do you reduce false rejects in a vision inspection system?
Work in physical order. First stabilize presentation and triggering so the feature lands in the same place every time. Second, fix illumination and exposure so contrast is repeatable across shifts and substrates. Third, separate the checks so one loose cosmetic tolerance is not gating a critical one. Only then adjust thresholds, and always re-measure against a labeled panel so you can see the escape/false-reject tradeoff you just made.
Architecture layers
An inspection system is a chain: presentation and fixturing, trigger and synchronization, illumination and optics, acquisition, inspection logic, verdict and controls handshake, then the data and audit record. Each layer's instability propagates upward, so debugging starts at the bottom, not at the algorithm.
Fig. — End-to-end inspection system flow
- 01
Part presentation
Conveyor, indexer, web path, fixturing, part orientation
- 02
Lighting & optics
Geometry, strobe, polarization, lens, working distance
- 03
Industrial camera(s)
Trigger-synchronised acquisition, one or many stations
- 04
VSA Inspect / IPC
Deterministic pipeline plus AI models where justified
- 05
Inspection logic
Recipe, tolerances, source-of-truth comparison, arbitration
- 06
PASS / FAIL / NO READ
Three distinct verdicts — never two
- 07
PLC & reject
Encoder-tracked reject window, fail-safe on loss of verdict
- 08
Image + quality record
Retained image, verdict, recipe, timestamp, operator
The false-reject investigation order
- 1. Collect the false-reject images. If they are not retained, fix that first — you cannot debug anecdotes.
- 2. Check registration: is the region of interest landing on the feature every time?
- 3. Check timing: trigger jitter or a drifting photo-eye moves the part between trigger and exposure.
- 4. Check illumination stability across shifts, LED age and ambient light.
- 5. Check product variation: legitimate but new appearance is not a defect.
- 6. Only then revisit tolerances, and quantify the escape rate you are accepting in exchange.
Fig. — Trigger, verdict and reject timing budget
Compute placement
The reject decision stays as close to the line as possible. Anything that crosses the plant network should be reporting, not real-time control.
- Smart camera
- One stable check, modest bandwidth, minimal data needs
- Industrial PC
- Multi-camera, heavy processing, custom algorithms, local retention
- Edge compute + GPU
- Learned models at rate; needs model lifecycle management
- Server / plant systems
- Aggregation, dashboards, long-term evidence — not the reject decision
Monitoring after go-live
- Trend reject rate by class, shift and SKU; a rising trend is usually drift, not new defects.
- Periodic golden-sample verification to detect illumination and focus drift.
- Alert on no-read spikes separately from fail spikes — they have different causes.
Frequently asked questions
- Our vision system rejects good parts. What is the first thing to check?
- Whether false-reject images are being retained, and then whether the region of interest is landing on the feature consistently. Presentation and trigger timing account for a large share of false rejects that get blamed on the algorithm.
- Should we just loosen the tolerance?
- Only with the escape cost quantified. Loosening a tolerance trades false rejects for escapes; that trade should be an explicit, documented quality decision rather than an afternoon adjustment.
Related engineering material