I can locate a timeout in our UR5e housing-inspection reporting logs, but I cannot assign the acknowledgement to an attempt. Python reused the job label after restart, and the PLC, application and controller timestamps disagree. I am reconstructing the retained records, not assuming the timeout means nothing happened. What links would you look for before accepting a match?
What ordering can each source establish on its own? I'd keep three local sequences before attempting one combined timeline. Moving clocks until the lines look sensible can manufacture the answer you're meant to be investigating.
Can the controller records distinguish request receptions using something other than your reused application label? I would ask its owner explicitly; a missing identifier in Python need not mean no independent evidence exists.
The application has a clear restart boundary and two uses of the same label. The PLC export shows request transitions, but its acknowledgement record contains only the repeated job label. I have asked for the controller's retained event detail without changing the original times.
Keep the request-send record distinct from confirmed receipt too. If the application logs sending before the write finishes, the local sequence may prove what the code attempted rather than what the other side received.
And don't restart or resubmit a job to see which log it resembles. You can test logging gaps offline. The old housing's outcome has to stay unresolved until its own evidence supports more.
No resubmission involved. The application send line is indeed written before the communication call, so I have relabelled it send attempted in the reconstruction. Its timeout follows, but that pair does not establish PLC receipt.
That is a useful distinction. Are there shared events with a known relationship that can bound the clock difference, rather than a guessed constant offset from the one acknowledgement you want to match?
A bounded clock comparison may narrow the candidates, but still keep any identity evidence beside it. Two attempts close together can remain ambiguous even after you have a reasonable time range.
The controller export separates two request receptions around a recorded restart, but the retained acknowledgement lacks the reception reference. Shared sequence observations narrow its possible interval without identifying which attempt it answers. We still have two candidates.
Then the handover needs two candidates, not one selected because its time is nearer. What will the reporting application show for that housing while the evidence remains incomplete?
It can also be a useful offline regression case for the future matcher. A test that expects unresolved here is more honest than one with a guessed answer baked into the expected output.
The report now shows reconciliation required, with neither attempt credited as accepted. We have retained the three original sequences and the reasons each possible link is insufficient. The future interface proposal uses attempt identity that survives restart, but the owners have not approved that design yet.
Thanks for reporting the unresolved result. Does the proposed identity reach the acknowledgement producer as well as the application? A better Python label alone would leave this same missing link at the far end.
That is now an explicit requirement in the joint proposal. I have also kept the historical case separate: improving future correlation will not recover an identity the old acknowledgement never recorded.