Our UR5e bracket verification log uses check-7 before and after a Python restart, and the PLC clock disagrees with the laptop. I've got an acknowledgement with two possible homes, neither especially convincing
Can you see the application restart in the original log, and does either side retain a sequence number? Start there before shifting timestamps around. The same label on both attempts makes a sorted spreadsheet look more certain than it is.
Restart is clear, sequence number isn't. Python starts numbering again at one, while the exported PLC trace only contains the job label and acknowledgement state
Ask controls whether the original capture contains more fields than the export. You might recover an attempt reference that was left out. Keep the original order within each log meanwhile, even though the clocks do not line up.
Julia's point matters for the report too. A state sampled at capture start needs a different description from a recorded transition. Otherwise the next person may read it as an event you actually saw.
Keep the observation, though. It tells the reader what was present when capture began, even if its origin remains unknown. Put the missing earlier trace beside that limitation.
We once spent ages aligning clocks only to find a held bit in every row. Is there an older capture on the engineering laptop before anyone goes looking for clever timing tools?
Did controls find any earlier capture or extra identifier, Anika? I'm curious whether you managed to connect either attempt, or whether this remains a logging change for the next investigation.
No earlier capture turned up. Controls is adding an attempt reference that survives application restarts; the old acknowledgement stays unassigned. Thanks Julia, that arrow would have become a very confident paragraph