Post-placement vision inspection after conveyor picking

Conveyor picking and crack inspection answer different questions: where should the robot pick, and is the placed part acceptable? Combining them requires more than adding another image tool. You need separate acquisition conditions, a reliable link between the picked part and its inspection, and a defined response when either stage fails.

For cell designers and controls engineers, the practical starting point is to treat placement inspection as a separate job. Then decide whether the existing vision runtime can execute that job without disrupting conveyor tracking. The architecture below explains the checks, timing calculations and result handling needed before choosing software or hardware.

Separate picking from acceptance inspection

The picking image establishes a target pose while the part moves through the conveyor field of view. Its result may include position, orientation, capture time and an encoder reference. The placement image examines the part after transfer, usually under different viewing and lighting conditions.

Keep these outputs separate. A valid pick target does not mean that the part passed crack inspection. Likewise, a failed inspection should not silently modify the conveyor target queue.

Define the inspection requirement before configuring image acquisition:

• Identify the surfaces and crack types that must be visible.
• Specify the smallest relevant defect and the acceptable false-reject behavior.
• Define the placement position and orientation range.
• Decide whether the station must detect missing parts, doubles or incorrect orientation before evaluating cracks.
• State what happens to acceptable, rejected and unclassified parts.

The existing crack-detection decision workflow explains how image findings become inspection decisions. Here, the additional problem is connecting that decision to the correct transferred part.

Treat lighting and fixture design as part of the inspection system. A sharply focused image cannot reveal a crack hidden behind a gripper or beneath the part.

Decide whether one runtime can support both jobs

A shared runtime is reasonable only when its documented capabilities cover both acquisition and scheduling requirements. The ability to connect another camera is not enough. Check whether it supports independently triggered jobs, separate calibration, result identification and predictable execution under load.

Use documentation supplied by the manufacturer or its authorized distributors. Confirm software licensing and supported camera interfaces before committing to an architecture.

A second runtime does not necessarily require another general-purpose computer. Depending on the application, inspection may run on a smart camera or a separate supported vision controller. Conversely, multiple cameras on one host do not prove that the software supports independent applications.

Ask these questions during the software review:

1. Can the placement job acquire without changing the picking camera's settings?
2. Can each result carry a request identifier or an equivalent documented association?
3. What happens when both jobs request processing simultaneously?
4. Can a slow inspection delay tracking updates or target delivery?
5. How are unavailable cameras, failed acquisitions and job exceptions reported?
6. Which software features require additional licenses?

The multi-camera acquisition architecture explainer covers camera ownership and session structure. Keep that acquisition design separate from the application-level decision about which part each result belongs to.

Carry part identity across the transfer

Create a logical part identifier when a conveyor target is committed to a pick. The identifier represents a tracked transaction, not necessarily a physically marked serial number. Carry it through robot handling, placement and inspection.

Do not associate results solely by arrival order. Processing delays can change completion order, while a missed pick can shift every subsequent association.

A practical transaction record contains:

• Part identifier and conveyor target reference.
• Pick request and pick-completion status.
• Destination station and placement sequence.
• Inspection request identifier and recipe revision.
• Capture acknowledgement and image reference.
• Inspection outcome, completion time and fault reason.

Keep the transaction open until the part reaches a defined disposition. A successful placement acknowledgement should move the record into a waiting-for-inspection state, not directly into an accepted state.

For a station holding only one part, permit only one active inspection transaction unless the software explicitly supports more. If the camera cannot return a request identifier, use a documented handshake that prevents another request until the current transaction finishes or is cancelled.

After a restart, do not match new requests to old results using a reset counter alone. Add a run identifier or use another documented method that distinguishes transactions across restarts. Discard late responses that cannot be matched to an active request.

The same capture-time discipline matters upstream. See the guide to stale conveyor scene data when validating the transition from conveyor target to picked part.

Capture after release, clearance and settling

Trigger the placement image from a verified station condition, not simply from the start of a robot move. The required sequence usually includes placement completion, gripper release, camera-view clearance and sufficient settling.

Use the following operational sequence as a starting point:

1. Reserve the inspection station for the selected part identifier.
2. Complete placement and confirm the expected part-present condition.
3. Release the part and move the gripper clear of the inspection view.
4. Wait for the validated settling condition or settling interval.
5. Issue the inspection request with its identifier and expected recipe.
6. Confirm that an image was acquired, then wait for the processing result.

Settling time depends on the product, fixture and motion profile. Determine it from repeated images taken at different delays after placement. Compare feature position and inspection stability, rather than choosing a delay only because one image looks sharp.

Camera readiness also matters. A trigger can be rejected or missed if the device is not ready for another acquisition. The guide to external camera trigger timing explains the distinction between trigger frequency and sustainable acquisition.

Continuous capture can also work, but the selected frame must demonstrably belong to the settled part. A recent preview frame is not sufficient evidence. Retain its frame identifier and capture timestamp with the inspection transaction.

Calculate latency and processing demand separately

The first timing question is whether the inspection finishes before the station needs a decision. The second is whether the processing system can sustain the combined workload. These are different calculations.

