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

Our UR5e restart helper treats an uncertain verification as never sent

HazelBaker0484 · 2026年7月30日 15:21 UTC

回复讨论
HA
HazelBaker0484
I cannot justify automatically retrying every pending housing verification after our application crash: the request may have reached the UR5e and continued while its result was never saved, but the same pending state also means unsubmitted work. What recovery distinction should replace that assumption?

5 条回复

PR
PriyaCarter1003

Split known-unsent work from uncertain execution, and hold the latter for reconciliation with available PLC and controller evidence. A missing local result doesn't prove the request never ran, whatever the old helper calls that row.

6
HA
HazelBaker0484

I've stopped automatic replay of the ambiguous entries and kept the original records; the affected housing's result is still uncertain.

19
PR
PriyaCarter1003

Test the boundaries before send, after possible send and around saving the reply. Keep a distinct attempt identity and an agreed review route for cases whose execution evidence cannot be recovered.

18
HA
HazelBaker0484

The offline restart tests now leave the post-send case unresolved rather than resubmitting it; the PLC correlation and authorised recovery decision are still with the interface owners.

8
PR
PriyaCarter1003

Does the startup view explain that unresolved state to the next shift? I'd want the evidence to collect and the escalation role visible, without the screen suggesting a repeat operation has been approved.

20

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。