I am trying to understand exactly when my tag values are being stored in my database. With the settings shown below, would the tag values possibly be stored more or less often than 10 seconds?
See if the following pages help your understanding:
... and how data compression works:
I found the tag history was of limited value for many applications and instead I logged process values based on gateway events.
The second link helped me understand it a little better, I just didn't read far enough the first time when I was in the manual. I still do not quite understand it though because when I query the database, I see a few timestamps that are unexpected, based on my understanding of how it works. I am assuming the deadband is still in play, even when the sample mode is set to "periodic"?
Figure 1. Query results with milliseconds cropped off.
I'm not too sure, but you can see in Figure 1 that you have three sequences of timestamps at 10 s intervals. Between 1 and 2 you are missing 688, 698 and 708. Between 2 and 3 you are missing 778. I have no idea why!
IA's documentation is vague on much of this and I gave up on it for applications where I needed records on the hour and, for example, every 15 minutes. I created my own data tables for these as mentioned above.
Where I have used the historian as an easy way to look back at events in a process to see what happened, I set the max time between samples to a value that will ensure that there is at least one record returned in a likely period of interest. This might be once a day or, more likely, at least once per hour. (If a tag value doesn't change for months - a temperature setpoint, for example - there might be no record at all in that data partition.)
1 Like
I can't answer this either, but I know for setpoints I always change the deadband mode to discrete. This essentially disables compression, and might force storage every 10 seconds like you're wanting. It's worth a shot. When deadband mode is in auto, if you look at diagnostics of a tag you'll see information on the last stored value and notice it doesn't always match the current value, but in discrete mode it will.
1 Like
Based on the tag property settings in my first post, I believe that the "deadband mode" and "historical deadband" settings are causing this. If the tag value HAS NOT changed enough (based on the compression algorithm) then it will not store until the "Max Time Between Samples". If the tag value HAS changed enough than it will store at the "Sample Rate". I'm not sure if this is correct, just the way I am understanding it. With all that being said, it does not explain why it stored the same tag value at 718 and 728.
Thank you. I will try this and see if it helps. I might also try adjusting the "Historical Deadband" value and see what the storage looks like.
Yes, your understanding is correct, the data missing between 678 and 718 is because of the deadband setting, the value change is not enough to be recorded. the data is recorded at 718 is just because the max time is reached, and the value is 0.08.
And why 728 is recorded with a same value 0.08, actually this is because there is a real change at 738, the ignition will insert a previous value of 0.08 at 728. (This is not mentioned in Ignition user manual)
You can verify this by create a memory tag with float data, enable the history and set same history properties. you can manually change the value and check the record in DB table at same time. You can understand what I mean.
it is more probably that the value is kept as 0.08 no change during 678 to 728, the 718 is recorded just because the max time reached, and 728 is recorded with 0.08 is just becasue there is a real change at 738, Ignition will amend a previous no change data at 728.
in another word, if there is no change at 738, the 728 value will not be recorded.
You should look at the docs for Deadband Style. When style is "Analog", Ignition's storage algorithm holds the most recent point in memory, waiting to see if it is needed to mark an inflection point on the analog trendline. In other words, points can be recorded late, based upon following data.
When style is "Discrete", the recordings strictly follow the deadband and min/max time settings.
When style is "Auto", the tag's datatype determines the behavior: floating point values are treated with the analog style, and other types use the discrete style.
All of this is documented.
1 Like
YES！ Thank you for helping me to find out why the data is always recored late in analog dead band style, it is documented in that example in the manual.
This afternoon, i created a memory tag with float datatype, enable the history and apply different history properties, and then manually change the value to test how tag history works. I found that in analog style, the new value seems not recorded immediatly, but they are recorded in next cycle, which is totally different with discrete style. Now I totally understand.
1 Like
