I'm staring at a Python timeout, a PLC acknowledgement and a controller event that could belong to either of two bracket checks. The application restarted and reused its friendly little job label. Very friendly. Now two attempts answer to it.
The three clocks disagree as well. I have kept the original exports, but sorting all the rows by the displayed time gives me a story I don't trust. Is there a sensible way to work out what we can still say about these attempts?
We once counted repeated tests as extra parts because the summary label looked unique. Start by separating the application sessions and keeping each source's original order. What identifies the restart apart from the reused label?
There is a process-start entry in Python and a new connection entry in the PLC trace. The controller list has no matching job label. I can split Python into two sessions at least.
Preserve the original timestamp and source on every row. Then look for events whose relationship is independently known, such as that connection transition. I would not assign one fixed clock offset across a restart without checking whether the offset changed.
Different physical bracket numbers are in the operator's sheet. Neither appears beside the PLC acknowledgement. So I know two brackets were involved, not which one that acknowledgement belongs to.
Then leave that acknowledgement unassigned for now. Can you at least distinguish a new attempt from a retry within each application session? That would stop another kind of double counting.
Owen, don't let someone fill the empty cell with the most convenient bracket number. Your operator sheet can show two samples without rescuing a missing link in the software history.
For future captures, ask the authors for an attempt identifier that survives across the participating logs, with retries linked to it and sessions identified separately. That will need testing through restart, not just during an uninterrupted run.
Felix Ali, retries are distinguishable inside each Python session, so I've separated those. Zara, the authors added session and attempt references to the test build and retained the source times. We still cannot assign the old acknowledgement.
Restart test is done. Two jobs with the same display label now have different attempt references in the application and PLC capture, and the retry stays attached to its original attempt. We can follow the new test without borrowing the operator's bracket number to guess. The historical acknowledgement stays unknown.
That is useful progress. Does the exported summary preserve those references too, or only the detailed logs? The summary was where our repeated tests turned into imaginary extra parts.