Design a Reliable Machine Vision Reject Station
Track each inspected part from trigger to confirmed removal using deterministic timing, queue logic, fail-safe states, and reject verification.
The vision algorithm identifies every defective bottle in a recorded test, yet occasional bad bottles still reach the packer. The fault is not image recognition: conveyor slip, variable spacing, delayed results, a full reject bin, double feeds, and an unverified air blast cause the wrong physical item to be removed. A reliable inspection needs a closed chain from part identity to confirmed disposition.
The method below is vendor-neutral. The worked example is explicitly hypothetical; replace its assumptions with measurements from the actual product, line, and risk assessment.
What you will learn
Identify the physical or data-system limit behind vision reject-station design.
Convert the inspection need into measurable acceptance criteria.
Select a practical architecture without hiding important trade-offs.
Commission the system using repeatable tests instead of visual impressions.
Validate performance under representative production variation.
Technical foundation
Inspection and disposition are different functions
The camera decides about an observed part. The material-handling system must associate that decision with the same physical item and execute the correct action later. System escape rate includes recognition errors plus tracking, actuator, and verification failures.
Distance tracking is often better than time delay
When conveyor speed changes, a fixed timer shifts the reject point. Encoder counts tied to belt or mechanism motion can preserve position, but slip between product and measured surface, acceleration, backlash, and encoder faults remain.
A reject should have an observable completion
A command to a solenoid is not proof that the part left the good stream. A downstream sensor, reject-chute sensor, image check, weight change, or count reconciliation can confirm disposition. The required assurance depends on risk and mechanics.
Related guides on this publication: Machine Vision PLC Integration: A Robust Handshake and Machine Vision Triggering and Encoder Synchronization and False Accepts and False Rejects in Machine Vision.
Engineering workflow
1. Define every physical state
Evaluate: single part, closely spaced parts, double feed, missing part, stopped conveyor, accumulation, rework, startup, shutdown, and manual removal.
Why it matters: tracking logic must behave deterministically outside the ideal sequence.
Measure or calculate: draw state and timing diagrams with part identity from entry to accept and reject destinations. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: more states require more logic but eliminate undocumented behaviour. Common failure: testing only evenly spaced parts at constant speed.
2. Create a unique tracking event
Evaluate: entry sensor, camera trigger, encoder position, lane, carrier, pocket, or machine-cycle identifier.
Why it matters: the result must be attached to one unambiguous physical entity.
Measure or calculate: log the identifier at trigger, result receipt, reject command, and verification. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: carrier-based tracking is robust but may require machine modifications. Common failure: using a single pass/fail bit that can be overwritten by the next part.
3. Calculate the decision window
Evaluate: camera-to-actuator distance, speed range, result-latency tail, actuator delay, reject duration, and safety margin.
Why it matters: a correct late result is operationally wrong.
Measure or calculate: derive the earliest and latest command positions and compare with measured trigger-to-result percentiles. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: greater distance gives processing margin but increases queue length and floor space. Common failure: using average algorithm time in the mechanical design.
4. Choose position and queue logic
Evaluate: encoder counts, shift register, FIFO records, pitch positions, conveyor slip, and restart rules.
Why it matters: part spacing and speed variation determine whether time or position tracking is valid.
Measure or calculate: mark test parts and compare predicted versus measured arrival over speed and load. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: encoder tracking adds hardware and diagnostics but reduces speed sensitivity. Common failure: retaining queued results after the conveyor or product stream has been manually cleared.
5. Engineer the reject mechanism
Evaluate: air blast, pusher, flap, diverter, robot, vacuum, product mass, friction, spacing, pressure, and recovery.
Why it matters: the actuator needs a verified operating envelope, not only a command pulse.
Measure or calculate: measure successful removal across minimum and maximum product states and utilities. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: longer actuation improves removal but may disturb adjacent good parts. Common failure: setting pulse duration on one empty container.
6. Verify disposition and fault response
Evaluate: reject sensor, downstream presence, bin full, pressure, actuator feedback, jam, missed verification, and safe machine state.
Why it matters: closed-loop evidence detects physical reject failures.
Measure or calculate: force each fault and confirm alarm, containment, queue handling, and recovery. Keep the acquisition settings, sample identity, line state, and calculation method in the test record so alternatives remain comparable.
Trade-off: strict verification adds sensors and possible nuisance stops. Common failure: counting a solenoid output as a confirmed reject.
Worked example
Hypothetical conveyor: The camera is 1.50 m upstream of an air reject. Conveyor speed ranges from 0.40 to 1.20 m/s. Vision decision latency is 35 ms at the 99.9th percentile, valve plus air-flight delay is 25 ms, and required command margin is 15 ms.
Travel time at maximum speed = 1.50 / 1.20 = 1.25 s
Required time before reject = 35 + 25 + 15 = 75 ms
Nominal available margin = 1.25 s - 0.075 s = 1.175 s
Encoder counts at 2,000 counts/m = 1.50 × 2,000 = 3,000 counts
The distance is ample for computation, but reject timing must be offset by the measured actuator delay and validated for slip. A queue record should hold cycle ID, trigger count, decision, validity, and expected reject count. A downstream sensor must confirm the defective part did not continue.
Practical decision aid
| Failure | Detection | Defined response |
|---|---|---|
| Vision result late | decision deadline timer | reject or stop according to risk |
| Encoder stops changing | motion plausibility | freeze/clear tracking safely |
| Reject air pressure low | pressure switch or transmitter | prevent unverified production |
| Reject bin full | level or count logic | stop or controlled changeover |
| No reject confirmation | chute/downstream sensor | contain product and alarm |
| Queue/part count mismatch | entry–exit reconciliation | enter recovery procedure |
Use the table as a screening aid, then confirm the decision with real images, timing records, and failure testing. A technically attractive component is not a valid solution until the complete inspection cell meets its defined acceptance criteria.
Common mistakes and how to prevent them
Using a fixed time delay on variable speed. the actuator hits the wrong part. Prevent it by tracking position with a qualified encoder or carrier.
Sending only a pass/fail bit. results are overwritten or misassociated. Prevent it by using identifiers and buffered records.
Sizing from average latency. rare slow results miss the window. Prevent it by using a defined tail and timeout.
Ignoring adjacent products. a pusher or air blast rejects good neighbours. Prevent it by testing minimum spacing and every product mass.
Keeping queue state after manual clearing. old results act on new parts. Prevent it by defining restart and reconciliation rules.
No reject verification. mechanical failures become customer escapes. Prevent it by confirming physical disposition.
Validate under production conditions
Use marked good and defective challenge parts over minimum and maximum speed, spacing, mass, friction, air pressure, conveyor acceleration, and line accumulation. Force late results, invalid images, duplicated triggers, missing triggers, encoder loss, power interruption, PLC restart, actuator failure, blocked chute, full bin, and manual product removal. Reconcile trigger, decision, command, confirmed reject, and downstream counts by cycle ID. Acceptance must include zero wrong-part rejects and a defined fail-safe response for every unconfirmed disposition.
Build the validation set from representative acceptable parts, confirmed defects, boundary cases, and nuisance variation. Repeat complete part presentations; repeatedly processing one stored image measures software determinism, not inspection repeatability. Include start-up, warm-up, maximum line speed, changeover, maintenance, environmental extremes, and recoverable communication faults where relevant.
Define acceptance criteria before looking at the final results. Report raw counts and denominators for false accepts, false rejects, invalid acquisitions, missed triggers, timing overruns, and any manually reviewed category. Preserve enough image and recipe context to reproduce failures. After release, trend leading indicators and conduct periodic labelled audits so deterioration is detected before it becomes a customer escape.
Key takeaways
Track a physical part, not a floating pass/fail bit.
Base rejection on measured decision and actuator timing tails.
Use position tracking when speed varies, while checking slip.
Verify the part actually reached the intended destination.
Test restart, queue mismatch, and utility faults explicitly.
Follow this Hashnode blog for more practical industrial machine-vision engineering, and connect with Kivanc Ekici on LinkedIn. For related machine-vision and automation information, visit ITAGE.
Frequently asked questions
Should a reject station use time or encoder distance?
Encoder position is generally more robust when conveyor speed varies, but carrier motion, slip, encoder integrity, and mechanics must still be validated.
How far should the reject be from the camera?
Far enough for worst-case image acquisition, processing, communication, actuator delay, and margin at maximum speed, without making tracking unnecessarily complex.
Is actuator feedback enough to confirm rejection?
It confirms actuator motion or command, not necessarily product disposition. A product-level downstream or chute check provides stronger evidence.
What should happen to an invalid vision result?
The risk assessment should define a fail-safe action such as reject, divert, contain, or stop; it should never silently become pass.
How are restart conditions handled?
Define whether tracked parts are cleared, physically removed, reconciled, or retained with persistent identity before automatic operation resumes.