Our logs show a timeout during fixture inspection with Universal Robots UR5e, but I can't assign an acknowledgement to the right attempt. We're in a commissioning station recording job events, 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.
@NoraAli0235 Can your application log identify where the process restarted? That would distinguish the reused labels within one source, even with mismatched clocks elsewhere.
Start with the session split and each source's own ordering, leaving that acknowledgement unassigned. The timestamps beside those entries should establish a combined sequence.
Those clocks disagree. Why would putting their timestamps beside the sessions establish an order across systems without an offset or matching exchange?
You're right to challenge that. The timestamps can suggest matches, not prove them. Keep source order intact and label cross-system links uncertain unless there's supporting evidence.
@FarahBaker0504 I'll keep that acknowledgement unassigned. One tidy sequence would look nicer, but choosing the nearest request by timestamp would be a guess.
@NoraAli0235 My merged log fooled us after a machine clock adjustment. Keeping the original source order let us untangle our confidently wrong interpretation.
@NoahArcher0368 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.
@FarahBaker0504 Does the documented PLC interface support a correlation value? Application identifiers alone won't create matching identifiers in another system's records.