Our UR5e inspection request ends before the application notices it

Did the PLC clear the request itself, or did something from the application clear it? I mean the observed event, not what the screen label suggests.

Will, no accepted request in the application history. Carla, the PLC clears it on its timer. No acknowledgement involved.

That gives the controls and application owners a concrete case to walk through. I would have them define request, receipt, busy, completion and clearance together, including the identity carried through the exchange. Otherwise both sides can implement their own reasonable but incompatible meaning of ready.

Maria, would you show the waiting plate separately from the connection status, so a healthy link doesn't make the unfinished job disappear?

Walk through one missed receipt on paper with both owners before changing timing, because the unanswered ownership question will survive a longer pulse

Who bought the interface integration? Put that owner in the meeting. This shouldn't become Sam's unpaid job of translating between two suppliers who each say their half works.

Keep the plate's acceptance status separate from receiving its inspection request, since a receipt alone gives quality no result to accept.

Anna, I would include what each side retains after reconnecting in that same definition. The handover needs a way to explain an unfinished job, not merely a sequence that works while both applications stay up.

Proposed starting point for their review: hold the identified request until receipt is acknowledged, then track completion separately. They still need explicit timeout and recovery behaviour, not an everlasting waiting lamp.

Nathan, yes. Connected, waiting for receipt and waiting for a result are different messages. I'd avoid one big green status swallowing all three.

Integrator owns both sides, Isaac. The trainer agrees the current ready label is misleading. Thank you Maria and Nathan.

Toby, that proposal is understandable, but I would want the owners to say what prevents an old acknowledgement clearing a new request. Holding the request longer is only part of the agreement.

Will, agreed. The acknowledgement must be attributable to the request it answers, with stale responses and reconnects included in the review. I meant that by identity, but it should be explicit in the examples rather than buried in a heading.

Would the handover include a deliberately delayed response example? Easier for me to understand than a signal table where every row happens immediately.

Carla, include one that never arrives too, otherwise the demonstration never teaches who gets called when waiting doesn't end

And an interrupted example, with the retained request and physical plate reconciled under the agreed recovery method. I would not sign off the handover on a happy-path demonstration alone.

Those examples are now in the review agenda. Interface changes and operator wording are still proposals, not commissioned behaviour.