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.

"FmoocKh", 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 above, 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).

"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.

Name field.

                Add or remove start conditions

Other fields, no existing code to override.

                Add or remove parameter expressions.

Other fields, with code to override (child tags of a user-defined type)
             Inherit from parent (Area parameter only)
            Add or remove override

Optimized Expressions

When using an expression to configure a parameter value, you can choose whether the value should be evaluated only when the tag starts (and re-starts), or whenever there is a change to any value used by the expression. Non-optimized tag expressions are intended for situations where configuration values must be obtained from equipment, which is reachable only after the application starts.

Do not deselect the optimization option unless there is a clear need to do so. Misuse of non-optimized tag expressions can have undesirable side-effects. In particular, note that configuring a tag so that its properties change dynamically may have an impact on logged values or cause unintended alarms.
Every time that the non-optimized parameter expression changes, the tag will restart, as will all of its descendants, just as if you changed it in the Tag Browser. Be certain that variables within the expression will not change frequently.

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.

When optimization is selected:

  • The parameter value will be evaluated only when the tag is created, when the application re-starts, or when you explicitly change any property of this tag or a parent using 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 not selected:

  • Expressions can use information obtained from hardware after tags have initialized and I/O operations begin.
    This is the primary purpose of non-optimized parameter expressions.
  • The expression will be re-evaluated whenever any of the parameters used in the expression change.
    Be careful to consider all the possible effects of this fact.
  • 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 those that can be evaluated in both script and steady-state.

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.

Start Tag 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.

 

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.