our UR5e job request clears before the application accepts it

PLC owns request, application owns result, but there is no receipt acknowledgement. The current notes use complete for both receiving the request and finishing inspection. I have highlighted those two meanings.

Two different events deserve two different names.

And the operator needs to know which wait matters. Waiting for acceptance and waiting for a result may send them to different people. A perfect signal table can still produce a useless screen.

We have that trace. The request rises and falls between two application polls. No application acceptance or inspection start is recorded for that occurrence.

That's a useful test case. Now add disconnect after acceptance, result while disconnected and restart with a request already present. A longer pulse alone leaves those cases waiting for you.

Who decides whether an uncertain inspection can be repeated?

The shift lead, with the controls maintainer handling unresolved state. The draft currently says retry permitted after review, but it does not say how that decision is recorded.

I would not hide the missing record inside after review. The person on the next shift needs to see which item was reviewed and what was decided. Otherwise every change of shift starts the argument again.

Does the proposed request include an identity that returns with its acknowledgement and result? The trace shows why this request was missed, but a later old response could still be mistaken for new work.

Yes, specify identity through the whole exchange, including a restart boundary. A number that resets locally while the other side retains old results is an invitation to a very plausible wrong answer.

The two owners are adding run and request identity to the proposed interface. Review decisions will refer to that identity and the physical item. We have not changed the deployed exchange yet.

Thanks. That gives the shift lead something identifiable.

I still want the screen walked through by an operator. Developers can agree that retained means retained and miss that the person sees only a frozen green box with no explanation.

Dinesh, has the draft been tried with someone who was not in the design discussion? Interested whether they can distinguish waiting from needing a review without extra verbal help.

Two operators reviewed screen mockups. Both read request accepted as inspection passed, so the labels need changing. They did understand the named review contact and item reference.

That's an expensive misunderstanding caught on cheap paper.

Try the revised labels with the same failure sequence, not only the clean run. Include who clears the reviewed condition, so fixing the wording doesn't leave them stuck at a better-described wait.

Revised draft distinguishes received, inspecting and result, with the review state separate. Controls has the clearing rules and test cases. Joint testing and operator practice remain outstanding.