Our Python job name starts again after restart while the PLC keeps logging, so sorting the mismatched timestamps gives me a lovely story with no basis for choosing which housing attempt owns the acknowledgement.
I can't choose which housing attempt this UR5e acknowledgement belongs to
GabrielChen1149 · 12 Feb 2026, 02:52 UTC
3 replies
Replying to GabrielChen1149
We had a similar reconstruction fail because the report dropped startup markers. Check the original files for a run boundary and anything carried across both systems, such as an attempt identity or distinctive request sequence, before applying clock offsets.
14pointsReplying to ChloeArcher0396
Startup boundary is there but the acknowledgement carries only the reused job name, and neither trace retains a shared unique request marker, so I've left the two possible attempts in the account instead of picking the nearest time
14pointsReplying to GabrielChen1149
That is an honest limit for the old incident. For the proposed recording change, test a delayed response across restart and confirm you can distinguish the attempts without relying on the clocks being close.
23pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .