Before a historian ever decides what to keep, it has to decide how often to look. The scan rate is how frequently the collector reads a source value - the raw sampling that feeds the compression test. Set it too slow and you miss real events; set it too fast and you burden the source and the network for little gain. This guide explains what the historian scan rate is, the oversampling tradeoff, and why it is a different thing from a controller's scan cycle.
Historian Scan Rate in one line: The historian scan rate is how often a collector reads a value from its data source - the raw sampling interval that happens before any deadband or compression is applied. It sets the finest event the historian can possibly capture: nothing changing faster than the scan rate can be seen, no matter how the compression is tuned.
Data collection is a two-stage process. First the collector reads the source at its scan rate - polling a register or receiving a subscription update - producing a raw candidate value. Then a compression test decides whether that candidate is worth storing. The scan rate governs the first stage only. Compression can throw samples away, but it can never recover a change that occurred between two scans, because the collector never saw it. That makes the scan rate the ceiling on what the historian can capture.
This is why the scan rate and the compression deadband are separate settings that do different jobs. The scan rate controls temporal resolution - how finely time is sampled. The deadband controls amplitude resolution - how big a change has to be to matter. A fast scan with a wide deadband captures fast events but only stores significant ones; a slow scan with a tight deadband stores small changes but can miss a transient entirely because it happened between reads.
Collectors usually group tags into scan classes so that different tags can be read at different rates. A fast-moving pressure that needs one-second resolution can sit in a one-second scan class, while a slow tank level sits in a one-minute class. Assigning every tag to the fastest class wastes collector, network, and source capacity; assigning a fast signal to a slow class blinds the historian to its behavior. Choosing the class per tag is the practical form of choosing the scan rate.
It is tempting to scan everything as fast as possible on the theory that compression will discard the excess anyway, so nothing is lost. There is truth in that - a fast scan gives compression the raw material to catch a spike it would otherwise miss - but oversampling is not free. Every scan is a read against the source device, a message on the network, and a candidate the collector must evaluate. Scanning a thousand slow tags every second when they change once a minute loads the RTU, the link, and the collector for data that compression will mostly reject.
On constrained links, oversampling is genuinely costly. A remote site on cellular or satellite pays for every poll in bandwidth and sometimes in device power, and a scan rate far faster than the signal actually moves is wasted effort on a link that may already be the bottleneck. The right rate is fast enough to capture the fastest event you care about on that tag, and no faster - matched to the signal, not maximized blindly.
The opposite error, undersampling, is worse because it is invisible. If a pressure genuinely swings on a two-second cycle and you scan it every ten seconds, the historian records a smooth signal that never shows the swing - not because compression removed it, but because the collector never sampled it. Undersampling a real dynamic can also alias, making a fast oscillation appear as a slow drift. The archive looks clean and is quietly wrong, which is the most dangerous kind of data error.
The historian scan rate is easy to confuse with a PLC scan cycle or a controller scan class, but they live on opposite sides of the system. A PLC scan cycle is how fast the controller executes its logic and updates its outputs - a real-time control concern measured in milliseconds, driven by the need to keep a loop stable. The historian scan rate is how fast a collector reads values out of that controller for archiving - a data-collection concern, usually measured in seconds, driven by how much resolution the archive needs.
The two can be wildly different and usually are. A PLC might scan its logic every few milliseconds while the historian collector reads the same tag once a second, because control needs to react far faster than anyone needs to trend. Conversely, no historian scan rate can capture detail finer than the controller updates its own values; if the PLC only refreshes a register every 500 milliseconds, scanning it every 100 milliseconds just re-reads the same number several times.
The practical lesson is that they are tuned for different purposes and by different people. The control engineer sets the PLC scan to keep the process safe and stable; the data engineer sets the historian scan to give operations and analytics enough resolution without overloading the source or the link. Understanding that split keeps you from over-scanning a historian in a vain attempt to match control-loop speed, or from blaming the historian for detail the controller never exposed.
The scan rate controls how often the collector reads the source - the temporal resolution - and happens before any compression. Deadband compression then decides whether each read is significant enough to store, controlling amplitude resolution. Compression can discard samples but can never recover a change that happened between two scans, so the scan rate sets the ceiling on what the historian can capture and the deadband decides how much of it to keep.
It is not harmful to accuracy - a faster scan gives compression more chance to catch a transient - but it is not free. Every scan is a read against the device, a message on the network, and a candidate the collector must evaluate, so oversampling loads the source, the link, and the collector, especially on constrained cellular or satellite paths. The goal is a scan rate matched to the fastest event on that tag, fast enough to capture it and no faster.
No. The PLC scan cycle is how fast the controller executes logic and updates outputs, a real-time control concern usually measured in milliseconds. The historian scan rate is how fast a collector reads values out for archiving, a data concern usually measured in seconds. They are set by different people for different purposes, and no historian scan rate can capture detail finer than the rate at which the controller refreshes its own values.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.