I can't assign this acknowledgement confidently. Our FR5 housing-check application restarted and reused the job label, then timed out. The PLC and Python clocks disagree, with a controller event list offering a third opinion.
I've kept the original files. Is there a sensible first comparison I can do without spending an afternoon moving timestamps until the story looks right?
Look for an event both systems identify independently, not just two entries near each other. Does either trace carry a request counter or another identifier alongside the reused label?
Check the restart boundary in the Python file too. The same label before and after a process restart may describe two attempts even if the display makes it look like one job.
Aaron, PLC has a request counter. Dinesh, Python has a startup line between the two uses of the label. Its summary file drops the counter, but I haven't checked the raw received messages yet.
Please check the raw messages before fixing the clocks. We spent ages arguing about a one-hour offset in an exercise, then found the useful identifier sitting in a field the summary never printed.
It's held by quality, Callum. No automatic repeat. Mei, thanks for the raw-message nudge: the acknowledgement includes the earlier counter, not the counter allocated after startup.
Outgoing request and returned acknowledgement carry the earlier counter. The later request has a different one. I've split the report into those two attempts. Newer result still unknown.
I'd still investigate the clocks for future troubleshooting, but don't adjust the old originals. Add a separate explanation of the differences and how the counter established this link.
No, current offset alone would be a poor basis. I meant investigate their configuration and any recorded changes. The old correlation should stand on the captured identifiers we actually have.
The summary dropping the counter is worth fixing independently. A future maintainer should not need the same scavenger hunt to see that the attempts differ.
Quality has accepted the two-attempt description and owns the housing decision. We added the counter and application-run identifier to the summary. The original timeout hasn't magically gained a result.
That wording matters to planning too. Pending often ends up on someone's list of things to run again, even when the technical note below it says something more cautious.
Changed to outcome unknown for that case. Pending now isn't the label for everything we failed to save. Thanks, Mei; that was an awkward ambiguity we were about to keep.
Make sure it is more than a wording change. If startup still selects all missing-result entries for resubmission, a clearer report will not stop another uncertain attempt.