Configuring Tag History

Configuring Tag History

Watch the video

You can log historical data by enabling history on individual tags. Once enabled, tag values are stored using a configured historian provider. Depending on the provider, data may be routed through the Store and Forward system or written directly to disk.

When history is enabled, each record includes a millisecond-resolution timestamp, tag quality, and the original value. Values are stored based on the tag’s history settings, such as deadband and sampling mode. Some providers also track execution metadata to help detect stale values.

Enable History on a Tag

History must be enabled on a tag in the Tag Editor before you can begin logging any values.

note

Dataset-type tags are not supported by the historian system.

1. In the Tag Browser, select one or more tags.
2. Right-click the selection and choose Edit Tag .
3. In the Tag Editor, scroll to the History section or select it from the left panel.
4. Enable the History Enabled property.
5. Select a Storage Provider.
6. Set the Sample Mode to Tag Group.
7. Choose a Historical Tag Group, such as Default Historical.
8. Click OK to apply your changes.

Tags with history enabled display the History icon in the Tag Browser.

note

To record history for members of a UDT, edit the UDT definition and enable history on individual members. These settings will apply to all UDT instances.

Tag History Configuration

Sample Mode

This setting controls when tag values are evaluated for storage.

• On Change: Stores a value when the tag's value changes.
• Periodic: Stores a value at fixed intervals based on the Sample Rate.
• Tag Group: Uses the execution rate of the selected Historical Tag Group.

Historical Tag Group

The Historical Tag Group setting is available when Sample Mode is set to Tag Group. It determines how often the historian checks the tag for changes that should be stored. This property uses a configured Tag Group, which defines an execution rate.

The evaluation frequency should align with or be slower than the tag's primary Tag Group to avoid redundant checks. For example, if the tag executes at a 1,000ms rate and the Historical Tag Group runs at 500ms, the historian will evaluate the tag twice per update. This can result in unnecessary processing and potential storage of duplicate values.

Choosing a Historical Tag Group with the right execution rate helps optimize performance and ensures storage integrity.

Max and Min Time Between Samples

These settings define how often values are stored when using On Change sampling. Normally, values are only stored when a change occurs that exceeds the deadband. If the tag value remains the same, no new records are inserted, regardless of how much time passes.

• Max Time Between Samples sets the maximum number of Tag Group executions that can pass before a value is forcibly stored, even if it hasn’t changed. This ensures you don’t go too long without a data point.
• Min Time Between Samples prevents values from being stored more frequently than a set interval, even if changes exceed the deadband.

note

Max Time Between Samples must be at least 1000 milliseconds.

These settings are useful for maintaining consistent records in scenarios where tag values may be static for long periods or fluctuating too rapidly. For example, setting Max Time Between Samples to 5 and using a Tag Group that runs every 1 second will guarantee a record is stored at least every 5 seconds, regardless of change.

Use these options carefully to balance data integrity with database storage size.

Deadband Discrete Style and Analog Compression

This section describes the Deadband Style property options Auto, Analog, and Discrete because it may not be immediately clear how the deadband value is used differently depending on whether the tag is configured as a Discrete tag or as an Analog tag. Discrete values are more straightforward, registering a change any time the value moves +/- the specified amount from the last stored value. However, with Analog tags the deadband value is used more as a compression threshold, in an algorithm similar to that employed in other Historian packages. It is a modified version of the 'Sliding Window' algorithm. The following examples show the process in action, comparing a raw value trend to a "compressed" trend.

Discrete

Storage: The deadband will be applied directly to the value. That is, a new value (V1) will only be stored when:

|V1 - V0| >= Deadband

Interpolation: The value will not be interpolated. The value returned will be the previous known value, up until the point at which the next value was recorded.

Analog

Storage: Every time the tag's value changes, this method will calculate upper and lower slope values. These slope values are stored in memory, and are ultimately used to determine when a new value is stored. The calculations used are listed below:

