Tag History Max time between records

When specifying a ‘Max time between records’ in a tag’s History the historian does write a new record to the sqlt_data_* table at that interval. However, it writes the value that it last wrote instead of the current value if the change in the current value has not exceed the historical deadband.

I think the historian should write the current value at the ‘Max time between records’ interval. The ‘Max time between records’ setting does not seem to be useful unless it does that. I want to stop trends from flat-lining for long periods when the tag value changes less than the deadband.

That is the purpose of the deadband. If you want to save the historical value that occurs at the interval then you should set your deadband to 0

Then what is the purpose of the ‘Max time between records’ setting if it just causes the same value to be written to the history database?

Setting the deadband to 0 will cause way too many values to be written to the history database, making the the trends slow.

When used, the deadband has to be the only mechanism to move the reference point. If we allow anything else change the reference point then you could wind up in a position where the deadband is never triggered, even though the delta between the current and previous values is greater than the deadband.

Consider the following example, with history running according to your suggestion:
deadband: .1
max time between records: 10

(T = time, V = value)
T00, V: 1.1
T10, V: 1.19
T20, V: 1.28
T30, V: 1.37

Consider the fact that the value delta is greater than the deadband over time, but never between individual “Max Time” records. Thus, the deadband is never triggered. This is a non-deterministic system, and tag history needs to be deterministic.

If the value is flatlined, then you can be sure that the value has not varied greater than the original reference point, and that is far more important than trending at a slightly higher resolution (which can be accomplished anyways, you just need to take performance and scale into account). We’d be sacrificing accuracy for precision.

Thank you for the detailed answer, Luke!

I can see that doing what I suggested would solve one problem and create another.

From the user manual:

“Max Time Between Records
Normally the Tag Historian only stores records when values change. By default, an “unlimited” amount of time can pass between records- if the value doesn’t change, a new row is never inserted in the database. By modifying this setting, it is possible to specify the maximum number of time or scan class execution cycles that can occur before a value is recorded. If the value is set to “execution” mode, the execution count is that of the historical scan class. Since this setting generally leads to more data being stored in the database, it is important to only change this property when necessary.”

Ignition did not always have this setting. Can you tell me why it was added? “…when necessary” just kind of hangs there in that last sentence.

The main reason for this setting is to allow the user to force a data point to occur in every partition (I.E. if you partition monthly, you’d use 30 days for max time between records), even if that tag doesn’t change during that time. Also, this is a simple way to allow users to store a minimum number of records in a given time period to comply with whatever record keeping standards to which they might be adherent.

1 Like