• Tag Group (normal execution rate)
• Historical Tag Group (e.g. Default Historical)
• Sample Mode (Tag Group vs On Change vs Periodic)
• Deadband Style (Auto vs Analog vs Discrete)
I understand that the Tag Group controls how often the tag is evaluated/read, while the Historical Tag Group controls how often the historian evaluates whether a sample should be stored. However, it’s not entirely clear when it is best to reuse existing tag groups versus creating a dedicated Historical Tag Group, or how closely these two rates should be aligned.
Additionally, I’m looking for clarification on Deadband Style = Auto. Since Auto switches between Analog and Discrete based on the tag’s data type, what are the recommended practices for tags that are non-float types (e.g. INT/DINT) but represent states, enums, or AOI state machines?
In practice, what configuration patterns are recommended to:
Avoid unnecessary historian evaluations
Prevent excessive or noisy history
Ensure important state changes are reliably captured
Any guidance or real-world examples would be appreciated.
I'll be honest in that the historical tag groups have always confused me (there's a min/max time between samples on the tag group, but also on the tag itself there's a max time between samples). So I've just avoided using them to remove confusion.
On change is just like it says. Every time the tag value changes, it evaluates against the min/max sample time and deadband settings to determine if it should be recorded.
Periodic evaluates the value on a periodic basis rather than every change and will store it if it falls outside the deadband or if the max time has elapsed.
On deadband styles, I stick with Auto except for tags that aren't "fluid" in their changes. This includes setpoints, alarm limits, sequence steps, etc. where I use Discrete. This makes a big difference due to how analog points are stored compared to discrete points. Discrete points will essentially be recorded on change, but analog points will be stored in memory and each new value is compared to the previously stored and previous values to determine if the value is outside of the deadband and if the previous point should be recorded or ignored. Deadbands in analog deadband style are based on a rate of change rather than an absolute change (it can get confusing, but check the link below to help explain the math behind it all).
Just a word of advice: there are scenarios where relying on the automatic Tag Historian isn't ideal. I work in plastic injection molding, where everything revolves around injection cycles. For auditing and analysis purposes, we need to log all data exactly when the cycle tag updates, regardless of whether the values have changed or not.
Another example is the quality system—data collected by the PLC that we need to log exactly 'when received' (since the PLC sends the data in a burst after a cycle).
We handle this history logging via a tagChange script—triggering on the tag or its timestamp if it's read-only—and we execute it manually using a SQL query into its own database.
As michael said - be careful with Analog deadband. To better see what he's saying about the difference between Analog & Discrete - make a tag that is an expression that just counts up at steady rate. Set it to Analog deadband for history. Make a duplicate tag, but set it to Discrete. Toss both tags on a chart and watch...
I use Discrete for everything as well. Auto/Analog does unexpected things when showing it on a trend. Just set your deadbands correctly and the steps are so small that discrete is practically a smooth curve.
Your tag history is sort of its own philosophy you need to develop to weigh how fine of details you want vs how much storage space you're willing to consume.
Generally bools we do on change unless you want to capture as a batch as specific intervals. Floats we have set into a few buckets for fast, medium, and slow. Something like a pressure reacts quickly so you likely would want it to historize more frequently than say a temperature in a vessel which will move quite slowly.
As others have said, pretty much always discrete deadband. I don't fully understand the why but auto/analog does some weird stuff and when we were trying to deal with it discrete was the answer a while back.
For those confused about the analog style, if you've ever used other historians and heard the term "compression", this is essentially what they're doing. It's not the same as compression like a ZIP/RAR/7Z archive file. They're trying to reduce the number of data points stored by only recording points outside of the deadband. When using discrete mode, this is simple and straightforward. When using analog mode, it gets more complex because the deadband isn't a simple "if the value moves more than 0.1 or 1% or whatever, but instead is based on slope/rate of change". When that slope changes more than the deadband, it records the previous value (not the current value), because that's when the slope/rate of change was enough to trigger a change, but the current value now sets the new standard slope. If the variable is changing at a constant rate/slope, then there's no need to store a new value until that rate of change/slope changes. Essentially when historizing only the starting and ending points of the consistent rate of change/slope needs to be recorded and drawn (you can draw a straight line between the starting and ending points and still be within the specified deadband). Depending on how long this lasted, it could save storing dozens or hundreds of points possibly. It does get confusing, but I suggest reading the math behind it in the link I posted earlier.
This is why even for floats that are setpoints, alarm limits, sequence steps, etc, you always want to use discrete because they're not a continuously changing value like process variables. Otherwise you can use Auto/Analog for process variables (except booleans) and you should see some storage savings (unless you have a super noisy process - in which case your slope would be constantly changing and would cause more problems interpreting data than it solves).
I think the big problem with Analog is that the charts don't KNOW it's analog. So they assume the last datapoint logged is what the value still is, so you get a flatline. Rather than a line continuing at whatever slope it's actually on.. Would love to see Inductive come up with a way to graph it properly.
I agree with you there. When viewing a trend it almost should always use the current value as the last value on the trend. Essentially it would be drawing the roughly correct slope of the line until it falls outside the deadband, then the line might shift slightly once a value is stored, but it shouldn't be significant. This would prevent the flatline of the value (or even if they just showed the line at the current recorded slope would help especially for tags that don't poll that fast).