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.

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 together will do so automatically in a parent-child relation. For example, the driver will find the port without you needing to select it during configuration.

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 ancestor 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 parent tag that is a port. On the other hand, it can become difficult to manage tags if there are too many levels. That's why you get a choice...

 

The relationship between tags is not entirely in whether the driver is a child or sibling of the port. It's in how the relationship between the two is specified. The default relationship is different depending on whether you make the driver a child or sibling, but you can override the default and define it the way you want. 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 of the right type, 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 "Sim Host", not the specific one within Station 1.

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

Fixed depth relative path [..\Sim Host]

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 [<Site1\Sim Host>]

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 either Ancestor or Open Relative. These make the most sense here. But, 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.

Examples of Tag Hierarchies

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

1. Flat.

All tags at the same level.

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

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.

Driver is the parent and both the port and the I/O are children of the driver. This will save a great deal of configuration time while creating the I/O as they will link to the parent driver automatically. The port must be created after the driver and linked manually.

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

Leaves room for expansion. Each new PLC that you add will have its own site. Here, each "site" tag is a Context tag. The port is a sibling of the driver in this example, but it could as easily be a child.

 

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

If the PLC monitors and controls more than one type of equipment, it can make sense to have a Context tag for each type.

 

These are easiest to build if each Context is below the driver, but with a bit of extra work involving expressions you can organize them so that the port, driver and each Context is a sibling, yet still keep the advantages of the hierarchy.

 

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.