A camera can classify a conveyor item once while separate control logic sends accepted items toward a robot and rejected items toward a pusher. The difficult part is maintaining each item's identity between inspection and action, especially when processing finishes late or a robot misses a pick.
This arrangement suits cells where both destinations use the same inspection decision. It does not prove that a later operation succeeded. You will need to distinguish shared inspection results from genuine post-process verification, then check whether your acquisition software, tracking system and output hardware support the proposed architecture.
Decide whether you need another decision or another observation
Single camera inspection routing uses one observation to make a quality decision, then distributes that decision to different destinations. The robot receives eligible targets. The reject mechanism receives items assigned to rejection. Neither destination needs to acquire the original image independently.
Post-process verification answers a different question: what happened after an operation? An upstream image cannot show whether a robot removed the item, whether assembly succeeded, or whether a pusher actually cleared the belt.
| Requirement | Can the original inspection serve it? | Additional requirement |
|---|---|---|
| Classify an item and choose its destination | Yes, if the inspection provides the required information | Identity tracking and supported routing logic |
| Send accepted items to a robot and rejects to a pusher | Yes, with suitable controls | Separate destination queues and position-based scheduling |
| Confirm that a robot removed an item | No | A new observation or suitable presence confirmation |
| Inspect a feature created during processing | No | A new image showing that feature |
| Confirm that rejection succeeded | No | Downstream observation appropriate to the failure being detected |
Sometimes the same physical camera can make a second observation after an indexed move or return cycle. That is still another acquisition, with different visibility and timing requirements. A downstream camera is often more practical on a continuously moving conveyor.
Give acquisition one owner and distribute results
Do not assume that a robot application and a pusher controller can both open the same camera. Discovery, parameter access and image streaming are different capabilities. Even when multiple connections are possible, their ownership and configuration rules need checking.
A clearer architecture gives acquisition to one supported application or device. That owner triggers the camera, receives the image, runs inspection and publishes a structured result. The robot interface and reject scheduler consume those results rather than competing for image acquisition.
The result might contain an item identifier, classification, measured pose and capture encoder count. Its communication method depends on the documented interfaces available in your equipment.
For host-based inspection, compare area scan cameras. For on-device processing, consider smart cameras and vision sensors, but check the actual inspection tools, result fields and communication capabilities before selecting a model.
The distinction matters more than the camera connection count: one image source can support several result consumers without granting each consumer camera control.
Build a record that follows the physical item
A pass/fail bit alone is insufficient when several items occupy the conveyor. Each result needs an identity that remains attached to the same physical object until its final disposition.
A useful item record contains:
- Item ID: unique within the active tracking session.
- Capture position: the encoder count associated with exposure.
- Capture time: useful for diagnostics and detecting stale records.
- Classification: accept, reject or unknown.
- Location and pose: sufficient for the destination that needs them.
- Destination: robot, reject station or a defined exception path.
- State: awaiting result, queued, requested, confirmed or expired.
- Recipe and session identity: prevents old results entering a new production run.
Associate the encoder position with image exposure, not with inspection completion. Otherwise, variable processing latency becomes a variable position error. Check the documented relationship between the trigger, exposure event, encoder latch and any timestamps.
Before a result exists, the control system should already know that an item requires a decision. A result deadline can then identify missing inspections. Without that expectation, a missed trigger may leave no record to reject or investigate.
Late or duplicated messages must not create another physical action. Match updates by item ID, reject incompatible session identifiers, and make repeated commands safe to process without repeating the action.
For the problems caused by old observations entering current tracking, see conveyor scene timing and stale pick data.
Calculate the position budget before choosing hardware
For a conveyor moving in one direction without significant slip, encoder displacement estimates the distance traveled since capture. The following relationships are useful starting points:
The time and actuator-lead calculations assume approximately constant speed over the relevant interval. Encoder tracking handles changing conveyor position, but it does not remove a pusher's mechanical delay.
Worked routing example
Assume these application values, independent of any particular product:
- Conveyor speed: 500 mm/s.
- Encoder scaling: 10 counts/mm.
- Robot pickup window: 450–650 mm after the capture location.
- Reject contact position: 1,000 mm after capture.
- Inspection latency: 80 ms.
- Effective delay from output command to reject contact: 40 ms.
The item moves during inspection:
The item enters the robot window after:
That interval is not entirely available for robot motion. Communication, target acceptance, motion planning and the robot's approach requirements must fit inside the actual picking schedule. The physical window lasts:
For the pusher, compensate for its effective delay:
Schedule the command relative to the item's capture count. Do not start an arbitrary travel timer when inspection finishes, because result latency can vary.
For a coordinated multi-destination system, the encoder-sharing guide explains related position-reference concerns. The picking request timing guide addresses the robot-side scheduling budget.
Keep robot targets and reject actions in separate queues
Maintain one authoritative item record, then create destination-specific queue entries that reference it. The robot queue needs pose, eligibility and pickup-window information. The reject queue needs the actuation position and the item's current disposition.
The queues should not independently decide ownership. A central state transition commits the destination so that routine updates cannot assign the same item to both actions.
Robot acceptance of a target is not proof that the item left the conveyor. Define the distinction between target received, pick attempted and removal confirmed. If failed picks must reach the reject station, retain their tracking information until the supported confirmation event occurs.
A failed-pick transfer requires enough distance for failure reporting and reject scheduling. If the item has already passed the pusher's command position, a software reassignment cannot recover that opportunity. The cell needs a documented alternative, such as stopping production or using another containment route.
Define exception handling for:
- Inspection timeout or an unknown classification.
- A robot target that expires before pickup.
- Lost communications or a restarted application.
- Encoder discontinuity, belt reversal or tracking-reference loss.
- A reject output that is unavailable or not acknowledged.
Unknown quality should not silently become acceptance. Depending on the process, the appropriate response may be rejection, segregation or a controlled stop.
Check actuator spacing and the uncertainty budget
A pusher must complete its action and recover before the next relevant item arrives. Average production rate is not enough; adjacent rejects are often the limiting case.
At a pitch of 100 mm and a conveyor speed of 500 mm/s:
If an illustrative actuator needs a 60 ms active interval followed by 90 ms recovery, its total cycle occupies 150 ms. That leaves 50 ms before the next item at that pitch. Validate the complete mechanism, including load, pressure variation, output timing and item interaction.
Timing uncertainty also becomes position uncertainty:
Suppose image-location uncertainty is ±1 mm, actuator-delay uncertainty contributes ±2.5 mm, and belt slip contributes ±2 mm. A conservative worst-case sum is ±5.5 mm. Do not substitute a statistical combination unless the error assumptions justify it.
Encoder resolution is only one contributor. A scale of 10 counts/mm gives 0.1 mm per count, but that does not establish overall placement accuracy. Compare the full uncertainty budget with the item's usable contact area and neighboring-item clearance.
Choose camera and controller roles separately
Choose the imaging hardware from the inspection requirement first: feature visibility, contrast, motion behavior and required detail. Then choose the control architecture from tracking, communication and output requirements.
The LS-CMR-0395 is a monochrome, global-shutter GigE area scan camera with a C-mount. Consider it as an acquisition candidate for a host-based architecture, subject to the inspection's optical and performance requirements.
- Sensor format
- 1/2.7"
- Interface
- GigE
- Resolution
- Up to 3 MP
- Shutter
- Global
The MV-SC3013XM-12M-ATN-H is a monochrome, global-shutter vision sensor with a GigE interface. For an on-device architecture, verify the required inspection tools and result interfaces rather than assuming they follow from the interface specification.
- Interface
- GigE
- Resolution
- Up to 3 MP
- Sensor format
- 1/1.45"
- Shutter
- Global
Use the camera finder to compare imaging options. Neither a camera's interface nor its shutter type establishes support for shared access, item queues or robot routing.
A dedicated control architecture may also involve vision controllers. The MV-SVC2506-16G60-128G is a controller candidate to evaluate against the required software and integration interfaces, not evidence that this routing sequence is supported automatically.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 16 GB
Confirm licensing, camera compatibility, encoder acquisition, result messaging and output scheduling in the applicable documentation. For acquisition timing questions, consult hardware triggering with external pulses.
Know when the single-observation approach is wrong
Add another observation when the decision depends on something that changes after the first image. Examples include a newly inserted component, a disturbed label, an exposed underside or the result of a reject action.
Tracking can also become inadequate when items slide, rotate, collide or transfer between conveyors after inspection. An encoder measures conveyor motion, not necessarily each item's motion. A downstream locating image may therefore be needed even when no new quality feature requires inspection.
Another camera can improve visibility, but it does not automatically solve missing IDs or ambiguous ownership. Its results still need association with the correct item and a defined relationship to earlier decisions.
Conversely, adding a camera solely to give another consumer access to an unchanged classification may add unnecessary acquisition and synchronization work. A documented result-distribution interface can be the better answer.
When evaluating camera count, list every required observation and the event it proves. Separate those observations from the number of applications that need the resulting data.
Commission the routing sequence before production
Use a commissioning checklist that exercises identity and failure handling, not just successful inspection:
- Verify capture association. Confirm that each expected item receives the correct image and capture position.
- Alternate classifications. Run accept–reject–accept patterns and confirm both queues preserve item identity.
- Test consecutive rejects. Challenge the pusher at the minimum permitted item spacing.
- Delay a result. Confirm that a late message cannot schedule an action for the wrong item.
- Duplicate a result. Check that retries do not create another target or output pulse.
- Simulate a missed pick. Verify the documented transfer or containment policy before the reject deadline.
- Change speed within the approved range. Recheck actuator compensation and pickup-window availability.
- Exercise stop and restart. Invalidate stale records and re-establish the tracking reference through the supported sequence.
- Log each transition. Record item ID, capture count, destination, command position and confirmation state.
For restart coordination, use the conveyor vision startup synchronization guide. Keep commissioning tests within the machine's approved operating and safety procedures.
Before ordering, prepare a timing sketch, interface list and observation checklist. Start with the camera configurator, or send the proposed capture, pickup and reject arrangement through application support to review which hardware roles fit your requirements.
Questions
Can one camera supply inspection results to both a robot and a reject pusher?
One acquisition can supply the classification used by both destinations when supported control software distributes the results. The camera does not necessarily need connections from both controllers. Reliable operation depends on associating each decision with its physical item and scheduling the destination action before its deadline.
Does reusing an inspection result count as post-process verification?
Post-process verification requires evidence collected after the operation being checked. Reusing an earlier image only repeats the earlier decision. Depending on the requirement, confirmation might come from another image or a suitable presence sensor, but the observation must actually demonstrate the required outcome.
Can two applications connect directly to the same camera?
That depends on the documented camera and software architecture. Network discovery does not establish permission for simultaneous acquisition or parameter changes. Prefer a supported acquisition owner that publishes results, unless the documentation explicitly describes and supports the required multiple-client arrangement.
What should happen when the robot fails to pick an accepted item?
Choose the missed-pick policy before commissioning. Possible responses include tracked reassignment to a downstream reject station, segregation or a controlled stop. Reassignment only works if the system detects failure while sufficient travel remains, and if the original item's position is still known.
Is an encoder necessary for a downstream reject pusher?
A timer may be adequate for a validated constant-speed arrangement with sufficient positional tolerance. Encoder tracking is generally more suitable when speed changes or stops occur. Neither method corrects item slip automatically, and a delayed actuator still needs compensation and an uncertainty allowance.


