Vision format selection timing: fix PLC trigger races

A picking sequence that succeeds with a simulated input but fails from a PLC usually needs a signal-sequence investigation before an imaging adjustment. Seeing the trigger change proves only that an input changed somewhere; it does not prove that the receiving task sampled the intended selection and work-area state together. This troubleshooting procedure helps you separate selection-data races, conflicting simulation sources and readiness faults, then verify the correction with a receiver-side trace.

Start with the difference between simulation and production

Treat a successful simulated request as evidence that part of the processing chain can work, not proof that the PLC handshake is correct. Simulation may change timing, retain a previous selection or write through a different interface.

Capture the failing transaction before changing delays. Record the requested format, grouped-input value, intended work area, readiness state, trigger and acceptance or rejection indication. Use the receiving application's diagnostics wherever available.

If failures occur specifically after restarting the application, use the restart-handshake troubleshooting procedure alongside these checks. A restart fault and a selection race can look similar but require different evidence.

Establish one owner for each process signal

Before testing, stop automatic production through the normal controls and follow the machine's documented commissioning procedure. Keep guarding and safety functions active throughout diagnosis.

Create an ownership list for the selection word, request trigger, work-area commands, acceptance response and completion response. Identify the intended writer and every possible alternate writer, including application simulation, commissioning tools and retained test logic.

A PLC can show its output changing while an application continues using a simulated value. Another arrangement may combine multiple request sources, creating an edge earlier than the PLC sequence expects. Neither behavior can be inferred from the PLC output view alone.

Check the ordinary process signals at both ends:

• Is the live communication mapping enabled and connected to the intended destination?
• Does a simulation indicator remain active in the application?
• Can a background task or operator command also issue requests?
• Does restarting restore a test setting or retained command?
• Is the input viewer displaying the effective value or only the incoming transport value?

Use documented controls to remove conflicting simulation sources. If ownership is unclear, resolve that uncertainty before adjusting timing.

Verify the grouped selection at the receiving task

A grouped input represents a numeric selection assembled from multiple bits. Confirm its width, bit order, addressing and configured selection mapping against the application documentation.

Do not stop at checking individual bits. Verify the decoded integer that the receiving task actually uses. A correct PLC register does not establish that the destination uses the same representation.

For example, changing from binary 0011 to 0100 changes several bits. If separate writes or mapping stages expose intermediate combinations, the receiver could briefly observe another value. A grouped write reduces this risk only when the complete communication and application path preserves the update coherently.

Perform a static test before a timed test:

1. Set a valid selection without issuing a request.
2. Confirm the decoded selection at the receiver.
3. Confirm that this selection belongs to the intended project and work area.
4. Repeat with another configured selection.
5. Return to the required selection and check its validity indication, if provided.

Do not assume a particular numeric value means disabled, default or invalid. Those meanings belong to the configured application.

If selection is correct but the destination rejects the target, investigate target-selection mapping and rejected requests. If the receiving work area cannot initialize, follow the work-area initialization checks rather than extending the trigger delay.

Measure the selection-to-trigger timing budget

The relevant interval is between selection becoming valid at the receiver and the request being sampled there. The interval between PLC assignments is only part of that path.

Selection and trigger can pass through different communication updates, input images and application tasks. A PLC instruction written first can therefore become effective second.

Use a common-clock trace where possible. Otherwise, correlate events through a shared observation point before calculating timing differences.

Here, D is the commanded delay between writing the complete selection and issuing the trigger. Lselection,max is the bounded selection-path latency, while Ltrigger,min is the earliest trigger-path latency. Tsetup is the receiver's documented setup requirement, and M is an engineering margin.

Worked timing example

Consider an illustrative commissioning trace with these assumed bounds:

• Selection-path latency: no more than 8 ms.
• Trigger-path latency: at least 1 ms.
• Required receiver setup time: 2 ms.
• Additional timing margin: 3 ms.

The required commanded separation is:

With a commanded separation of 2 ms, the trigger could arrive at 3 ms while the selection arrives at 8 ms. The receiver could therefore act on the previous selection.

A trial separation of 15 ms would put the earliest trigger arrival at 16 ms. Against the latest selection arrival at 8 ms, that leaves 8 ms of setup interval, exceeding the assumed requirement plus margin of 5 ms.

These are example values, not hardware specifications or a universal delay recommendation. An observed maximum from a short trace is not automatically a guaranteed bound. Prefer a documented selection acknowledgment when available; use a fixed delay only when the complete timing path can be bounded adequately.

