A vision system that finds a bad part has done only half the job - something still has to physically remove that part before it reaches a customer. The reject mechanism is that something, and it is where inspection reliability is actually won or lost. This guide describes the common reject actuators, explains why the mechanism matters more than the camera for keeping bad product off the line, and walks through the tracking, confirmation, and fail-safe logic that make a reject fire on the right part and prove it did.
Reject Mechanism in one line: A reject mechanism is the actuator that physically removes a failed part after an inspection - typically an air-blast nozzle, a mechanical pusher, a diverter arm, or a drop gate. It is triggered by the inspection's fail signal but its reliability depends on more than firing: encoder-based part tracking so it acts on the correct product downstream, a reject-confirmation sensor to prove the part actually left, and fail-safe logic that stops the line if a reject cannot be verified. The mechanism, not the camera, is where reject reliability is decided.
The right reject actuator depends on the product's size, weight, speed, and how gently it must be handled. An air-blast nozzle fires a burst of compressed air to knock a light part off the conveyor and is fast, non-contact, and simple, which suits small or fragile items moving quickly - but it has limited force and can miss a heavier part or one that shifts. A mechanical pusher extends an arm or paddle to shove the part off the line and delivers far more force, handling larger and heavier products, at the cost of a moving part that must complete its stroke and retract in the available window.
For higher speeds or gentler handling, a diverter arm or air jet steers the part down a reject lane rather than knocking it off entirely, keeping product intact and letting the line run fast because the good parts are never touched. A drop gate takes yet another approach: a section of the conveyor floor opens so the failed part falls into a reject chute below, which is robust for bulk or awkward products but depends on precise timing so only the bad part drops. Each mechanism trades speed, force, footprint, and product handling differently, and choosing wrongly is a common cause of unreliable rejects.
Whatever the actuator, the theme is the same: the physical act of removal is harder to get right than the decision to remove. A camera can flag a defect in milliseconds, but a pusher that is slightly too slow, an air blast that is slightly too weak, or a diverter mistimed by a fraction of a second lets a bad part continue or ejects a good one. This is why experienced integrators treat the reject mechanism, not the vision, as the part of the system most in need of careful engineering and hardest to make robust.
The central problem is that inspection and rejection happen at different places on a moving line, so the reject must fire on the same part that was inspected - but by the time the part reaches the reject station, many other parts may have passed the camera. This is solved with encoder-based part tracking: an encoder measures conveyor travel so the controller knows exactly how far each inspected part has moved, and it fires the reject only when that specific failed part arrives at the actuator. Without accurate tracking, a mistimed reject ejects the wrong part and lets the defective one through, defeating the whole inspection.
Because timing is everything, the reject window is often tight, and small errors in encoder counts, conveyor slip, or actuator response add up. A robust design accounts for the actuator's own delay - the fraction of a second between the fire command and the part actually being removed - so the command is issued early enough that the removal completes while the part is in front of the mechanism. Getting this synchronization right across the full range of line speeds is a large share of the commissioning work on a reject system.
Firing is not proof of success, which is why a reject-confirmation sensor is essential. Placed after the actuator, it checks that the failed part actually left the line - the air blast really moved it, the pusher really cleared it, the diverter really steered it away. This closes the loop between intent and outcome: the system does not merely command a reject, it confirms one happened. Confirmation also catches the mechanical failures that quietly ruin an inspection line, such as a low-pressure air blast or a sticking pusher that no longer clears parts even though the fire command is still being sent.
The point of confirmation is what you do when it fails. Fail-safe reject logic dictates that if a reject was commanded but confirmation does not verify the part left, the system must not carry on as if nothing happened - because a bad part may now be loose on the good line. The safe response is to stop the line and alarm, forcing a human to find the escaped defective part rather than let it ship. This is the difference between a system that tries to reject and one that guarantees no known-bad part passes undetected, and it is the essence of designing rejection to fail safe.
All of this is orchestrated through the controller. The vision system delivers a pass or fail to the PLC, which tracks that verdict against the part using the encoder, fires the correct actuator at the correct moment, reads the confirmation sensor, and enforces the fail-safe stop if confirmation is missing. The camera senses, but the PLC is what turns the verdict into a tracked, confirmed physical action, tying together inspection result, part tracking, actuator, and confirmation into one closed loop. The reliability of the whole inspection ultimately lives in that controller logic.
Merobix is a cloud SCADA platform that reads live tags from field devices over Modbus, DNP3, OPC UA, and MQTT, and a reject station's counts and states - rejects commanded, rejects confirmed, and fail-safe stops - can be surfaced as tags alongside other process signals. Trending confirmed rejects against commanded rejects makes a weakening air blast or a sticking pusher visible before it lets bad parts through, and an unusual rate of fail-safe stops is an early alarm that the mechanism needs attention. Watching these across a line, or across several sites, turns reject reliability into a continuously monitored metric rather than something discovered only after a defective part reaches a customer.
Because the camera only decides whether a part is bad, while the reject mechanism has to physically remove it, and removal is far harder to make reliable. A vision system can flag a defect in milliseconds, but a slightly slow pusher, a slightly weak air blast, or a mistimed diverter can let the bad part continue or eject a good one. Escaping defective parts almost always trace back to the mechanism, its timing, or its confirmation rather than to the inspection, which is why integrators treat rejection as the reliability-critical part of the system.
It verifies that a commanded reject actually happened by checking, after the actuator, that the failed part really left the line. Firing the reject is not proof of success - an air blast can lose pressure, a pusher can stick - so without confirmation a mechanically failing reject would keep sending fire commands while bad parts continue undetected. The confirmation sensor closes the loop between intent and outcome, and it is what fail-safe logic relies on to stop the line when a reject cannot be verified.
It uses encoder-based part tracking. An encoder measures how far the conveyor has moved, so the controller knows the exact position of each inspected part as it travels from the camera to the reject station, and it fires the actuator only when that specific failed part arrives - accounting for the actuator's own response delay. This matters because many other parts may pass the camera before a given part reaches the reject point, and without accurate tracking the reject would eject the wrong part and let the defect through.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.