Receipt and completion now have separate meanings in our interface review. The draft still lets both programs clear the request, and the application sometimes misses the brief PLC pulse. Ordinary job signals only; safety functions are separate.
Our UR5e request vanishes while both programs claim to own it
SaraAbbott0026 · 19 Feb 2026, 15:12 UTC
19 replies
Replying to SaraAbbott0026
Give each signal one writer and agree the full exchange with both authors. A held request with a matching acknowledgement can survive a slow poll, but only if both ends agree when each owner clears its own output.
21pointsReplying to SaraAbbott0026
I'd fix the ownership before making the pulse longer. Otherwise you've given two programs more time to disagree about the same bit.
9pointsReplying to SaraAbbott0026
What tells the application this is a new job, Sara?
8pointsReplying to LouisBrooks0833
A job label, but it is reused after restart. That needs an attempt identity agreed with the PLC author as well.
19pointsReplying to SaraAbbott0026
Include run and attempt identity in request and receipt. Our offline replay stopped mixing restarts once both authors carried them through.
15pointsReplying to SaraAbbott0026
Would the proposed acknowledgement mean accepted for processing or inspection complete? Separate names in a document still need separate events in the program.
2pointsReplying to OscarCarter0967
What should the operator do when receipt has been confirmed but the inspection result has not arrived? That is a different wait from a request nobody has received.
5pointsReplying to SaraAbbott0026
And preserve the history on reconnect. An empty local list can make the same retained completion look new again, even with a useful job label.
17pointsReplying to SaraAbbott0026
Could the two authors walk through one delayed poll together before anyone changes the code? Seems a cheap way to expose which arrow each expects next.
17pointsReplying to RebeccaAllen0343
Rebecca's walkthrough should include the housing still at the fixture when the application loses contact, so nobody writes a restart instruction that assumes a fresh empty job.
11pointsED
Replying to NadiaCarter0987
I would bring the covering operator into that explanation too, once the authors agree it. Otherwise the job can have immaculate internal names while the screen still offers a button nobody knows how to interpret.
18pointsReplying to SaraAbbott0026
Does the timeout leave the original request identifiable, or will a retry quietly replace it?
10pointsReplying to BrunoAllen0278
Keep it identifiable. If a late acknowledgement arrives after timeout, it must still belong to that original attempt. A new attempt should not inherit it because somebody has stopped waiting.
13pointsReplying to OscarCarter0967
Oscar: acknowledgement means accepted for processing, separate completion result later. Bruno: timed-out attempt remains identified. Authors are walking through delayed poll, duplicate receipt and late acknowledgement together.
6pointsReplying to SaraAbbott0026
Don't let duplicate receipt start another inspection either. Same receipt, same work, however many times the connection delivers it.
14pointsReplying to RebeccaAllen0343
Walkthrough found the application cleared the request before the PLC had observed acknowledgement. Revised draft gives each output one owner and specifies the return-to-idle order. It includes unmatched and interrupted cases.
9pointsReplying to SaraAbbott0026
Has the operator-facing distinction reached the screen draft yet, Sara?
8pointsReplying to NadiaCarter0987
Yes. Waiting for receipt and awaiting inspection result are separate on the draft, with the agreed assistance route. Implementation and testing remain to do; this closes the conflicting ownership definition, not the whole fix.
6pointsED
Replying to SaraAbbott0026
Useful. I would like to hear whether the covering operator can explain those waits without either author translating.
5pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .