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 · 2026年2月19日 15:12 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
19 条回复
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.
21分I'd fix the ownership before making the pulse longer. Otherwise you've given two programs more time to disagree about the same bit.
9分What tells the application this is a new job, Sara?
8分A job label, but it is reused after restart. That needs an attempt identity agreed with the PLC author as well.
19分Include run and attempt identity in request and receipt. Our offline replay stopped mixing restarts once both authors carried them through.
15分Would the proposed acknowledgement mean accepted for processing or inspection complete? Separate names in a document still need separate events in the program.
2分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.
5分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.
17分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.
17分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.
11分ED
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.
18分Does the timeout leave the original request identifiable, or will a retry quietly replace it?
10分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.
13分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.
6分Don't let duplicate receipt start another inspection either. Same receipt, same work, however many times the connection delivers it.
14分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.
9分Has the operator-facing distinction reached the screen draft yet, Sara?
8分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.
6分ED
Useful. I would like to hear whether the covering operator can explain those waits without either author translating.
5分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .