I've got attempt identities covered on this UR5e inspection interface. The unresolved bit is earlier: the PLC clears its request on a timer, while the app thinks it clears after acceptance. No wonder the traces tell different stories. What's the cheapest way to put both owners in front of the same missing-request case? This is the job interface, separate from safety control.
Use a trace where the app polls either side of the request, and put the PLC timer transition on that same timeline. Actually, first ask both owners to label who writes each value. A shared diagram with two writers hidden in it is still sketchy.
One writer each. PLC raises and clears request; app writes acceptance. The dispute is exactly when PLC may clear. I've drawn the app's delayed poll beside the current timer expiry.
That should make the gap visible without buying faster hardware. Are they proposing to retain the request until a matching acceptance, and what do they expect to happen if the app never answers?
Retained request is proposed. Unanswered request becomes a visible waiting fault needing the defined recovery, not permission to send another job. Restart handling still needs agreement; the timer argument is finally over.
Post how the restart example goes. That is where a page can look empty while the PLC still has work pending, and somebody decides another click will help.