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

My reused housing job label leaves the UR5e acknowledgement unassigned

ReeceBrown0906 · 2026年7月28日 14:13 UTC

回复讨论
RE
ReeceBrown0906
I'm reconstructing a fixture-inspection timeout, but the Python, PLC and UR5e clocks disagree and the app reused the housing job label after restart; what can I establish without assigning the acknowledgement to whichever timestamp looks closest?

5 条回复

BR
BrunoAdams0104

Preserve the original records and separate the application runs at restart. Look for request or attempt identifiers, recorded sequence and message content before comparing clock times. A common label may describe the housing job without uniquely identifying the attempt that received an acknowledgement.

3
RE
ReeceBrown0906

I can separate the application runs, but neither acknowledgement nor request includes a persistent attempt identifier and I have no measured clock offsets for that period.

14
BR
BrunoAdams0104

Then preserve the ambiguity. You may be able to bound possible associations from ordering within each source, but cross-system proximity is not proof. Also distinguish receipt acknowledgement from inspection completion; even a correctly assigned receipt would not establish the housing's result.

15
RE
ReeceBrown0906

I've recorded both possible associations and left the acknowledgement unassigned; quality's housing disposition is a separate enquiry, not a result inferred from this timeout.

14
BR
BrunoAdams0104

For future attempts, ask the application and interface owners for identity that survives restart and is carried through the relevant records. Record clock relationships too, but don't expect that improvement to retrospectively decide this old event.

8

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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