I'm reconstructing a failed fixture inspection attempt on Universal Robots UR5e in a commissioning station recording job events, using a machined bracket.
Our Python log, PLC trace and controller event list have disagreeing timestamps.
The application also reused its job label after a restart.
I can see a timeout, but I can't tell which attempt an acknowledgement belongs to
Which acknowledgement belongs to my retry? - fixture inspection
HanaBrown0883 · 2026年4月24日 03:45 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
11 条回复
@HanaBrown0883 Got a process-start entry? That could separate the reused labels without trusting another machine's clock.
15分@DineshBennett0734 Found it. I can split our Python log into two sessions. Still no attempt match for that PLC acknowledgement, though
10分Keep source order, label the sessions and leave that acknowledgement unassigned. Comparing the timestamps alongside them should establish the combined order.
18分Those clocks disagree. No offset or causal link, no established combined order.
0分回复 RickShift
You're right; i went too far. Timestamps suggest matches. Keep source order and mark cross-system links uncertain unless evidence supports them.
20分I'll keep that acknowledgement unassigned. One tidy sequence would look nicer, but choosing the nearest request by timestamp would be a guess
4分My merged log fooled us after a machine clock adjustment. Keeping the original source order let us untangle our confidently wrong interpretation.
10分Would monotonic time fix it? Or only inside one process?
10分@FarahBrooks0852 Inside a running process. Machines and restarts don't automatically share that clock, so keep a session ID and wall-clock reference too.
19分This resolves how I'll present the incident: separate source sequences, application sessions identified, and the unmatched acknowledgement left uncertain. I'm not claiming that establishes the job's final outcome
8分That gives readers an honest incident view without making the unknown result look settled.
12分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .