Top  | Previous | Next

Tag Paths

Tags and their properties can be referenced by a string based path. Each has a unique absolute path, and will often have many equivalent relative paths when referenced from other tags. You will most often generate these by browsing or through drag and drop. However, it's a good idea to understand how tag paths work, particularly if you get into indirect tag binding or scripting.

 

A tag path will look something like this: [Source]folder/path/tag.property

 

The italicized portion of the path may contain the following:

•A tag
•Any number of nested folders followed by a tag, separated by forward slashes (/).
•A period (.) followed by a property name after the tag. Omitting this is equivalent to using the .Value property.

 

Now consider the [Source] (portion surrounded by square braces)

 

Source Option

Meaning

Applicability

[Tag Provider Name]

The name of the tag provider that hosts the tag

OPC and Expression tags

[] or not specified

The default tag provider for the current project.

OPC, Expression tags

[.]

Relative to the folder of the tag that is being bound.

Expression, Client tags

[~]

Relative to the tag provider of the tag that is being bound (root node)

Expression, Client tags

[Client]

Refers to a client tag

Client

[System]

Refers to a system tag

System

 

Relative Paths

Paths that begin with [.] or [~] are known as relative paths. The are used inside tags that bind to other tags, and are relative to the host tag's path. Using the relative path syntax helps avoid problems cause by moving tags and renaming providers. [~] refers to the tag's provider root. It can replace the explicit provider name, and thus protect against provider renames and importing/exporting/moving tags between different providers. [.] refers to the tag's current folder. By using [.], tags can be moved from folder to folder without problem (provided that all of the applicable tags are moved together).