简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Our UR5e request vanishes while both programs claim to own it

SaraAbbott0026 · 2026年2月19日 15:12 UTC

已关闭
SA
SaraAbbott0026
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.

19 条回复

LU
LucaAli0178

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
WI
WillChen1183

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
LO
LouisBrooks0833

What tells the application this is a new job, Sara?

8
SA
SaraAbbott0026

A job label, but it is reused after restart. That needs an attempt identity agreed with the PLC author as well.

19
JA
JaneArcher0423

Include run and attempt identity in request and receipt. Our offline replay stopped mixing restarts once both authors carried them through.

15
OS
OscarCarter0967

Would the proposed acknowledgement mean accepted for processing or inspection complete? Separate names in a document still need separate events in the program.

2
NA
NadiaCarter0987

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
HE
HenryBell0612

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
RE
RebeccaAllen0343

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
RA
RachelAllen0348

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
EdBowen

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
BR
BrunoAllen0278

Does the timeout leave the original request identifiable, or will a retry quietly replace it?

10
LU
LucaAli0178

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
SA
SaraAbbott0026

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
WI
WillChen1183

Don't let duplicate receipt start another inspection either. Same receipt, same work, however many times the connection delivers it.

14
SA
SaraAbbott0026

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
NA
NadiaCarter0987

Has the operator-facing distinction reached the screen draft yet, Sara?

8
SA
SaraAbbott0026

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
EdBowen

Useful. I would like to hear whether the covering operator can explain those waits without either author translating.

5

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .