Value Mode

The value mode, analog or discrete, dictates the type of value that the tag represents, and will affect how the deadband is applied to values, and how interpolation should be performed when querying. Interpolation is the method in which the Tag Historian query system generates values for a tag when the desired time does not fall directly on a sample timestamp.

Discrete

• Storage - The deadband will be applied directly to the value. That is, a new value (V₁) will only be stored when: |V₁-V₀| >= 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 - The deadband is used to form a corridor along the trajectory of the value. A new value is only stored when it falls outside the previous corridor. When this occurs, the trajectory is recalculated, and a new corridor formed. See below for an example.

• Interpolation - The value will be interpolated linearly between the last value and the next value. For example, if the value at Time₀ was 1, and the value at Time₂ is 3, selecting Time₁ will return 2.

Max Time Between Records

Normally 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 scan class execution cycles that can occur before a value is recorded. Setting the value to 1, for example, would cause the tag value to be inserted each execution, even if it has not changed. Given the amount of extra data in the database that this would lead to, it's important to only change this property when necessary.

Timestamp Source

When a Tag executes, there are two possible timestamps that can be observed: the time associated with the data, and the time that the tag was evaluated. The first case is generally only interesting when the value is provided by an OPC server. In most cases, the time provided by OPC, which in Ignition is referred to as the "Value" time, will be very close to the system time. Some servers, however, either due to their location or how they function (history playback, for example), will provide times that are very different than the current time.

It is generally desirable to store the System time, as it is the time that the value was actually observed by the system, and it creates a uniform timeframe for all realtime data. However, in the later case, it is necessary to store the time provided by the OPC server. Using the Value timestamp source has several consequences: the system is no longer able to validate the tag quality against the scan class' execution, and tag value interpolation will behave differently.

The validation of the scan class execution is generally not a concern when recording historical playback data. Interpolation only occurs when the value mode is Analog, and when there is not a value for every time window. Using System time, the value is only interpolated during the last "scan class execution window", that is, one scan class timeframe before the next value. Using Value time, however, the value is interpolated for the entire time between two data points.

The Deadband, and Analog Compression

As described above, the deadband value is used differently depending on whether the tag is configured as a Discrete tag, or an Analog tag. Its use with discrete values is straight forward, registered a change any time the value moves +/- the specified amount from the last stored value. With Analog tags, however, 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. Its behavior may not be immediately clear, so the following images show the process in action, comparing a raw value trend to a "compressed" trend.

In this image, an analog value has been stored. The graph has been zoomed in to show detail; the value changes often and ranges over time +/- 10 points from around 1490.0. The compressed value was stored using a deadband value of 1.0, which is only about .06% of the raw value, or about 5% of the effective range. The raw value was stored using the Analog tag mode, but with a deadband of 0.0. While not exactly pertinent to the explanation of the algorithm, it is worth noting that the data size of the compressed value, in this instance, was 54% less than that of the raw value.

By looking at one specific sequence, we can see how the algorithm works:

The sequence starts with the second stored compressed value on the chart.

1. A value is stored. No further action is taken.

2. The next value arrives. A line is made through the value, with the size of the specified deadband value. A line is projected from the last stored value to the upper (line U1), and lower (line L1), bounds of this new value line. This establishes the initial corridor.

3. A new value arrives. The same procedure is taken, and new lines are created. However, only lines that are more restrictive than the previous are used. In this case, that means only line U2, the new upper line.

4. Another value arrives, causing a new lower line (L3) to be used.

5. Finally, a value arrives that falls outside of our corridor. The last received value (value 4) is stored, and a the process is started again from that point.

Binding

Many alarm properties are bindable, which means they can be bound to other tags in the system, or expressions. For example, you might bind the enabled property to another tag which represents whether or not your process is running, thereby disabling the alarm when production is stopped. Or, you might bind the setpoint of an alarm to a tag that operators can manipulate, thereby letting the setpoint be changed at runtime.

To bind a tag, simply click on the binding icon ( ), and the binding UI will slide in from the right. From here you can select the binding type (No Binding, Tag, Expression, or UDT Parameter, if applicable). Note that the expression can reference many useful values such as the tag's value and other settings of the alarm. When you've configured the binding to your liking, click on the Back button.

Associated Data

Associated data are custom alarm properties that can be added to any alarm. These properties will often be bound to other tags that represent associated contextual data that may be related to the alarm. A snapshot of the values of these properties will be taken when the alarm becomes active. These values will be attached to the alarm event as it moves through the rest of the alarming system, meaning that the values will be available from the alarm status system, the alarm journal system, and in the alarm notification system.

Main Alarm Settings

Alarm Mode Settings

Deadbands and Time Delays

Notification Settings

Email Notification Settings

Expression

In expression mode, the tag can use all of the features available in the expression language. It can refer to other tags, and use operators and functions to calculate a value for the tag.

SQL Query

In this mode, the tag's value will be the result of the specified SQL query. The query can be any valid query, but should result in only one value. Note that insert and update queries can be used, and will often result in an integer value, so the tag's data type should be set accordingly.

Like SQL Query bindings in the Vision module, the queries for tags can refer to other tag values. The values of referenced tags will inserted as literal text in the query before being sent to the database.