Clicking on the Search Find and Replace.icon in the Tag Browser will open up the Designer's global Find/Replace screen. In the the example below, we searched for the Ramp9 Tag and limited the search to the default Tags. Results are shown at the bottom of the screen. For additional information, see
The Refresh Providersicon refreshes all of the Providers in the Tag Browser. This is useful if you or others have modified Tags but do not see an update. In general, this button is not used very often.
The New Tag Creating Tags for more information.icon opens a context menu showing all the options to add a Tag, Folder, UDT Instance or a UDT Definition. The new object is added under the Folder you have selected or as a sibling to the Tag you have selected. This button is disabled if there is no selection. See
With the OPC Browser, you can browse to find external PLC or OPC Tags. Click the OPC Server drag them to the icon at the top of the Tag Browser to open the OPC Browser. You can then select Tags andTag Browser to be used in the Ignition system. See Creating Tags for more information.
In the Tag Browser, the Tag Group Tag Group Editor window. Tag Groups dictate the rate of execution of Tags. This is where you set up your Tag Groups and scan rates. See Tag Groups for more information.pens the
The Tag Browser displays the Value, Data Type, and Traits columns by default. To toggle any of the options, click on the Column Selectoricon, then click the checkbox.
In the example below, we changed the Column Selector so that only the Tag values are shown next to the tag names.
Certain settings or Tag configurations are visually represented next to the Tag in the Tag Browser.
The following icons enable you to note some important settings on the Tag at a glance. A description of the icons are listed below.
|Scaling||The Scale Mode property under the Numeric Tag Properties section of the Tag Editor has been set to a value other than "Off." The value on the Tag will be scaled to some degree.|
|Alarming||At least one alarm has been configured on this Tag.|
|Tag History||This Tag has been configured to log data into the Tag Historian system.|
|Tag Event Script||At least one Tag Event Script has been enabled on this Tag.|
Context Menu (Right Click)
Editing Tags is done mostly through the Tag Browser. The Tag Browser allows you to right click on a Tag or folder to perform any of the following functions. Note that different objects will have different options available. The special Data Types folder is slightly different than a regular folder and will have even fewer options.
Disabled when a Folder is selected.
Opens the Tag Editor window so the Tag can be edited.
Disabled when a Folder is selected.
Editing the JSON code of the Tag.
|Rename||Renames the current selection.|
|Delete||Deletes the current selection.|
|Cut||Cuts the current selection into the clipboard.|
|Copy||Copies the current selection into the clipboard.|
|Paste||Pastes the content in the clipboard into the selected context.|
|Copy Tag Path||Copies the currently selected Tag path into the clipboard.|
Disabled when a Tag is selected.
For Folders, this option opens a sub-menu to create a Tag or Tags.
|Multi-instance Wizard||Creates many instances of a UDT at the same time.|
|Exports the selected Tags.|
|Import Tags||Imports Tags into the project.|
|Go To Definition|
Removed unless a UDT or UDT Member is selected.
Finds the UDT definition used in the UDT instance.
|Restart Tag||Attempts to start / restart the selected Tag. If a folder is restarted, then all tags under the folder will restart.|
|Refresh Providers||Refreshes the list of Tag providers.|
The Tag Editor is robust interface that contains all the properties that can be configured for Tags. In the Tag Editor, you set the Tag's name, value, numeric and meta data properties, security, alarming, history, and more. For more information, see Tag Properties.
Tags names are flexible and to not have to match data source names (like an OPC path) or tag codes (such as N7, F8, etc.). It is not necessary that Tag's name be related at all to its underlying data source (OPC path, for instance). This provides a level of indirection that is convenient for systems with many repeat Tag structures.
It is important to give Tags a meaningful structure and arrange them in hierarchical Tag folders so that they are easy to understand, identify, and locate for all developers. By default, Ignition Tags are named after their OPC Server address when a Tag is dragged into the Tag Browser. You can change this name to just about anything that you want. We recommend using names that mean something to your process, such as "Motor 3 Amps." Alternatively you could create folders in your Tag Browser such as "Motor 3/Amps.". When renaming Tags and folders, there is really only one question to ask: "does this structure make sense?"
Another important concept to consider when naming and organizing your Tags, is to do this early in your project. If you rename or move any of your Tags to another folder, and your Tag is being used in other places, chances are you are going to break the reference to the Tag on your screen. So keeping your Tags organized and defining your Tag structure early on in your project is critical.
When you choose a new name for your Tags and folders, there are some rules that must be followed. The first character of the Tag name must be one of the following:
- Any alphanumeric
- Any valid unicode letter
- An underscore
The second character, and every character after that can then be one of the following:
- Any alphanumeric
- Any valid unicode letter
- An underscore
- A space
Any of the following special characters:
' - : ( )
All other special characters can not be used in a Tag name.
Tags and their properties can be referenced by a string-based path. Each Tag has a unique absolute path and often has many equivalent relative paths when referenced from other Tags. You most often generate these paths by browsing or through dragging. 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 looks something like this:
folder/path/tag.property 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.
[Source] portion surrounded by square braces can have the following options:
|[Tag Provider Name]||The name of the Tag provider that hosts the Tag.||OPC, 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. This is especially useful in UDT definitions.||Expression, Client Tags|
|[~]||Relative to the Tag provider of the Tag that is being bound (root node).||Expression, Client Tags|
|[Client]||Refers to a Vision Client Tag.||Vision Client|
|[System]||Refers to a System Tag.||System|
What about Perspective Client Tags?
There are no "Client Tags" in a Perspective Session. Take a look at the Session Properties for similarly scoped variables.
Using Relative Paths
Paths that begin with [.] or [~] are known as relative paths. They are used inside Tags that bind to other Tags, and are relative to the host Tag's path. Using the relative path syntax helps to avoid problems caused by moving Tags and renaming 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). Additionally, you can use ".." (two periods) to go back one folder from the current relative position, for example [.]../../tag allows you to reference a Tag two folders up.
[~] 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.
Tag Path Manipulation
Ignition provides a great deal of flexibility for Tag addressing since Tag paths and Tag properties are string-based. The underlying strings that compose a valid Tag path can be assembled from many different parts in with the eventual construction resulting in a valid Tag path.
The following scripting demonstrates this concept. Suppose there was a Tag path to a level indicator in a tank. In this case it is the default Tag provider, Tanks folder, Tank 1 Folder, and the Level Tag.
But suppose that there was more than just Tank 1 and instead there was Tank 2, Tank 3, Tank 4, etc. Dynamically changing the Tag paths is simple because Ignition's Tag paths are string representations. The following takes the tank number and inserts it into a new Tag path. The tankNumber variable changes the eventual creation of the tagPath. Using this method in scripting or in an expression binding will look slightly different.
The result of the tagPath variable will be [default]Tanks/Tank 2/Level which is a valid Tag path to the the level sensor for Tank 2.
Working with Tags
Once you have Tags in your Tag Browser, they automatically start executing. The Designer is live, and in the Tag Browser you can see your Tags update in real time. The most commonly used type of Tag is an OPC Tag, which gets its value from a device like an OPC Server. You can connect to just about any type of device out there and show the data on screen, as history, and write back whenever you want. Tags make Ignition extremely flexible and easy to show data. See the Quick Start Guide to get some tags created and in your client.
Click these links to find out about
Once you have some Tags created, you can edit them to include even more features. You can:
In addition to all that, Ignition allows you to create UDTs (User Defined Types) out of your Tags to rapidly develop projects with structured objects. This gives you the ability to create a master type then quickly add many instances. UDTs allow you to make a change in one place and see it automatically propagated to every instance.