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.