Design Your Own Tags

To create a new type of tag, start with a Context tag. Any Context tag with a legal word in the Type field can be turned into a new type template. All child tags of that Context will be included in the new template. The Type property value becomes the name of the new type. Within your application (and any applications that use this one as an OEM layer), the new type will be available alongside the standard tag types.

The following images illustrate the process.

Name the type something that you can guarantee will be unique to your application. One way to do this is use compound words like AceCustomPump.
An error message will be displayed if the type name cannot be used.

New copies of your custom type can be created as easily as any standard VTScada tag type. If the type definition includes child tags, as is normally the case, then those will be created at the same time. Note that you can build on this by creating your own widgets that display all the child tags in one object.

Plan ahead and do less work later.

Before following the steps just described, take time to build the tag so that as much work as possible is done once and never needs to be repeated. For example, configuration fields in the child tags can and should use parameter expressions (that you create) so that they will be configured automatically using information from the parent tag.
When adding new instances of your custom tag type, developers should only need to configure the parent type. All child tags should be configured automatically using parameter expressions. The expression can be complex, or it can be as simple as copying a value from the parent tag to the child. The goal is to keep all of the configuration in one place / tag.

If some child tags will not be needed in every instance of the type, then use Start Tag expressions. These are similar to parameter expressions, but are stored in the tag's name field and control whether the tag will be enabled or disabled. For example, in a lift station that can have up to three pumps, all three will exist in the type definition, but two will be controlled by Start Tag expressions and be enabled only according to the number of pumps configured in the parent station.

If there's a chance that you will want to use the new type in other applications, build the type in an OEM layer below your application rather than directly in the application. It's much easier to distribute feature updates via OEM layers than to export tag types. (Reusable Application Layers)

Custom configuration

Some (not all!) configuration properties that relate to tags can be inherited from a parent tag instead of using global settings from the Application Configuration dialog. For example, you can have Roster and Alarm tags with their own delays and call-out priority settings. Alarm message templates can be designed that differ from one part of the application to another. Drivers can have differing configuration if (for example) you have some Modbus devices whose addressing begins at 0 and others whose addressing begins at 1. (ModiconTypedAddr1Offset)

Improve the design

You can modify the design of the new type by making changes to one instance, then issuing an "Redefine Type" command on it in the Tag Browser. For example, you might add a Context tag having two child tags: an Analog Input, and a Logger storing the Input's data. Later you decide to add an Alarm to the structure. By running a Redefine Type command, all new and existing instances of that type in the current application will include those child tags.

Never redefine a working instance of your custom type. Always create a temporary copy to modify, then run redefine on that. This avoids the danger of having local overrides become part of the type definition, changing all existing and new instances.

Context (Site) Tags and Alarm Notification

Context tags (or custom types derived from a Context tag) may define custom alarm message templates, for use by all alarms occurring within the structure. This is done by adding the desired template name(s) to the Context's list of properties. To create a custom property value that will be dynamic and unique for each instance, use tokens. A token will be replaced by the meaning it represents. All non-token characters will be passed along as a string. (To pass a percent sign as part of a string you must type %%)

A custom template with a value of:

Check: %D%T - %A - %M 

will output a message like:

"Check: [Date][Time] - [Area] - [Alarm description]"

You cannot pass an expression in the value field of a Context tag's custom property. To do this, you must create a custom tag type. See Alarm Notification Templates for more detailed instructions.