Vision picking request timing: overlap processing and motion

A robot can finish its current placement while the vision system prepares the following target. If the application instead waits until placement finishes before requesting another position, those activities run sequentially and may create avoidable idle time. This explainer is for engineers reviewing that handshake. You will learn where to issue the request, how to manage the returned target, and how to measure the improvement without weakening freshness checks or machine safety.

Move the request, not the next physical pick

The useful change is to request the following target after the current pick is confirmed, but before placement finishes. Vision processing, target selection and communication can then overlap the remaining robot motion.

This requires a documented asynchronous interface or an equivalent supported scheduling function. Moving a blocking request earlier in the robot program may simply move the waiting period. The current placement must remain able to continue while the request is pending.

Keep three events separate:

• Request: ask the vision application to prepare or allocate another target.
• Ready: receive a valid response identifying the target and its coordinate reference.
• Use: accept that target for the next motion sequence after the required checks.

Earlier requesting does not authorize earlier movement. Motion permission, collision checks, gripper confirmation and safety-rated functions retain their existing roles.

Define the handshake before changing its timing

First identify what the request actually does. Depending on the application, it might trigger image acquisition, select an existing detection, reserve a target, or combine these operations. Those meanings produce different latency and freshness requirements.

A request that selects an already processed target might return quickly. A request requiring a new exposure and full analysis may take much longer. Neither behavior should be assumed from a function name.

Record whether the interface permits one outstanding request or several. Also establish whether readiness means a new image was processed or an existing target was allocated.

For a first implementation, keep one request outstanding and one reserved target. This makes cancellation, timeout handling and event matching easier to verify. A deeper queue is useful only when the application can maintain target validity and ownership across every queued entry.

Startup is a separate concern. Establish the first valid target before entering the repeating sequence, using the principles in conveyor vision startup synchronization troubleshooting. A steady-state timing improvement does not establish a correct startup handshake.

Estimate the available cycle-time saving

Use a simple timing model before changing hardware. Define the overlap window from the earliest permitted request event to the latest point when the following target must be ready.

Let:

• F be the cycle work outside that overlap window, such as the following approach and pick.
• P be the available placement-and-return overlap window.
• V be request-to-ready latency, including acquisition when required.

For a simplified steady-state cycle:

This estimate assumes the request starts at the beginning of the overlap window. It also assumes unchanged motion times, no extra contention and no additional request overhead. These equations describe scheduling, not a guaranteed production rate.

Worked example

Suppose the measured overlap window is 720 ms, request-to-ready latency is 180 ms, and the remaining cycle work is 300 ms.

The target preparation finishes within the available motion window, so its latency disappears from the repeating critical path. It still consumes processing and communication resources.

Now suppose request latency rises to 900 ms while the overlap window remains 720 ms. Residual waiting becomes 900 ms - 720 ms = 180 ms. Requesting earlier still helps, but cannot conceal the entire delay.

Measure the window from the actual request event, not from the start of a robot movement. If the request is submitted late, part of the apparent overlap window has already been lost.

Reserve the following target explicitly

An early response creates a period when the robot owns a target but is not yet ready to pick it. That reservation needs a clear lifecycle.

A useful conceptual sequence is:

Available → Reserved → Pick accepted → Consumed

Timeout, rejection and cancellation paths must also exist. Their exact behavior belongs to the application's documented interface, rather than an improvised modification of an internal target list.

Associate each request with an identifier. Store the returned target identifier, coordinate frame, acquisition reference and validity information together. Do not keep coordinates in one shared variable while a separate callback silently replaces the associated status.

For a shared work area, reservation must prevent another consumer from receiving the same target. Completing placement of the current part must not accidentally release the reservation for the following part.

Decide what happens if:

• The current pick fails before the following request should be submitted.
• Placement fails after another target has already been reserved.
• The response arrives after its request timed out.
• A recipe change occurs while a request is pending.
• A restart leaves an old reservation in application memory.

A late response should not automatically become the next accepted result. Match it to the active request and operating context first.

For changeover-specific faults, use vision picking project changeover ownership diagnostics. Here, the concern is reservation duration within a running cycle, not changing which project owns acquisition or processing.

Check freshness at use time, not only at receipt

An early result can be correct when received and unsuitable when the robot finally uses it. Result age therefore needs an explicit reference event.

