Two intervals govern how a process value moves from a sensor into long-term storage, and confusing them leads to misdiagnosed data problems. The sampling interval is how often the system reads the sensor; the logging interval is how often it writes a value into the historian. They are frequently set to different numbers on purpose, and understanding the gap between them explains both why a historian can store far fewer points than it reads and why a fast event can still slip through the record unrecorded.
Sampling Interval vs Logging Interval in one line: The sampling interval is how often a sensor or tag is actually read; the logging interval is how often one of those readings is written to the historian. Sampling usually happens faster than logging, so many reads are taken and only some are stored - which saves storage but risks missing a transient that occurs between logged points.
Picture the path a measurement takes. A sensor produces a value continuously; a device reads that value on the sampling interval, turning the continuous signal into a stream of discrete readings; then the historian decides, on the logging interval, which of those readings to keep permanently. These are two separate clocks doing two separate jobs. The sampling clock determines what the system knows about the signal in the moment; the logging clock determines what survives into the archive.
When the two intervals are equal, every reading is stored and the distinction barely matters. The interesting behavior appears when they differ, which is common. A pressure tag might be sampled every second so that fast logic and alarms have fresh data to act on, yet logged only every fifteen seconds because storing every second for years would be enormous. In that arrangement fourteen of every fifteen readings are used briefly and then discarded, and only one becomes part of the historical record.
The decoupling can also run the other way with smarter logging rules. Instead of storing on a fixed logging interval, a historian may sample fast and then store only when the value changes by more than a deadband, or store the highest and lowest sample seen since the last write. In all these schemes the sampling interval still sets how often the signal is looked at, and the logging rule - fixed interval, deadband, or min-max - decides which of those looks are worth keeping.
The reason to log less often than you sample is storage and bandwidth. A tag stored every second generates dramatically more data over a year than the same tag stored every minute, and a site with thousands of tags multiplies that into a real cost in disk, transmission, and query time. Logging on a longer interval, or only on significant change, lets a system read frequently enough to stay responsive while writing sparingly enough to be affordable to keep for years. That is the win, and for slow, well-behaved process variables it comes at almost no cost.
The risk lives in the gap between logged points. If the sampling interval catches a spike but the logging interval does not fall on that spike, the spike may never be written. A pressure surge that lasts two seconds is visible to a one-second sample but can be entirely absent from a fifteen-second fixed-interval log if none of the stored samples land during the surge. The historian will show a smooth line across an event that actually happened, and no query of the stored data can recover what was never written.
This is why the logging rule matters as much as the interval. A plain fixed-interval log is the most likely to miss transients, because it stores whatever the value happens to be at each tick regardless of what occurred between ticks. A min-max logging rule, which stores the highest and lowest sample seen in each logging window, deliberately preserves the peak of a transient even while discarding the calm samples around it. Choosing the logging rule to match how the tag behaves is how you keep the storage savings without going blind to the events that matter.
In a cloud SCADA deployment the two intervals often live in different places, which is precisely why keeping them straight matters. The sampling interval is typically set close to the field, in the RTU or the collector reading a device, while the logging behavior is configured where data lands in the historian. A platform like Merobix exposes both so that an engineer can decide independently how fresh the live data needs to be and how densely the history needs to be kept.
Getting the pairing right is a per-tag judgment. A slow tank level that drifts over hours can be sampled and logged sparingly with no loss of meaning. A fast pressure or vibration signal that can spike in seconds needs a sampling interval fast enough to see the spike and a logging rule - a tight deadband or min-max - that guarantees the spike is stored rather than merely observed and thrown away. Treating every tag with one blanket interval either wastes storage on the slow tags or loses events on the fast ones.
The payoff of decoupling them well is a historian that is both affordable and trustworthy. Frequent sampling keeps dashboards and alarms responsive to what is happening now; disciplined logging keeps years of history without hoarding redundant points; and a logging rule matched to each tag's behavior means the archive still contains the transients that a naive fixed interval would have quietly dropped. The whole point of separating the read clock from the store clock is to get all three of those at once.
Because they serve different needs. Fast sampling keeps live values, alarms, and control logic responsive to what is happening right now, while slower logging keeps the historian affordable to store and query over years. A tag might be read every second but written to history every fifteen seconds, using the frequent reads for the moment and keeping only some of them permanently.
Yes, and this is the main risk of decoupling the two. If a spike occurs between logged points and the logging rule does not capture it, the event is read by the fast sample but never written to history, so no later query can recover it. A min-max or tight-deadband logging rule reduces this by deliberately storing the peak of a transient even when it discards the calm samples around it.
No, though they are related choices about what to store. A fixed logging interval writes a value on a set schedule regardless of change. A deadband instead stores a value only when it moves by more than a threshold since the last stored point. Both are logging rules layered on top of the sampling interval, but one is time-based and the other is change-based.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.