Our logs show a timeout during inspection-cycle reporting with Fairino FR5, but I can't assign an acknowledgement to the right attempt. We're in a small production cell with an inspection fixture, using a sample housing.
Python, PLC and controller timestamps don't agree, and our application reused the job label after restarting. I'm trying to reconstruct what we actually know.
Can your application log identify where the process restarted? That would distinguish the reused labels within one source, even with mismatched clocks elsewhere.
Keep source order, label the sessions and leave that acknowledgement unassigned. Comparing the timestamps alongside them should establish the combined order.
Those clocks disagree. Why would putting their timestamps beside the sessions establish an order across systems without an offset or matching exchange?
@JamieChan1078 You're right; I went too far. Timestamps suggest matches. Keep source order and mark cross-system links uncertain unless evidence supports them.
I had a clock adjustment make a merged incident view look plausible on my setup. The original per-source order was what let us correct the interpretation.
Use monotonic time for durations within a running process. It doesn't supply a shared clock across machines or restarts; keep session identity and wall-clock reference alongside it.
I can't see a correlation field in our export. I'll need the interface owner's input, and that won't retroactively identify the entries I already have.
@HassanBennett0704 Request recorded, acknowledgement received, completion reported, each with its source. Timeout means your wait ended; it doesn't establish the robot's final result.
This resolves how I'll present the incident: separate source sequences, application sessions identified, and the unmatched acknowledgement left uncertain. I'm not claiming that establishes the job's final outcome.