For image-derived coordinates, acquisition time is usually more meaningful than response arrival time. A fast response can still contain an old detection selected from a queue.

Only subtract timestamps that share a valid time reference. Otherwise, use documented clock synchronization, encoder references or application-side event correlation. Similar-looking timestamps from unrelated clocks do not establish result age.

For a stationary tray, check whether the scene remained unchanged after imaging. Part removal, tray indexing, vibration or another mechanism entering the work area can invalidate a reserved position.

For a moving conveyor, a position from an earlier image needs the application's supported tracking reference and validity limits. Request timing alone does not make a fixed coordinate follow a moving object. See conveyor vision scene timing and stale pick data for the separate problem of matching results to the physical scene.

Earlier requesting can also expose an acquisition constraint: the robot may obscure the following target during its current pick or departure. In that case, separate image acquisition from target allocation if the documented interface supports it. Otherwise, wait until the camera has a usable view.

Separate hardware selection from scheduling support

An early-request feature normally depends on the application, robot interface and runtime configuration. Camera resolution, processor capacity and network connections do not prove that a particular asynchronous handshake is supported.

Start with the vision controllers category when reviewing dedicated vision hardware, but obtain software compatibility confirmation before ordering. Record the required operating environment, acquisition interface, licensing and robot communication method.

The MV-SVC2506-16G60-128G is a vision-controller candidate with camera GigE ports. Treat it as a hardware option to evaluate, not proof of support for your application's request scheduling.

For image acquisition, the LS-MV-133GM-GE is a monochrome GigE camera with a global shutter. Scheduling compatibility still needs separate confirmation across the acquisition software and robot application.

Use the area scan cameras category and camera finder to evaluate image-acquisition requirements. The timing budget should distinguish exposure, readout, transfer and processing instead of treating them as one unexplained delay.

If a request initiates a hardware-triggered exposure, verify the trigger relationship independently using camera hardware trigger frame-rate checks. A request acknowledgment is not necessarily an exposure acknowledgment.

Measure the change with matched event logs

Use the same parts, recipe, motion program and acquisition settings for the baseline and changed sequence. Begin under the machine's approved commissioning procedure, then validate at production conditions.

1. Record the baseline. Log pick confirmation, request submission, acquisition reference, response readiness, placement completion and next-target use.
2. Match every response. Include request and target identifiers so delayed responses cannot be mistaken for current ones.
3. Enable the supported scheduling change. Change request timing without simultaneously changing exposure, processing settings or robot speed.
4. Measure distributions. Compare median and 95th-percentile cycle time, request latency and target age. Also report the observed maximum and timeout count.
5. Exercise recovery paths. Test no-target responses, failed picks, delayed processing, placement faults and controlled restarts.
6. Check completed output. Count successful placements and rejects, rather than relying only on an internal robot cycle timer.

For example, collect 500 consecutive cycles per condition as an initial comparison. This can reveal repeated timing patterns, but it does not establish long-term reliability or rare-fault performance.

A useful acceptance rule combines performance and correctness: waiting decreases, every accepted response matches its request, and target age remains inside the validated application limit. Faster average cycles are not a successful outcome if duplicate allocations or late-result acceptance appear.

Use the machine-vision software upgrade validation checklist when the change also involves a runtime update. Keep the timing experiment separate from unrelated software changes whenever practical.

Know when earlier requesting is the wrong answer

Earlier requesting helps when independent preparation work can overlap useful motion. It does little when the following target is already ready, when the request is nearly instantaneous, or when no valid target can exist until placement completes.

It can be counterproductive when a longer reservation prevents another robot from using a shared target. It can also increase rejection rates when parts move unpredictably during the added holding period.

A continuously updated guidance task is another exception. A single prefetched pose is not a substitute for ongoing feedback; see visual servoing loop design when the robot must repeatedly revise its motion from new images.

Before committing the change, check that:

• The interface documents asynchronous requesting or an equivalent supported feature.
• The request cannot block completion of the current placement.
• Reservation, cancellation and late-response behavior are defined.
• Target validity is checked immediately before use.
• Acquisition remains possible at the proposed request event.
• Safety functions and motion permissions remain unchanged.
• Measured improvement survives recovery tests and normal production variation.

Prepare a timing trace and compatibility checklist before selecting replacement hardware. Use the camera configuration step for acquisition requirements, or contact the applications team with your request-to-ready measurements, overlap window and software constraints.