For an illustrative sequential schedule, estimate the decision latency as follows:

These terms must describe non-overlapping intervals. If the camera or software overlaps exposure, transfer and processing, use measured timestamps to avoid counting the same interval twice.

Assume a station receives 120 parts per minute:

For a worked example, assign these application timing assumptions:

The estimated decision time is:

Here, the assumed allowance is 60 ms and the station's decision deadline is 300 ms after placement completion. The example fits that deadline, but it is not a guaranteed worst-case bound. Validate every interval under the expected maximum load.

Now examine a simplified shared processing resource. Suppose picking consumes 35 ms per part, inspection consumes 65 ms, and reserved processing overhead is 20 ms:

This calculation assumes serialized work on the same resource and excludes time spent waiting for acquisition. It does not predict utilization for arbitrary multithreaded or accelerator-based software. Low average demand also does not prevent a long queue, blocking call or unusually difficult image from missing a deadline.

Measure tail latency during simultaneous picking and inspection, including image logging and communications. For broader scheduling considerations, use the guide to overlapping vision processing and robot motion.

Make outcomes and timeouts explicit

Use distinct outcomes for accepted, rejected and unknown inspection status. A timeout, camera fault or invalid image belongs in the unknown category unless a validated process rule specifies otherwise. It should never become an implicit pass.

The controller should accept a result only when all required conditions match:

• The request identifier belongs to the active station transaction.
• The expected inspection job and recipe revision were used.
• Acquisition succeeded and image-quality checks passed.
• The result arrived before the applicable deadline.
• The part has not already been removed or assigned another disposition.

A result acknowledgement closes the communications transaction; it does not by itself prove that the physical part reached its destination. Keep removal or downstream-transfer confirmation separate.

On timeout, hold the part or route it to a defined unclassified disposition according to the validated process design. Record the reason, notify the controlling sequence and prevent a late result from changing a completed disposition.

Retry only under controlled conditions. The same part must remain at the station, its pose must still be valid, and the retry must receive a new request identifier. Do not repeatedly retry until a rejected part eventually passes. Any repeat-inspection policy needs validation against the actual defect criteria.

Store enough evidence to diagnose disagreements: part identifier, request and result times, recipe revision, outcome and relevant images. Image retention policies should consider storage capacity and any applicable data requirements.

Choose hardware around the inspection interface

Start with the required image and the supported software interfaces, rather than choosing hardware by processing specifications alone. Compare acquisition ownership, trigger behavior, available inspection tools and fault reporting.

For host-based acquisition, browse area scan cameras through the camera finder. The LS-CMR-0395 is a catalog example with GigE, monochrome imaging and a global shutter. Its presence here does not establish sufficient crack visibility or software compatibility; those require application-specific checks.

For local processing, consider smart cameras when their documented tools cover the required inspection. The MV-SC3013XM-12M-ATN-H is a monochrome, global-shutter vision sensor. Confirm inspection-tool availability and communications behavior before treating it as a replacement for a host-based application.

For a supported host architecture, review vision controllers. The MV-VC2101-128G40-NN is a vision-controller candidate whose catalog description identifies a basic version without I/O or lighting functions. Plan any required external interfaces explicitly, and confirm runtime compatibility and licensing separately.

None of these examples establishes a complete inspection solution by itself. Camera selection still depends on defect size, field of view, contrast and validated processing performance.

Check integration before ordering and commissioning

Use a written acceptance checklist so that software, controls and inspection requirements agree:

• Defect evidence: representative acceptable and defective parts produce distinguishable images across the allowed placement range.
• Runtime support: documented features cover independent jobs, camera access and the intended inspection tools.
• Licensing: acquisition and inspection features are covered by the required legitimate licenses.
• Transaction identity: missed picks, retries and late responses cannot shift results onto another part.
• Capture conditions: part presence, gripper clearance and settling are verified before image selection.
• Timing: combined-load measurements meet the decision deadline with a justified allowance.
• Fault response: camera loss, failed acquisition and processing exceptions produce defined unclassified outcomes.
• Recovery: restart behavior reconciles the physical station with software records before automatic operation resumes.
• Traceability: saved results can be linked to their images, recipes and final dispositions.

Exercise abnormal sequences deliberately during controlled commissioning. Include an empty placement, a delayed result, a disconnected camera and a restart while a part remains at the station. Follow the machine's approved commissioning and safeguarding procedures throughout.

Recognize when another image is not enough

Post-placement inspection works only when the placed pose exposes the relevant defect with repeatable contrast. If cracks can occur on hidden faces, consider additional views, controlled reorientation or a different inspection method. Another software job cannot compensate for an invisible defect.

A single station may also be unsuitable when settling occupies most of the available cycle. Parallel fixtures or a separate inspection position can decouple robot transfer from inspection latency, but they require additional occupancy tracking and transaction handling.

Start with representative parts, a clear defect definition and a timing diagram covering placement through disposition. Use the camera configuration starting point to develop the imaging setup, or contact the applications team with your station sequence, sample images and decision deadline.