Conveyor target availability: diagnose cycle-time losses

A conveyor cell can lose throughput when a target-availability output becomes a prerequisite for every new cycle. The output may describe a queue state that changes during reservation and acknowledgement, rather than continuously indicating usable conveyor capacity.

For controls and vision integrators, the useful question is therefore not simply whether targets exist. It is whether the application waits for information that becomes available later than the scheduling decision requires. Diagnose that distinction with timestamped events, target identifiers and measured cycle intervals before changing the sequence.

Decide what the availability signal actually promises

Conveyor target availability is not necessarily the same as queue depth, an empty placement location or permission to begin motion. Its meaning depends on the documented work-area and queue interface.

A target can exist in the queue while being outside the tracking window, reserved by another consumer, rejected by a filter or already approaching its usable limit. Conversely, a mapped output can remain low briefly after the queue has established another eligible target.

Separate these states in your investigation:

• Detected: a candidate placement location has entered the system.
• Eligible: the location satisfies the documented work-area and selection rules.
• Reserved: a particular consumer owns the target.
• Completed: the application has finished the associated operation.
• Acknowledged: the queue has accepted the documented completion or disposition transaction.
• Published: the resulting availability state has reached the application or mapped output.

These are diagnostic labels, not assumed API names. Some runtimes combine states or implement a different lifecycle.

Read the interface documentation before interpreting a falling edge as conveyor starvation. The related scene-timing troubleshooting guide addresses stale scene data; this investigation starts with valid data and follows steady-state target ownership.

Capture the target lifecycle without changing it

Use existing trace facilities, documented status reads and passive signal capture wherever possible. A diagnostic operation that reserves or acknowledges a target can change the very behavior being measured.

Record at least these events for each cycle:

1. Candidate target creation, including its identifier and conveyor position.
2. Eligibility changes, if the runtime exposes them.
3. Target reservation request and successful reservation.
4. Placement completion and the target identifier used.
5. Acknowledgement request and confirmation, where separately observable.
6. Queue-state update and availability-output transitions.
7. Application wait entry, wait exit and next-cycle start.

Also log timeout results, rejected selections and queue depth when documented read-only access exists. A total queue count is useful context, but it does not prove that an unreserved target is eligible.

Use one monotonic clock when possible. For traces spanning multiple devices, establish clock alignment and uncertainty, or capture a common event on each recorder. Device timestamps cannot be directly subtracted merely because both are displayed in milliseconds.

For a suspected delay around 60 ms, a logging interval of 20 ms gives poor separation between adjacent stages. Aim for timestamp uncertainty below 5 ms for that investigation, and report the actual uncertainty with the results.

If acquisition timing is uncertain, follow the external-trigger timing guide to distinguish trigger arrival from image delivery. Neither event alone proves that a target has entered the placement queue.

Calculate the cycle-time penalty before assigning blame

Use completed placements over a steady-state interval, not a brief display of instantaneous rate. Separate motion and handling time from time spent waiting at the availability gate.

Consider a hypothetical cell that completes 100 placements per minute without an additional availability wait, but 90 with it:

• Reference cycle: 60000 / 100 = 600 ms.
• Gated cycle: 60000 / 90 = approximately 667 ms.
• Added interval: 667 - 600 = approximately 67 ms per placement.
• Cycle-time increase: 67 / 600 × 100 = approximately 11.2%, using rounded values.
• Throughput reduction: (100 - 90) / 100 × 100 = 10%.

That does not establish the cause. It establishes the amount of recurring delay the trace must explain.

An illustrative trace might look like this, with elapsed time referenced to the previous placement completion:

Here, the measured delay is distributed across several stages. Calling all 67 ms an output delay would hide the distinction between queue processing, signal publication and application scheduling. Timestamp order also does not prove causality; repeat the measurement and inspect the associated target identifiers.

Test likely causes in this order

Start with sequencing and ownership because these checks explain why abundant queued positions can coexist with a low availability output. Then investigate actual supply and acquisition faults.

Change one variable at a time. If a task-period adjustment reduces the delay, repeat the test at several loads before declaring the problem solved. A faster task can conceal a race without correcting transaction ownership.

Separate physical target windows from handshake latency

The time a location spends inside a conveyor window is a physical constraint. Queue-processing latency is a control-system constraint. Measure both, but do not treat them as interchangeable.

For constant conveyor speed, an initial residence-time estimate is:

This estimate assumes the target moves with the conveyor and uses the configured usable window, not the entire visible belt length.

A target near the exit has less time remaining. Suppose its remaining travel is 160 mm at 800 mm/s:

In this example, 120 ms represents an estimated time to complete the relevant tracked action, while 40 ms is an application-selected timing allowance. Only 40 ms remains for additional delay. A recurring 67 ms wait would exceed that illustrative budget.

