Search

User Manual

GETTING STARTED


MODULES AND PLATFORM


APPENDIX


TUTORIALS & HELPFUL TRICKS


STRATEGIC PARTNER LINKS

Sepasoft - MES Modules
Cirrus Link - MQTT Modules

RESOURCES

Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples

ALL USER MANUAL VERSIONS

Ignition 8.1
Ignition 7.9
Ignition 7.8

Deprecated Pages

Employees

Sign In

Skip to end of metadata
Go to start of metadata


Logging data is easy with Tag Historian. Once you have a database connection, all you do is set the Tags to store history and Ignition takes care of the work. Ignition creates the tables, logs the data, and maintains the database.

The historical Tag values pass through the store-and-forward engine before ultimately being stored in the database connection associated with the historian provider. The data is stored according to its datatype directly to a table in the SQL database, along with its quality and a millisecond resolution time stamp. The data is only stored on-change, according to the value mode and deadband settings on each Tag, thereby avoiding duplicate and unnecessary data storage.The storage of scan class execution statistics ensures the integrity of the data.

Tag Configuration

The first step to storing historical data is to configure Tags to record values. This is done from the History section of the Tag Editor in the Designer. Select the History Enabled property to turn on history. The properties include an Historical Tag group that will be used to check for new values. Once values surpass the specified deadband, they are reported to the history system, which then places them in the proper store and forward engine. Complete information on the History properties (and all properties in the Tag Editor), can be found on the Tag Properties Table

On this page ...

IULocgo


Configuring Tag History

Sample Mode

The Sample Mode setting determines how often a historical record should be collected.

  • On Change - Collects a record whenever the value on the Tag changes.
  • Periodic - Collects a record based on the Sample Rate and Sample Rate Units properties.
  • Tag Group - Collects a record based on the Tag Group specified under the Historical Tag Group property.

Historical Tag Group

Historical Tag Group setting shows up with Sample Mode is set to Tag Group.  Historical Tag Group setting determines how often to record the value on the Tag. It uses the same Tag Groups that dictate how often your Tags should execute. Typically, the Historical Tag Group should execute at the same rate as the Tag's Tag Group or slower: if a Tag's Tag Group is set to update at a 1,000ms rate, but the Historical Tag Group is set to a Tag Group that runs at 500ms rate, then the Tag History system will be checking the Tag's value twice between normal value changes, which is unnecessary. 

Max and Min Time Between Samples

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 these settings, 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.

Deadband and Analog Compression

The deadband value is used differently depending on whether the Tag is configured as a Discrete Tag or as an Analog Tag. Its use with discrete values is straightforward, registering 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.

The Deadband Style property sets the: Auto, Analog, or Discrete.

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 - 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 Time0 was 1, and the value at Time2 is 3, selecting Time1 will return 2.

Auto

  • The setting will automatically pick either Analog or Discrete, based on the data type of the Tag. 
    • 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.

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.

Seeded Values

Tag history queries sometimes use seeded values (occasionally called "Boundary Values"). When retrieving tag history data, the system will also retrieve values just outside of the query range (before the start time, after the end time), and include them in the returned result set. They're generally used for interpolation purposes. If the tag is storing history with an Analog Value Mode, or "Prevent Interpolation" is enabled on the calling query, then these seeded values will not be included.

Pre-Query Seed Value

These are a single value taken from just before the start of the query range. The value and timestamp for this value is typically the first row in the resulting query. Pre-query seed values are always included when not using a raw data query

An exception to this rule is can be found with the system.tag.queryTagHistory function. Setting includingBoundingValues argument to True and returnSize to -1 will return a raw data query with a pre-query seed value. 

Post-Query Seed Value

These extra values are added to the end of the result set, representing the next data point after the query range. Post-query seed values are only included when interpolation is requested/enabled for the query. Thus, values stored with a Discrete deadband style will not include post-query seed values in the query results. 

If the system knows the query is retrieving records for a tag on the local system, this value will be determined by the current tag's value instead of retrieving the last recorded value in the database. The current tag's value is also used in cases where the time range extends to the present time. 

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:



Log Tag History Data

Note: Dataset type tags are not supported by the Tag History system. 
Do the following steps to log history data for your Tags:

  1. In the Tag Browser, select one or more Tags. For example, we selected several Sine Tags in the Sine folder.
  2. Right-click on the selected Tags, and then select Edit Tag .
    The Tag Editor window is displayed. Here, you can edit the Tag and change the name, data type, scaling options, metadata, permissions, history, and alarming.


     
  3. Scroll down to the History section of the Tag Editor. Select the History Enabled check box. 
  4. Choose a database (for example, MySQL) from the Storage Provider dropdown.
  5. Set the Sample Mode to Tag Group.
  6. Set the Historical Tag Group to Default Historical.

     
     
  7. Click OK.  Now look in the Tag Browser. To the right of each Sine Tag that is storing history, a History  icon appears letting you know it is set up.



    If you were to look in your database, you can see all the tables and data Ignition has created for you.

Setting a UDT to Log History Data

You can set a UDT to log history data, then all the instances of that UDT will log data without having to edit the individual instances.

  1. In the Tag browser, right-click on the UDT (for example, a Motor UDT) and select Edit Tag .
    The Tag Editor is displayed. 

  2. In Tag Editor, click a Tag (for example, the AMPS Tag). Scroll down to the History section.

  3. Set the following properties in the Tag Editor:
    History Enabled: true
    Storage Provider: MSSQL
    Sample Mode: Tag Group
    Historical Tag Group: Default Historical



  4. Click Apply. 

  5. Next, select the HOA Tag. 

  6. Set the following properties in the Tag Editor:
    History Enabled: true
    Storage Provider: MSSQL
    Sample Mode: Tag Group
    Historical Tag Group: Default Historical

  7. Click OK to save the changes to the UDT. Now every motor instance automatically starts logging data.



IULocgo


Add History to Tags in UDT





  • No labels