Every PLC and RTU keeps its own clock, and left to itself no two clocks tick at exactly the same rate. Without something continuously correcting them, a field device's clock and the SCADA server's clock slowly pull apart, so a value the PLC timestamped drifts further and further from server time as the days go by. This is clock drift, and it is different from getting the time zone wrong once. This page explains how drift accumulates, why a slowly growing offset quietly corrupts event ordering and historian alignment, and how to tell drift apart from a one-time timestamp mistake.
PLC-to-SCADA clock drift in one line: Clock drift between a PLC and SCADA is the gradual divergence between a field device's internal clock and the SCADA server's clock when the device is not being continuously synchronized by a time source such as NTP or PTP. Because no crystal keeps perfect time, the device's clock runs slightly fast or slow and its offset from server time grows steadily, so source timestamps land seconds or minutes off - corrupting sequence-of-events ordering and historian alignment.
A PLC or RTU marks time with a crystal oscillator, and every crystal has a small error - it runs a touch faster or slower than true time, and that rate is affected by temperature and by the individual part. Over a minute the error is invisible. But drift is cumulative: a clock that gains or loses a fraction of a second per day keeps doing so, and with nothing to reset it the offset just grows. After weeks, a device that was set correctly at commissioning can be seconds or minutes away from actual time, and different devices drift by different amounts and in different directions, so a whole fleet slowly fans out.
The cure is continuous synchronization. NTP disciplines device clocks over the network to a common reference, and PTP does it with much tighter precision where sub-millisecond alignment is needed; either one repeatedly nudges a device back toward true time so its error never accumulates. The problem arises with devices that have no time synchronization configured - an RTU that was set by hand at install and never disciplined, or a PLC on a segment that cannot reach a time server. Those clocks free-run, and free-running clocks drift. That is why clock drift is fundamentally a symptom of missing or broken time synchronization rather than a fault in the device itself.
Drift does its real damage to anything that depends on comparing timestamps across devices. Sequence-of-events analysis is the clearest casualty: when an incident cascades across several devices and you need to know which event happened first, you rely on their source timestamps. If one device's clock has drifted seconds ahead and another's seconds behind, the recorded order can be wrong - an effect can appear to precede its cause - and the investigation is led astray. The whole value of a sequence-of-events record is accurate relative ordering, and drift silently destroys it.
Historian alignment suffers the same way. When values from many devices are stored against their source timestamps and later overlaid on a trend or fed into a calculation, drift misaligns them: two signals that actually moved together appear staggered because their clocks disagree, and a computed value that combines several tags can be built from samples that were never truly simultaneous. Over long records the misalignment can wander as the drift grows, so the error is not even constant. What makes this insidious is that nothing looks broken - each device is happily timestamping and reporting, the data flows, and only when someone tries to line up events across sources does the disagreement surface, often during exactly the incident review when accurate timing matters most.
It is worth separating drift from a one-time timestamp error, because they look similar but call for different fixes. A time-zone or one-time setup mistake produces a fixed offset - a device reads exactly one hour off, or exactly some constant amount off, and it stays that way. Drift is different: the offset is not fixed, it grows over time, and it differs from device to device. So the diagnostic tell is whether the discrepancy is a stable constant that suggests a zone or configuration mistake, or a slowly widening gap that suggests a free-running clock. Correcting a timezone error is a one-time reconfiguration; correcting drift means putting the device on continuous synchronization so it stops accumulating.
This is where comparing source and server timestamps becomes the key diagnostic, and where a cloud platform can make drift visible. Every value can carry both the time the field device stamped it and the time the server received it, and the gap between those - beyond normal transmission delay - reveals a drifting clock. It helps operations when the platform surfaces that offset so a device whose source timestamps are creeping away from server time stands out before it spoils a sequence-of-events review. A cloud SCADA platform such as Merobix records both the source and server timestamps with each value, so a slowly growing divergence on a particular RTU is detectable as a trend rather than discovered too late, and the remedy - enabling or repairing time synchronization on that device - can be targeted at exactly the clock that is drifting.
The PLC keeps time with a crystal oscillator that runs slightly fast or slow, and without continuous synchronization that small error accumulates day after day until the device is seconds or minutes off. Devices with no NTP or PTP time source - an RTU set by hand at install, or a PLC that cannot reach a time server - free-run and drift. It is a symptom of missing or broken time synchronization rather than a fault in the device.
A timezone or one-time setup mistake produces a fixed offset - the device reads a constant amount off and stays there - so it is corrected with a single reconfiguration. Drift is a growing offset that widens over time and differs from device to device, because the clock is free-running. If the discrepancy is a stable constant it points to a zone or config error; if it is a slowly widening gap it points to drift needing continuous synchronization.
Sequence-of-events analysis relies on comparing source timestamps across devices to establish which event happened first. If one device's clock has drifted ahead and another's behind, the recorded order can be wrong, so an effect can appear to precede its cause and mislead an investigation. The same misalignment staggers historian trends that should line up, which is why disciplined clocks matter most exactly when timing does.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.