This arithmetic is a screening calculation, not a motion-feasibility or safety proof. Acceleration, tool clearance, tracking limits, target geometry and controller scheduling still matter. Use the controller's supported feasibility checks and validate the actual trajectory.

Also verify coordinate definitions. A target count inside an image region does not establish that the same targets are inside the configured conveyor work area.

Correct the handshake without using queue operations as polling

The preferred repair is a documented sequencing change, not a faster loop around an intrusive queue call.

1. Identify the authoritative scheduling interface. Determine whether the runtime provides a supported wait-and-reserve transaction, a readiness state or another documented mechanism.
2. Confirm ownership behavior. Establish what success, timeout, cancellation and acknowledgement do to the target and queue.
3. Place the transaction at the correct decision point. Acquire the target when the application can use it within the permitted tracking window, without holding reservations unnecessarily.
4. Handle unsuccessful acquisition explicitly. Do not continue with an old target, treat a timeout as success or acknowledge a target the task never owned.
5. Complete the lifecycle once. Match every documented completion, release or cancellation action to its target identifier and owning task.
6. Retest the mapped output. It may remain useful for supervision even if the documented scheduling interface is the correct mechanism for starting work.

Do not assume that acquiring and immediately acknowledging a target merely asks whether one exists. Depending on the interface, those operations may consume, retire, release or otherwise change the target. Use a documented read-only query when available; otherwise use trace evidence or obtain the supported diagnostic procedure.

A shorter timeout does not inherently increase throughput. It can increase retries, CPU load and scheduling contention while leaving the original publication delay untouched.

Choose instrumentation before replacing hardware

Use vision controllers when the application needs dedicated vision processing and camera connectivity. A controller's hardware specification alone does not establish placement-queue semantics, robot-runtime compatibility or acknowledgement timing.

The MV-SVC2506-16G60-128G is a vision-controller candidate for the vision-processing side. Confirm software compatibility and accessible diagnostic facilities before selecting it.

For upstream target generation, compare area scan cameras through the camera finder. The LS-MV-133GM-GE is a camera candidate; validate the complete acquisition and target-generation path rather than assuming a camera change will repair queue timing.

A separate part-present signal can help distinguish physical arrivals from software target creation. Compare photoelectric sensors through the trigger-sensor finder, checking wiring, sensing geometry and input compatibility.

The MV-PE5502 is a sensing candidate where its documented output and sensing arrangement match the installation. A presence transition provides an arrival reference, not proof of an eligible placement target.

Ordinary part-present sensing is not a substitute for protective sensing. Keep the diagnostic acquisition path separate from safety functions and follow the documented electrical interface requirements.

Verify sustained performance and the exceptional cases

Compare the original and revised sequences at the same conveyor speed, target spacing, processing load and product mix. Measure completed placements, gate-wait duration, reservation failures, expired targets and incorrect or duplicate placements.

For example, an observation covering 1,000 placements averages recurring timing behavior more effectively than a few successful cycles. Extend the test when rare gaps or periodic background tasks affect performance. Average throughput alone can hide occasional long waits, so report the median and a high percentile of cycle intervals as well.

Exercise these cases deliberately:

• No target is available when the cycle requests one.
• A target approaches the exit while another operation is active.
• Multiple consumers compete for eligible locations.
• An acquisition attempt times out or is cancelled.
• Processing load rises without changing the conveyor conditions.
• The system stops and restarts with partially completed transactions.

Use the startup-synchronization troubleshooting guide for restart-specific faults. Keep those results separate from the steady-state measurements.

The usual answer—reduce handshake delay—is wrong when the real limitation is sparse placement locations, unreachable targets or genuine motion-time growth. In those cases, earlier publication of availability cannot create usable capacity. Preserve the correct waiting behavior and address the actual constraint.

Close the investigation with a recorded checklist

Before accepting the change or ordering replacement components, confirm:

• Signal meaning is documented. Record exactly which state the availability output represents.
• Target ownership is traceable. Every reservation and disposition has a matching identifier and owner.
• Timing uncertainty is known. Cross-device traces have a verified alignment method.
• The delay budget closes. Measured waits fit the remaining target window under the tested conditions.
• Queue probes are nonintrusive. Monitoring does not reserve, consume or acknowledge production targets.
• Exceptional paths are validated. Timeouts, cancellation and restart cannot reuse stale targets.
• Hardware selection follows evidence. Replace acquisition or sensing components only when their measured behavior contributes to the loss.

Retain the trace, software versions, configuration and acceptance results as a regression baseline. The software-change validation checklist provides a related framework for checking later updates.

If the trace identifies an acquisition or sensing requirement, start with the camera configuration step or trigger configuration step. For component selection, send the measured timing budget and interface requirements through applications support.