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

Which attempt received this acknowledgement after the UR5e timeout?

NadiaCarter0987 · 2025年7月25日 21:59 UTC

已关闭
NA
NadiaCarter0987
I am reconstructing an inspection-reporting timeout from our Python log, PLC trace and UR5e event list. Their clocks disagree, and the application reused the same job label after restart. An acknowledgement appears in the records, but I cannot tell which attempt it belongs to. What can I establish without guessing the order from those timestamps?

7 条回复

EM
EmmaArcher0376

Keep the order inside each source and look for a shared event you can identify independently. I wouldn't just sort the three files by clock time. That can make a very tidy story out of a clock problem.

19
NA
NadiaCarter0987

Each source preserves its own order. The restart is identifiable, but the acknowledgement carries only the reused job label, with no attempt reference.

10
EM
EmmaArcher0376

Then a corrected timeline may still leave the acknowledgement ambiguous. Ask the application owner whether any other record links it to an attempt before assigning it to whichever one sits nearest on the page.

23
RI
RickShift

Was any new physical inspection observed after restart?

14
NA
NadiaCarter0987
回复 RickShift

The operator did not observe one, but was away from the station for part of that interval. I have recorded that as an incomplete observation, not evidence that nothing happened.

5
NA
NadiaCarter0987

No additional attempt link was found. The incident report leaves the acknowledgement unmatched. The interface owner is proposing unique attempt references and better clock records for future diagnostics; the old outcome remains uncertain.

13
EM
EmmaArcher0376

That's an honest result. Keep the unmatched example for testing the new scheme, so a delayed reply can't quietly attach itself to the next attempt just because the labels look familiar.

4

讨论已关闭

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