Tag Properties
Tags are points of data and may have static values or dynamic values that come from an OPC address, an Expression, or a SQL query. The values can be used on screens, in Transaction Groups, and more. Additionally, Tags offer a core set of features above and beyond simple values, such as the scaling, alarming, meta information, and history facilities.
Depending on the specific type of Tag, even more options are available. In general, Tags provide a common interface for tying together many types of data in Ignition.
Historical Tag data is stored in the database connection associated with the selected history Tag provider. Ignition creates and manages several tables within the Tag database that the historian uses to not only store your data, but also make it easily available within your Ignition projects.
There are several types of Tags that are similar in their configurations, but differ in how the value is generated. The different types of Tags are: OPC Tags, Memory Tags, Query Tags, Complex Tags, System Tags, and Client Tags.
Tag Configuration in the Designer
To configure a Tag, right-click the Tag, then from the popup menu go to New Tag and select the type of Tag you want to configure. (The example below is an OPC Tag). The Tag Editor window is displayed and you can now set the properties for that Tag. The Tag Editor window has the following sections depending on the type of Tag you are creating: General, Numeric, Metadata, Permissions, History, Alarming, SQL Query, Expression, and Tag Events.
The description for the each of the Tag properties in each section is described next.
General Properties
Properties common to most Tags are as follows:
Property |
Binding |
Name Description |
Name |
Name |
How the Tag will be presented and referenced in the system. The Tag path will be the provider, the folder structure, and this name. |
Value |
Value |
The value of the Tag. Can only be modified if the Tag allows value writing and the user has sufficient privileges. |
Data Type |
Datatype |
The type of the value. It is important that this be set as correctly as possible with regards to the Tag's underlying data source. The Tags system will attempt to coerce any raw incoming value (for example, from OPC or a SQL query) into the desired type. |
Enabled |
Enabled |
Whether the Tag will be evaluated by the scan class. If false, the Tag will still be present, but will have a bad quality. |
Access Rights |
AccessRights |
Specifies the access level allowed to the Tag: Read/Write, Read only, or Custom. If Custom, the Tag will use the permission settings. |
Scan Class |
ScanClass |
The scan class that will execute the Tag. The scan class dictates the rate and conditions on which the Tag will be evaluated. |
Additional Properties - OPC Tags |
||
OPC Server |
OPCServer |
The server against which to subscribe the data point. |
OPC Item Path |
OPCItemPath |
The path to subscribe to on the server. The point will be subscribed at the rate dictated by the scan class. |
Additional Properties - Tag in External Providers |
||
Driver |
DriverName |
The name of the Ignition Gateway that will be responsible for the execution of the Tag. All other Gateways will monitor the value. |
Numeric Properties
The Numeric properties are available to OPC, DB, and Client Tags whose data types are numeric.
Property |
Binding |
Name Description |
Scale mode |
ScaleMode |
If and how the Tag value will be scaled between the source, and what is reported for the Tag. |
Raw Lo |
RawLow |
Start of the "raw" value range. |
Raw Hi |
RawHigh |
End of the "raw" value range. |
Scaled Lo |
ScaledLow |
Start of "scaled" value range. Raw low will map to Scaled low for the Tag. |
Scaled Hi |
ScaledHigh |
End of "scaled" value range. Raw high will map to Scaled high for the tag. |
Clamp mode |
ClampMode |
How values that fall outside of the ranges will be treated. "Clamped" values will be adjusted to the low/high scaled value as appropriate. |
Scale Factor |
ScaleFactor |
For single parameter modes (currently only Exponential Filter), the factor parameter for the equation. |
Deadband |
Deadband |
A floating point value used to prevent unnecessary updates for Tags whose values "float" by small amounts. |
Deadband Mode |
DeadbandMode |
There are two modes to choose from: Absolute or Percent. |
Metadata Properties
The Metadata properties provide informational properties for a Tag. The values of these fields can be read and modified through scripting, or bound to properties such as Format, Engineering Units, Tooltips, Documentation, and more.
Property |
Binding |
Name Description |
Format String |
FormatString |
How the value should be formatted when converted to a string (only applies to numerical data types). |
Eng Unit |
EngUnit |
The engineering units of the value. |
Engineering Limits Low |
EngLow |
The lowest expected value of the Tag. |
Engineering Limits High |
EngHigh |
The highest expected value of the Tag. |
Engineering Limit Enforcement |
EngLimitMode |
Dictates how the engineering range should be enforced on the Tag. If not "none", the Tag will change to bad quality ("limit exceeded"), when the value exceeds the specified range. |
Tooltip |
Tooltip |
The tooltip provides a hint to visual components as to what should be displayed when the user hovers their mouse cursor over the component that is being driven by the value of this Tag. |
Documentation |
Documentation |
A freeform text property for information about the Tag. |
Permissions Properties
By default, a Tag's Access Rights property is set to Read/Write, which means that any user can read the value of the Tag and write to the Tag. Read-only mode makes the Tag non-writeable for all users. Custom mode allows the Tag to assign Read/Write or Read-Only privileges to individual roles. Any roles not explicitly granted a right by using the Custom Permissions Editor will not be able to read the Tag's value or write to the Tag.
Tag's Access Writes
Make sure your Tag's Access Rights (in the General section of the Tag Editor window) is set to Custom for these permissions to have an effect. Users must have at least one role in this list in order to have access to the Tag. If a user has more than one of the roles in the list, the role with the highest privilege will apply.
History Properties
The properties on the History tab of the Tag Editor window specify if and how the Tag's history will be stored in the Tags Historian system.
Property |
Binding Name |
Description |
Store History |
HistoryEnabled |
Whether the Tag will report its history to the Tags Historian system. |
History Provider |
PrimaryHistoryProvider |
Which Tag Historian data store the Tag will target. A particular Tag can only target one history store. For more information, refer to Historian Providers in Configuring Tag Historian. |
Historical Scanclass |
HistoricalScanclass |
The scan class to use to evaluate Tag history. This allows the Tag's history to be stored at a slower rate than the status is updated at. |
Historical Deadband |
HistoricalDeadband |
A deadband that applies only to historical evaluation. |
Max Time between Records |
HistoryMaxAgeMode / HistoryMaxAge |
The maximum amount of time that can pass before a new record is logged for the Tag. To learn more, refer to Max Time Between Records in Configuring Tag Historian. |
Historical Deadband Mode |
DeadbandMode |
There are two modes to choose from: Absolute or Percent. |
Timestamp Source |
HistoryTimestampSource |
Which timestamp is used for the value of the Tag. Refer to Timestamp Source in Configuring Tag Historian. |
Value Mode |
InterpolationMode |
Value Mode dictates the type of value that the Tag represents, how the deadband will apply to the values, and how interpolation should be performed when querying.
To learn more about Analog and Discrete values, refer to Value Mode in Configuring Tag Historian. |
Alarming Properties
Tags have the ability to define any number of alarms. Each alarm is a condition that will be evaluated when the value of the Tag changes. When the condition becomes true, the alarm is said to be active. When it becomes false, the alarm is said to be cleared.
Here is a list of Alarm Properties that you can edit or bind when creating or editing a Tag.
Property Name |
Description |
Main |
|
Alarm Name |
Each alarm has it's own name. For example, if the Tag is representing a level, the alarm name might be High Level. |
Enabled |
This boolean determines whether or not the alarm will be evaluated. A disabled alarm's condition will not be evaluated, and thus will not generate any alarm events. |
Priority |
An alarm's priority can affect how is appears in an Alarm Status table, or can affect how it is escalated through a pipeline. The priorities, which can be referenced by their integer equivalent in scripts and expressions, are: Diagnostic [0], Low [1], Medium [2], High [3], Critical [4]. |
Timestamp Source |
Chooses where the timestamp for the alarm event should come from: the system time of when the event was generated, or the timestamp of the value that tripped the event. |
Display Path |
This is a string value that will be used to display the alarm to operators. If this is blank, the operator will see the path to the Tag instead. Please use the forward-slash character to separate hierarchy levels in this path, for example: East Area/Boilers/Boiler5 |
Ack Mode |
Dictates how acknowledgement works for the alarm.
|
Notes |
A place for any free-form documentation about the alarm that can be displayed to operators. |
Ack Notes Required |
If this setting is true, the operators will be unable to acknowledge this alarm without entering some notes. |
Shelving Allowed |
If this setting is true, the shelving feature will be unavailable for this alarm. |
Alarm Mode Settings |
|
Mode |
This setting controls what condition this alarm is evaluating. The available modes are as follows:
|
Setpoint |
The value used to initiate an alarm.
|
Deadbands and Time Delays |
|
Deadband |
The value for the deadband, interpreted according to the Deadband mode. Note that all alarms are only evaluated after the Tag's value changes, which means that the Tag's own deadband will be considered first. When the deadband is positive, an active alarm condition needs to clear its setpoint(s) by the amount of the deadband for the alarm to clear. For example, suppose you had a Between Setpoints alarm with a low setpoint of 50 and a high setpoint of 70, and with a deadband of 2. The alarm will go active if the value is between 50 and 70, but will only clear if the value falls below 48 or rises above 72. |
Deadband Mode |
Defines how the deadband value is used.
|
Active Delay |
The time, in seconds, before the alarm will be considered active after the alarm's condition becomes true. Also known as a "rising edge time deadband." |
Clear Delay |
The time, in seconds, before an active alarm will be considered clear after the alarm's condition becomes false. Also known as a "falling edge time deadband." |
Notification |
|
Active Pipeline |
The name of an alarm notification pipeline to put this alarm into when it becomes active in order to send out active alarm messages. Many alarms may share a single pipeline. |
Clear Pipeline |
The name of an alarm notification pipeline to put this alarm into when it becomes cleared in order to send out cleared messages. |
Ack Pipeline |
The name of the alarm notification pipeline to put this alarm into when the alarm has been acknowledged. |
Email Notification Properties |
|
Custom Subject |
A string that will be used as the subject line of an email notification message. If blank, the message settings defined on the notification block that sent the email out will be used instead. |
Custom Message |
A string that will be used as the body of this alarm's email notification message. If blank, the message settings defined on the notification block that sent the email out will be used instead. |
SMS Notification Properties |
|
Custom Message |
If specified, will be used for the SMS message. If blank, the message defined in the notification block will be used. |
Associated Data |
|
User Defined 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. |
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 configured the binding to your liking, click on the Back button.
Expression/SQL Properties
DBTags have the ability to use an expression or a SQL query as their value instead of an OPC item path. This can be used to select information from the database or create your own formulas to manipulate other Tag values.
Expression Properties
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 Properties
In SQL 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 be inserted as literal text in the query before being sent to the database.
Tag Events
Each Tag has the option to have Tag Event Scripts on it. When you edit a Tag, you can navigate to the Tag Events section to see a list of all of the Tag scripts. You can then select which event you would like to write a script for. You can even write a script for multiple events if you like.
Similar Topics ...