System Tags are status Tags that Ignition provides about the Client and the Gateway. You cannot create any new Tags in the Client or Gateway folders. The Tag names and folder structure are managed by the Ignition Gateway. However, you can modify the Tags in the Gateway folder to perform alarming, history, and scaling. You cannot modify the Client-scoped System Tags.
Client-scoped Tags provide status information about the client's system. Every individual client is going to have their own values like IP address, hosting name, username, and more.
Gateway-scoped Tags provide status information about the Gateway like alarming, database, throughput, memory usage, performance of the server, and much more.
There are potentially more of these System Tags depending on the modules that you have installed. For example, if the Mobile Module is installed you will see a Mobile folder under the Client and Gateway folders. This will include information about the Client in addition to the Client folder, but only if the client is opened with the mobile module.
Client Tags, as the name implies, are only available for use in Clients. They are scoped at the client level unlike the Gateway Executed Tags. All clients will have the same list of client Tags, however, the actual values are unique and independent for each running Client. In other words, even though client Tags are created in the Designer, each client will create their own instances. This makes them very useful as in-project variables, for passing information between screens, and between other parts of the clients, such as scripting.
Client Tags are a hybrid of memory, expression, and SQL Query Tags, and do not have a scan class. When a client Tag is set to run as an expression or query, a poll rate is specified dictating how often the value should be calculated.
Client Tags support most of the data types that standard Tags do (including datasets), but excluding the array types.
|
The Source Tag Path property of a Derived Tag depicts which Tag the Derived Tag should reference. This is similar to the OPC Item Path on an OPC Tag, except it points to an Ignition Tag.
Aside from editing the Tag from the Designer, the Source Tag Path on a Derived Tag may be modified by writing directly to the SourceTagPath property on the Tag, or using a Tag Binding on a Vision component
Additionally, the SourceTagPath property may be changed through scripting:
#Example of writing to the SourceTagPath attribute via Python Script system.tag.write("Derived Example/Derived Tag.SourceTagPath", "[.]Folder/New Source Tag") |
Instead of a Numeric section, Derived Tags have a Value Derivation section accessible in the Tag Editor. This sections allows you to leverage Expressions when reading from or writing to the source tag, which provides a greater degree of customization than the traditional Numeric scaling settings available to OPC Tags.
Read Expression | Determines what value should appear on the Derived Tag. The current value of the source tag may be referenced with the {source} reference. |
Write Expression | When writing to the Derived Tag, this expression determines what value should be written to the source tag. The current value of the source tag may be referenced with the {source} reference. The raw value passed to the Derived Tag may be referenced with the {value} reference. |
This interface provides an opportunity to scale the written and read value. For example, if the source tag was in fahrenheit, and the derived tag should be celsius, we could use the following expressions:
//Read Expression ({source}-32)*(5/9) //Write Expression {value}*(9/5) + 32 |
When added as a member of a UDT, Derived Tags may reference peer members. Additionally, UDT parameters may be used in the Source Tag Path.