Upper Slope = ((NewValue + Deadband) - PreviousValue) / (NewTimestamp - PreviousTimestamp)

Lower Slope = ((NewValue - Deadband) - PreviousValue) / (NewTimestamp - PreviousTimestamp)

The algorithm will only store new values under the following conditions:

• The system always stores the first value on the tag when using the method, since the subsequent values will need an initial value to calculate slope from.
• If the newly calculated upper slope is less than the previously calculated lower slope value, the system will store the new value.
• If the newly calculated lower slope is greater than the previously calculated upper slope value, the system will store the new value.
• The system always stores a value when the quality on the tag changes.

In cases where a new value isn't stored, the system will compare the newly calculated slope values to the previously calculated values:

• If the new upper slope is less than the previous upper slope, then the new upper slope is used for future comparisons.
• If the new lower slope is greater than the previous lower slope, then the new lower slope is used for future comparisons.

Interpolation: The value will be interpolated linearly between the last stored value and the next value. For example, if the value at Time0 was 1, and the value at Time2 is 3, selecting Time1 will return 2.

Auto

This setting will automatically pick either Analog or Discrete, based on the data type of the tag. Auto is the default Deadband Style when initially configuring tag history.

• If the data type of the tag is set to a float or double, then Auto will use the Analog Style.
• If the data type of the tag is any other type, then the Discrete style will be used.

Deadband Settings

In addition to the Deadband Style, your tag history settings also include the Deadband Mode and Historical Deadband properties.

• Deadband Mode is set to Absolute by default. If changed to Percent, the deadband is calculated as a percentage of the tag’s engineering unit span.
• Historical Deadband applies specifically to historical data evaluation.
• If Deadband Mode is set to Off, all values are stored when the timestamp changes.

Interpolated Values

When querying historical data, Ignition may interpolate values to fill gaps where no raw data exists in a given time window. Interpolation helps maintain consistent charting, reporting, and aggregation behavior when data is sparse or unevenly distributed.

Interpolation only occurs when:

• The selected Aggregation Mode supports it
• Avoid Interpolation is disabled
• No raw values exist in a given time window

Interpolation Example

In the example below, a tag history query from 1:30pm to 5:30pm is executed using 60-minute intervals. The query returns three windows with data and one empty window.

• Time Window 1 (1:30–2:30): 0.04, 5.6, 45.6, 3.45, 96.45
• Time Window 2 (2:30–3:30): no data
• Time Window 3 (3:30–4:30): 9.68, 5.6
• Time Window 4 (4:30–5:30): 30.04, 9.6, 23.6, 76.49, 2.54

With SimpleAverage selected as the Aggregation Mode, the system averages the raw values in each window:

(0.04 + 5.6 + 45.6 + 3.45 + 96.45) / 5 = **30.23**

Since there are no values for Window 2, Ignition interpolates using the last value of Window 1 (96.45) and the first value of Window 3 (9.68):

The resulting linear interpolation at 3:30pm is 12.09. This is calculated by drawing a line between the endpoints and marking the value at the missing timestamp:

Unless the Average Aggregation Mode is used, all other modes will use the same interpolated value of 12.09.

Time-Weighted Average Interpolation

The Average Aggregation Mode uses a time-weighted formula instead of a simple arithmetic mean. This includes both raw and interpolated values with durations factored in.

Time-weighted average formula:

Average = (0.5 × abs(currVal − prevVal) × timediff) + (timediff × min(currVal, prevVal))

Using the earlier example:

prevVal = 96.45  
currVal = 60.29  
timediff = 2,699,999 ms

(0.5 × abs(60.29 − 96.45) × 2,699,999) + (2,699,999 × 60.29) = 211,606,751.63

note

To calculate the interpolated value of 60.29 (used above), Ignition uses a retValue interpolation formula:

retValue = A + ((B − A) × ((ts − Ats) / (Bts − Ats)))

Where:

