Automated Tag Configuration
Any parameter(*) of a tag can be configured using an expression rather than a static value. This is an extremely powerful feature that you can use to create tags that configure themselves based on where they are placed in the application. Also use it for tags that rely on data from the remote device for their configuration.
(*) The name parameter works differently. An expression here can be used to enable or disable the tag, but cannot change the name.
If you have created a tag as a child of another tag, then you have seen this feature in action. The Area field of every new tag will copy the parent tag's area unless you apply an override to set a new value. If you move or copy a tag to a new parent, its area field will change to match the new parent. The expressions described here are most effective when used in parent-child tag structures, where they can use information stored in an ancestor.
When using expressions for parameters, it is up to you to ensure that the result is valid and that it makes sense for the parameter. For example, an I/O address of either INVALID or "Hello World" is unlikely to produce a desired result.
Before writing your first parameter expressions, review the notes in the chapter, Expressions. In particular, take note of the advice in the topic, Keep the Else's under control !
Identify Parameters with Expressions:
- Parameter fields that contain expressions can be identified by their blue shading.
- If you override an expression with a new value, the field will have a yellow shading.
"EU43y4gag", in this application, is the key for a parameterized phrase:
"Primary pump in the %0 region".
"EU43y4gag" will not exist as a key in your application.
The context menu that appears when you right-click on a tag's configuration field will vary according to what the field is and how it was created.
Create, Edit, Remove, or Override an Expression
For all of the these actions, right-click on the parameter in the tag's configuration dialog. Your choices will vary depending on whether you add the expression to the name parameter (start conditions only), area parameter (which can inherit from its parent), and whether the tag is part of a user-defined type (where changes are considered overrides).
(1) "Reset to Default", seen in all the following examples, is not about expressions but rather for resetting a parameter to its default value if there was one. For example: in a driver tag, the port configuration defaults to [*Port] (ancestor relative path) but you might have changed it to absolute path. "Reset to Default" gives you an easy way to change it back.
(2) The ability to right-click on a parameter to add an expression does not apply to parameters that provide the options Constant - Expression - Tag. For those, use the tools provided instead of the right-click menu.
Name field.
Add or remove start conditions
Other fields, with code to override (child tags of a user-defined type)
Inherit from parent (Area parameter only)
Add or remove override
The Tag Parameter Expression dialog includes the option "Optimize to only evaluate at tag initialization." that is enabled by default. With this setting enabled, the expression is an optimized expression. That means that the value is only evaluated when a tag starts (or restarts). This is optimal because it is efficient. Optimized applications tend to be more stable and make the best use of your resources.
If this setting is disabled, the expression becomes a non-optimized expression.
Non-optimized tag expressions re-evaluate whenever any of the parameters used in the expression change. Each time they do so, all child tags are also re-evaluated. This is primarily used for parameters that use information from equipment that isn't available until after initialization.
Do not deselect the optimization option unless there is a clear need to do so.
When optimization is left enabled:
- The expression will be evaluated only when the tag is initializes. That includes:
- When the application starts
- The tag was just created
- You've modified the tag in the tag browser
- The expression will not be re-evaluated during normal operations.
- Your selection of functions is limited to those that can be evaluated in script mode.
When optimization is disabled:
- The expression will be re-evaluated whenever any of the parameters used in the expression change.
- When a parameter changes, this tag and all of its child tags will restart, slowing the application temporarily and increasing the load on the CPU.
- Each non-optimized tag expression requires extra RAM, roughly equivalent to half that required for a typical tag.
- Your selection of functions is limited to functions that can be evaluated in both script and steady-state.
Misuse of non-optimized tag expressions can have undesirable side-effects and can result in unexpected behavior.
There may be an impact on logged values or unintended alarms.
Do not use non-optimized expressions if variables within the expression will change frequently.
Do not use non-optimized expressions in alarm parameters.
A parameter expression that refers to tags outside the current hierarchy must use a non-optimized expression. There is no way to predict which hierarchy of tags will start first, therefore you must allow the expression to re-evaluate if a tag that it refers to in a different hierarchy starts later than the current tag.
Identifying properties
Do not add quotation marks to property names. Quotation marks should be used only to indicate literal text.
To read the a tag property other than it's value, follow the square brackets around the name with a backslash and then the name of the property.
[SomeTagName]\ShortName
To access the value of a property in a parent tag, preface the name of the property with two dots and a backslash (..\). VTScada will search upwards through the Parent-Child tree to find the first instance of a matching property name. You can specify the number of levels up at which to start by repeating the ..\ code.
Your expressions can use relative tag addresses, VTScada application properties and other system variables. Refer to topics in the scripting chapters beginning with Use Tag Values in Expressions.
Referring to text properties such as Description, Area or Engineering Units? You should use \ParmPhrase(), \GetPhrase() or \GetParmPhrase() rather than Concat(). See: Multilingual Expressions.
An expression in the name field of a tag will not change the tag's name. Rather, this expression will control whether the tag starts or not. Examples of this can be seen in the various Station Tags, which may be configured with a varying number of pumps for each station. This is done by tying the number of pumps in the overall station tag configuration to an expression in the name field of each pump. If the number is 1, only the first pump tag will start and the station tag will have one pump. If the number if 2, then two pump tags will start.
The expression used for a start condition must evaluate to TRUE (usually defined as 1) or FALSE (defined as zero).
For example, the MultiSmart, and MPE station tags include an option to set the number of pumps in the station.
The number of pumps in the station tag can vary.
The tag structure varies according to the number you choose:
On the left, one pump. On the right, three pumps configured.
Changing the selector doesn't change the number of pump tags created. It changes the number started. Select the Show Disabled option in the Tag Browser to reveal the difference.
The Multismart always has the same number of pumps. The choice is how many to start/enable.
Tags cannot be manually disabled from the right-click menu if they have a start condition. The "Enable" option will be grayed out.
To use this feature, add a Start Tag Expression to the name parameter of a tag.
The method is the same as adding a Tag Parameter Expression.
In the Tag Parameter Expression editor, whatever expression you create must ultimately return a Boolean result, meaning either zero or numeric non-zero (usually, one). If the expression works out to true at start-up then the tag starts. If false, it doesn't.
Start tag expressions are always optimized. They run only when the application starts or when a parent tag is redefined, which causes all child tags to restart. Ensure that the conditional within your start tag expression can be evaluated in both of those situations.
Overrides
Having made use of an expression to control a tag's configuration, you can choose to override that value in a given child tag. For example, a child tag which would otherwise inherit the area value "North County" might be assigned the area "South Street". When a value that would otherwise be based on a calculation is changed, this is called an "override". Assigning a value to a field that has no expression does not override anything and is simply called "assigning a value". The difference can be seen in the color that the field will turn: orange for overrides, and green for simple assignments.
A tag that has an override is marked with a
in the Tag Browser.
Overrides are both common and useful. Do not assume that the symbol means that you must take action to "clean up" the override in some way.
