I watched the reporting author put three logs into one time-sorted sheet and point to the acknowledgement nearest the timeout. Then we found the application had restarted and reused the plate-job label. The clocks disagree too, so the tidy sheet is doing more convincing than the underlying records.
I have kept the source files and asked for the request identities. I do not want to accuse the controller of ignoring a request when we may be reading the receipt for another attempt. What can we establish without pretending those clocks already agree?
The PLC trace has a retained request counter. The application summary does not show it, but the author says the original request record contains it. We are checking that record rather than adding clock offsets by eye.
We once lost the useful reference in a shortened export. Compare the original request and receipt fields before deciding the detail was never recorded.
Interested whether that recovers a real match, Laura; our support enquiries have become much shorter when the author stops calling several different events done.
Original request record contains the same counter and job identity as the PLC trace. It distinguishes the two attempts even though the application's display label repeats after restart.
Also have the author define what the receipt means in this job. Request accepted and inspection result recorded are different stages, even if somebody summarised both as an acknowledgement in the support email.
The receipt contains it. It belongs to the earlier attempt, while the timeout belongs to the later one. Jane, the agreed receipt means the application accepted the request, not that the plate passed inspection.
Yes. Its request is present, but no matching receipt survives in the retained application interval. That leaves the timeout unexplained; it does not establish that the request was never received.
They want the preceding application interval with the request counter retained. The recorder owner is checking whether its archive still contains it. The summary now groups by attempt and keeps each source's time visible separately.
Has the revised export been checked against the original request records? A correct explanation beside the screen will not help if the support bundle still drops the counter when somebody downloads it.
It has. Both attempts retain their different counters in the exported bundle, with the earlier receipt attached correctly. We also tried another repeated display label in the offline check; it did not merge the histories.
No, the archive no longer contains it. We have corrected the report and agreed a capture that retains the required lead-in for a future occurrence. I can withdraw the false receipt pairing, but I cannot give this old timeout a cause.