Relative Paths - Tag Relationships

In this topic, the examples refer to a driver that is linked to a port. The information holds true for I/O tags linked to drivers, loggers and alarms linked to I/O, etc.

The default auto-linking behavior changed in VTScada 12.2.
Just prior to version 12.2, tags with auto-linking configurations in their tag selector fields (ex. [*Drive], [*Port]...) would only automatically link to direct ancestors.
Older applications can be configured to auto-link with direct ancestors, uncle tags or else sibling tags by enabling the property EnableSiblingTagAutoLinking however this may cause unexpected behavior. Tags that were linked to other tags using an auto-linking configuration may automatically link to another tag unexpectedly and break your application.
Applications created after the release of version 12.2 have EnableSiblingTagAutoLinking enabled by default.

VTScada developers will often build tags in a hierarchy. For example:

This method of linking the tags together has several advantages:

• Tags for a station (or equipment, or anything) are grouped in one place, making them easy to find.
• Adding new stations is a matter of copying only the one top-level tag. Child tags are copied automatically.
  (Tools are available to automate much of the work when duplicating stations or equipment.)
• Tags that need to link to another tag (linking to Driver tags, Port tags, Alarm Database tags, Publishers, Historians, Style Settings and so on...) will automatically link to relevant ancestors and siblings. Direct ancestors will prevail over siblings. For example, the driver in the example hierarchy will find the port without you needing to select it during configuration.
• Keeping flatter hierarchies and avoiding deeply nested hierarchies will results in more succinct full tag names that make it easier to use tag selectors, troubleshoot and generate easy-to-read reports.

#1 There are many ways that a hierarchy can be built and there is no single method that can be considered "best" in every instance. After reading this topic, take time to consider your system and decide on a tag hierarchy that will work for you.

#2 If you change your mind after changing how tags link together, you can easily restore the original configuration by doing a right-click on the parameter then selecting "Reset to Default". This option is enabled only for properties that have a default.

Links between tags

As an example, when a driver is linked to a parent Port tag, the configuration field for the port would look like so:

[*Port] is expression code. Building it up piece by piece it means:

[ ]       "Look for a tag..."
[* ]      "Look for a tag of type..."
[*Port]   "Look for a tag of type port"

This will find the first relative tag of the correct type. If a tag is found, its description field is shown following the [*...] code.

This type of link between tags is useful if you copy tags for a new site. Instead of having to reconfigure the driver copy to use a different port, it will simply attach to the closest ancestor that is a port. If there is no port ancestor it can auto link to a sibling port. On the other hand, it can become difficult to manage tags if there are too many levels.

Links between tags by default

This overly simplified hierarchy only serves one purpose: demonstrating default links between tags.

In the provided example, there is only one context tag to mark the top of the hierarchy. All 'Driver #' tags are Modbus Compatible Device tags and all 'IO#' tags are I/O & Calculations tags. The IO# tags will link to the Driver tags like so:

IO1 → Driver 1

IO2 → Driver 2

IO3 → Driver 1

IO1 will link to Driver 1 because Driver 1 is IO1's ancestor. Even though Driver 2 is a sibling of IO1, the ancestor (parent, grandparent etc) will prevail. IO2 will link to Driver 2 because it is the closest ancestor. IO3 will link to Driver 1, a sibling, because it has no ancestor tag that is a Driver.

No matter how the tags link by default, you can always manually override the selection using the tag selector or select a specific relative pathway. The button between the X button and the Tag Browser button gives you a choice of how to specify the link. Each is useful in its own right.

Ancestor relative path [*Port]

The default for child tags. The driver must be a child of the port before you can use this. That's where the "ancestor" part of the name comes in. The driver will find the closest parent, which might be several generations back.

Open relative path [Sim Host]

The default for siblings. This is "open" in the sense that it does not point to a specific tag and "relative" in the sense that the position of the tags in the hierarchy matters. Imagine if you create Station 2 by copying all of Station 1. If you were using open relative path, you would still need to change the IP address in the port, but the copy of the driver would be looking for the nearest port named "PLC1_Port", not the specific one within Station 1.

>> Note that if the name changes, the link breaks.

Fixed depth relative path [..\PLC1_Port]

Like the previous, but not open. This option says to find a tag with the matching name, the matching number of generations away. Each generation back is specified by a dot-dot-backslash ..\

Absolute path [<Station 1\PLC1_Port>]

Use that tag and none other. The full tag name must be provided, right from the top of the hierarchy. This is tied to the selected tag's unique ID, so the port tag's name can change but the link will be kept to exactly the same tag.

It may be interesting to note that when working in the Tag Browser, the default for new tags will be Ancestor or Open Relative. When drawing tags in the Idea Studio, the default relationship between the widget and the tag is Absolute. You can rename or move a tag with confidence that it will remain linked to the same widget.

If there are two of the same tag type at the same level (such as two sibling Driver tags), the auto-linking tag will not link, and the tag selector field will show an error:

Examples of Tag Hierarchies

Following are a few examples of how tags might be organized...

1. Flat.

All tags at the same level. This method is outdated but you may see it in very old applications.

If your application needs more than 10 tags then don't do this. (Also, write better names and descriptions than those shown in this example.) If your application needs less than 10 tags, a context tag is still a best practice.

Prior to the introduction of Context tags, this was the only way to organize tags. Knowing how to use filters in the Tag Browser was an essential skill in order to find any given tag.

2. Simple

One PLC, very few I/O.

Create a context tag as the parent. The driver, the port and the I/O are all siblings. This will save a great deal of configuration time while creating the I/O as they will link to their siblings automatically.

It's also easy to copy this structure if you add a second or third PLC with a similar set of I/O.

3. Simple sites

Each new PLC is grouped under a context tag and complex devices (such as a pump) are grouped under nested context tags. This design is easy to scale up and parse down. Tags that link to other tags will auto link with ancestor tags or else siblings. So, for example, the I/O tags nested under the Pump 1 Context tag will find the driver nested under Site 1, a Speedset will link to a Driver as an ancestor.

 

Do not assume that "site" can only mean "location". A "site" could just as easily mean a pump, a generator, a lift station, or anything.

 

4. More complex sites

Hierarchies in the tag browser are flexible, scalable and can grow with the system needs to become quite complex. There is a large catalog of tags that serve a wide array of purposes

 

As projects become larger, complexity increases. Use care and plan ahead. Create as many levels in your tag hierarchy as you need, but do not let this get out of control. Having too many levels can be as hard to manage as having too few.

Ancestor pathways are not contained by context tags. In the following example, Driver 2 prevails because it is an ancestor of IO1. Despite residing together under the same Context tag, Driver 1 is merely a sibling of IO1. If Driver 2 did not exist, Driver 1 would have auto linked to IO1.