• A = 96.45
• B = 9.68
• Bts − Ats = 3:33pm − 1:45pm = 108 minutes
• ts − Ats = 2:30pm − 1:45pm = 45 minutes

96.45 + ((9.68 − 96.45) × (45 / 108)) = 60.29

Preceding Window Calculation

To include raw time-weighted values from 1:33pm to 1:45pm:

note

Time	Value
1:33	0.04
1:36	5.6
1:39	45.6
1:42	3.45
1:45	96.45

Sub-intervals:

• 1:33 to 1:36:
  (0.5 × abs(5.6 − 0.04) × 179,999) + (179,999 × 0.04) = 507,597.18

• 1:36 to 1:39:
  (0.5 × abs(45.6 − 5.6) × 179,999) + (179,999 × 5.6) = 4,607,974.4

• 1:39 to 1:42:
  (0.5 × abs(3.45 − 45.6) × 179,999) + (179,999 × 3.45) = 4,414,475.47

• 1:42 to 1:45:
  (0.5 × abs(96.45 − 3.45) × 179,999) + (179,999 × 3.45) = 8,990,950.05

Subtotal = 18,520,997.10

Add the two totals:

(211,606,751.63 + 18,520,997.10) / 3,419,999 = 67.29

Interpolated Average for Empty Window

Now using Average mode for the empty window (2:30–3:30):

prevVal = 60.29
currVal = 12.09
timediff = 3,599,999 ms

(0.5 × abs(12.09 − 60.29) × 3,599,999) + (3,599,999 × 12.09) = 130,283,963.81

Divide by window duration:

130,283,963.81 / 3,599,999 = 36.19

Seeded Values

Seeded values (also called boundary values) are additional values retrieved just outside the query range—one before the start time and one after the end time. These values support interpolation and certain aggregation modes, especially when data is sparse at the query boundaries.

• The pre-query seed appears just before the query's start time and is usually the first row in the result set.
• The post-query seed appears just after the query's end time and is often used to complete an interpolation window.

These boundary values are automatically included unless the query is configured to exclude them. To omit seeded values, you must meet all of the following:

• Interpolation must be disabled (either by tag mode or query configuration)
• Deadband Style must be set to Discrete
• The query must include noInterpolation=True
• The query must include includeBoundingValues=False

Seeded values are not returned when using raw data queries, except in one special case using scripting.

Pre-query Seed Value

The pre-query seed is a value retrieved immediately before the start time of the query. This value is used for interpolation and often appears as the first result in the dataset. When interpolation is enabled and the result set is not raw, this value is included by default.

An exception exists when using system.tag.queryTagHistory with returnSize=-1 (for raw data) and includeBoundingValues=True. In that case, the pre-query seed is still returned to allow proper interpolation on the client side.

Post-query Seed Value

The post-query seed is a value recorded just after the query end time. It is included when interpolation is enabled and helps calculate the last interpolated value for the final time window.

Seeded post-query values are not returned if the tag uses a Discrete deadband style. Tags with Analog deadbands or other interpolation-friendly settings will include this value.

When querying for local tags and the query range ends near or at the present time, Ignition may use the current tag value as the post-query seed, rather than fetching the last database record. This improves responsiveness when charting live data.

note

If a value appears outside the requested range, it is usually a seeded value. This often occurs when:

• The query window is very short and contains no data
• The query window ends in the future and no values exist yet

Raw Data Queries

In most cases, queries returned by tag history will apply some form of aggregation. However, it is possible to get a "raw data query", which is a result set that contains only values that were recorded: meaning no aggregation or interpolation is applied to the results. A raw data query can be obtained by using one of the following options:

• Set the Sample Mode on Vision Tag History bindings to On Change
• Setting the returnSize parameter on system.tag.queryTagHistory or system.tag.queryTagCalculations to -1.
  

note

Be aware that if a tag is storing history using the Analog style, the returned dataset will include post-query seed values.

• Setting the Query Mode on Perspective Tag History bindings to AsStored