I thought I had a simple timeout to explain. Then I put the Python log beside the PLC trace and controller events. Their times disagree, and the application reused the same job label after restarting.
There is one acknowledgement near the timeout in the sorted view. It might belong to the earlier attempt. I don't want to build a confident story from the sort order just because it looks tidy. Has anyone found a useful first comparison when the original events are still available but the labels are this poor?
Two UR5e attempts share one label and three different clocks
AmandaBriggs · 2026年4月8日 06:01 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
12 条回复
回复 AmandaBriggs
Preserve the original order within each source and split the application sessions first, because one reused label should not make two attempts look like one long attempt.
17分The restart marker separates them clearly in the raw application file. Our merged report removed that marker. I've put the two sessions into separate columns beside the untouched PLC and controller files.
9分回复 AmandaBriggs
Good start. Does the raw acknowledgement carry anything besides that short job label? Don't let the report decide which fields are worth seeing.
15分回复 AmandaBriggs
Record the clock settings and any known uncertainty before aligning those columns; changing today's clocks will not retrospectively establish the order of the old events.
-1分Julia, the raw acknowledgement contains a sender session value that the report drops. Leah, the controller export uses a different time basis; the maintainer is documenting that before we compare times.
9分回复 AmandaBriggs
Can that sender session be linked to either application attempt independently of the timestamps? I would use it only if its meaning and lifetime are known, not because it happens to look like the earlier session value.
10分Theo's right about the meaning. We fixed a display and export together on another job because the pretty view had hidden the identifier; fixing just Amanda's spreadsheet would leave the next person with the same trap.
14分The application author confirms the field is the sender's session identity, and the saved start exchange links it to the first attempt. The acknowledgement belongs there. The second attempt has no matching acknowledgement in these records.
4分回复 AmandaBriggs
Has the author explained why that first acknowledgement was still being delivered, Amanda, now that its ownership is clearer?
25分A queued delivery survived the first application's disconnect. The developer reproduced that offline and fixed the report to retain session and attempt identity. The new test delivers the older acknowledgement while the newer attempt waits; it stays with the first attempt.
25分回复 AmandaBriggs
Does the newer attempt's own acknowledgement still appear correctly after that delayed one? The test needs to show you have not simply ignored everything arriving after a reconnect.
12分回复 AmandaBriggs
And include the source clock information in the handover, Amanda, since the identity repair does not make three time displays interchangeable.
18分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .