I am documenting an ordinary inspection handshake on our UR5e training cell. The PLC request clears on a timer, while the application sometimes misses it. The safety functions are separate. I need the job interface owners to agree what receipt, completion and clearing actually mean before the handover is useful.
Get the PLC and application people to draw the same sequence, with one writer for each signal. A request cleared by elapsed time can disappear without either side ever agreeing that work was accepted.
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.
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.
Could you capture one missed request before changing the design? I mean the PLC transition and the application's observation interval from the same occurrence, so the proposed repair has a specific case to reproduce.
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.
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.
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.
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.