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. If doing so, it is typical to use an expression when defining the template so that the message will be unique for each instance of the type.

For example, Concat(\Name, "%N%M") would show the name of the Context tag plus the description of the alarm (which may be a child, grandchild, etc. of the context).

Because tag names and other properties may contain characters that would conflict with template characters, such as percent signs (%), you should always process information from the Context tag using the \PrepStringForTemplate() function. Updating the previous example, Concat(\PrepStringForTemplate(\Name), "%N%M") is the safer way to reference \Name in case any given name contains a %.

Note that you might also need to use a \GetPhrase or \GetParmPhrase call in your expression. See: Multilingual Expressions