The UR5e waits after unloading but our clip misses the request

New occurrence captured with the specified fields. The application waits for destination receipt, but the PLC trace shows it clearing that receipt before the application samples it. Author has confirmed both records belong to the same request.

That is much more useful. Are both authors using receipt to mean the request was received, or is one treating it as the destination being physically available? I would settle that before changing the timing.

Both mean request received. Their disagreement is its lifetime: PLC clears on its timer, application expects it held until the next agreed state. We have put those interpretations together.

Have them define ownership and clearing conditions for the whole exchange, including delayed receipt and interruption. Extending the timer would leave the same disagreement hidden underneath.

And tell the operator what this wait means. The current message may have made them suspect a blocked destination when the missing thing was a receipt.

Interface revision agreed. The offline delayed-reader and repeated-receipt cases pass without losing the request or creating another transfer. The draft message now says waiting for request receipt.

Did the agreed checks reach the installed station yet?

Yes. Integrator and controls owner completed the return checks on the identified job and fixture. This lost-receipt wait is fixed. Operator used the revised message and escalation route during the interruption walkthrough.

Good result. Keep earlier untraceable stops separate rather than retrospectively calling every one the same lost receipt.