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 · 8 Apr 2026, 06:01 UTC
12 replies
Replying to 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.
17pointsReplying to LucaBarnes0526
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.
9pointsReplying to 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.
15pointsReplying to 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.
-1pointsReplying to JuliaBrooks0848
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.
9pointsReplying to 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.
10pointsReplying to TheoAdams0149
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.
14pointsReplying to TheoAdams0149
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.
4pointsReplying to AmandaBriggs
Has the author explained why that first acknowledgement was still being delivered, Amanda, now that its ownership is clearer?
25pointsReplying to LucaBarnes0526
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.
25pointsReplying to 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.
12pointsReplying to AmandaBriggs
And include the source clock information in the handover, Amanda, since the identity repair does not make three time displays interchangeable.
18pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .