Move and Rename Tags

Full tag names describe the tag's place in the hierarchy. Thus, moving a tag and renaming a tag are essentially the same operation.

There can be side-effects when moving a tag. Details vary with the situation. Use care in the following cases: an I/O tag configured to use the nearest parent driver, a tag with a parameter expression that refers to another tag, a tag that is part of a user-defined type.

A tag's unique ID stays the same in nearly all cases when renaming(*), therefore logging, alarms, reports, widgets, etc. will not be affected.  But, anything that is based on the user-friendly name, including any expressions you may have created, are likely to break. See the examples and cautions at the end of this topic. (* The exception is a cut-and-paste operation. Cut is equivalent to delete. The following paste creates a completely new tag.)

Note that you can select multiple tags in the Tag Browser's main window by holding down the Ctrl key while selecting. Use this to copy, move, or delete several tags at once.

To rename a tag:

  1. Select the tag in the Tag Browser
  2. Click Properties, or right-click on the tag and select Properties from the context menu.
  3. Change the text in the name field.
  4. Click OK.

   

Rename a tag from "Pump1\Op Status" to "Pump1\Running".

To move a tag:

  1. Select the tag to be moved, in the Tag Browser
  1. Right-click on the tag and select Cut, or click the Cut button.

  ... or ...   

  1. Right-click on a tag elsewhere in the hierarchy, under which you want to place the original tag.
  1. Select Paste as Child
    You will be reminded that references may need to be updated - see following notes on the effects of changing the name.

  1. Click Yes to acknowledge the message and complete the move, or No to cancel the move.

Move a tag from Pump1\Op Status" to "Pump2\Op Status".

Effects of changing the name:

  • Expressions that referred to the tag may need to be updated. 

Expressions are created by users, not by VTScada, and use the tag's name rather than the unique ID.  Changing the name of the tag will usually mean that the expression will need to be changed to use the new name. An exception to this is if both the referencing tag and the referenced tag are moved together. In this case, the reference is likely to survive, but it is wise to check.

  • The link between tags may be affected depending on whether that link is Ancestor Relative Path, Open Relative Path, Fixed Depth Relative Path or Absolute Path. See: Relative Paths - Tag Relationships
  • Potential for confusion

If operators are used to seeing the tag with one name, changing its name to something else is likely to cause confusion.

Examples and Cautions

Logged history, tags drawn on a page, reports, built-in alarms and network values are all associated with the tag's unique ID, not the name.

Example 1: 

You have an Analog Status tag named AAA, which has logged history and which is drawn on a page.  You delete that tag.  You then create a new Analog Status tag and name it AAA.

The new tag has a new unique ID and therefore nothing that was associated with the old tag's unique ID will be associated with the new tag's ID.  This may surprise anyone who used older versions of VTS where tags were identified only by their name.

Example 2:

You have created a new type of tag, DrainValve.  DrainValve was created using two tags: a parent Context tag (Valve1 in this example), and a child Analog Status tag named Flow. (See: Design Your Own Tags)

Sample tag structure with user-defined types.

You move Flow from Valve1 into Pump 1 by doing a cut and paste operation.

When asked whether you want to redefine type ValveType, you decide upon "No".

Warning when moving a tag from a user-defined type.

If you choose "No" you cause the operation to be a cut (delete) and paste (create new tag) rather than a move.  WaterPipe gets an Analog Status tag named Flow that is identical to the original, but which is a new tag with a new unique ID.  Logged history, etc from the original Flow is now unrecoverable.

When synchronizing version changes, a move trumps a modify.

Example:

You have installed the application on two, unconnected computers.  On one computer, you move a tag to a new location in the tag tree.  On the other computer you leave the tag where it is, but change its properties.

You then connect the two computers (or take a ChangeSet from one to the other), thus allowing the version control system to synchronize the application on both machines.

In the final synchronized version, the tag will have been moved. The property changes will not be included in the running version.