Separate selection acknowledgment from work-area readiness

A selection echo may mean only that a value was received. It does not necessarily mean that the corresponding recipe is loaded, the work area is available or another request can be accepted.

List the documented meaning of each response before writing the sequence. Distinguish selection received, selection active, ready for request, request accepted and operation complete. Some interfaces combine states; others expose them separately.

A useful conceptual sequence is:

1. Prepare: Confirm communication health and the documented initial request state.
2. Select: Write the complete selection through its assigned owner.
3. Validate: Wait for the documented selection-active response, or satisfy a justified timing bound.
4. Check readiness: Confirm that the intended work area and processing sequence can accept a request.
5. Request: Issue the documented request transition or level.
6. Confirm acceptance: Wait for the matching response, with a timeout and defined fault handling.
7. Complete and rearm: Follow the documented clearing sequence before allowing another transaction.

This is a diagnostic model, not a replacement for the application's specified handshake. Some interfaces require a pulse; others require a held request. Preserve the documented behavior.

Keep the selected value stable for the required interval. Unless the interface explicitly permits another behavior, do not replace transaction data while its request remains unresolved.

For broader state-transition faults, consult project start and stop handshake troubleshooting. Keep this investigation focused on the selection and readiness conditions immediately surrounding request acceptance.

Verify the correction with a transaction trace

A correction is not established by one successful pick. Test the conditions that previously changed timing or retained state.

Record these events for each transaction:

• Selection command and effective received value.
• Selection-active response, where available.
• Intended work-area readiness.
• Request command and effective received transition.
• Acceptance or rejection response.
• Completion and return to the documented idle state.

Include a transaction identifier if the interface supports one. Otherwise, use a local trace index without pretending it is part of the application protocol.

As an initial screening test, run 100 controlled request cycles covering repeated selections and selection changes. Require a matching acceptance or explicit rejection for every request, with no unexplained edges. This is a practical starting point, not a reliability qualification.

Also test a normal application restart, a documented recipe change and recovery from an ordinary process timeout. Do not induce hazardous machine conditions for diagnosis.

When latency varies with processing load, review request timing across processing and motion. Increasing concurrency should come after correct transaction ownership, not before it.

For production diagnostics, map meaningful fault states rather than a single generic failure bit. The PLC status and alarm mapping guide explains how to retain useful distinctions for operators and maintenance.

Check hardware suitability without treating it as the fix

A selection race is usually a sequencing or integration problem. A faster controller or a different camera does not automatically correct conflicting writers, incomplete grouped updates or missing acknowledgments.

For centralized processing, review the vision controllers category. The MV-VC3501H-128G60 is a catalog option for a controller-based architecture. Confirm the required software, licensing, communication interface and process I/O separately before selecting hardware.

For device-side inspection, compare the smart cameras category and the camera finder. The MV-SC3013XM-12M-ATN-H is a catalog option to evaluate within that architecture. Its listing alone does not establish support for a particular picking application's selection protocol.

Before ordering, ask for confirmation of selection representation, acknowledgment semantics, supported communication options and startup behavior. Provide the intended signal sequence rather than asking only whether a device can receive a trigger.

Prevent recurrence with a release checklist

Do not solve every failure by making the trigger longer. Pulse duration affects whether a transition is detected; it does not necessarily make selection data valid before that transition.

Likewise, a longer delay is the wrong primary answer when the selection mapping is incorrect, the work area never becomes ready or simulation still controls an input. Fix the state or ownership problem first.

Use this checklist before releasing the sequence:

• Ownership: Every process command has one intended writer, with test sources visibly controlled.
• Representation: The receiver decodes the configured selection correctly, including transitions between selections.
• Timing: Selection validity precedes request sampling by the documented or justified interval.
• Readiness: Acceptance depends on the intended work area, not an unrelated ready indication.
• Persistence: Transaction data remains stable until the interface permits it to change.
• Recovery: Timeouts lead to a defined process state without silently replaying stale requests.
• Startup: Simulation settings and retained commands cannot unexpectedly reappear during normal production.
• Evidence: The release record includes a successful trace and the tested operating conditions.

If the trace still shows unexplained ordering, use application support with the signal map, effective input trace, configured selection mapping and software revision. That evidence supports a targeted diagnosis before hardware changes or further timing adjustments.