Skip to main content
Version: 8.1


What Is a Tag?

Tags are points of data and may have static values or dynamic values that come from an OPC address, an expression, or a SQL query. The values can be used on screens and in transaction groups.

Tags provide a consistent data model throughout Ignition, and offer the easiest way to get up and running creating realtime status and control systems. Despite their fast initial learning curve, however, Tags offer a great amount of power in system design and configuration. The ability to aggregate Tags from a variety of installations means that you can build widely distributed SCADA systems more easily than ever before with a high level of performance and relatively easy configuration.

While the goal of Tags in Ignition is to create an easy yet powerful model, the variety of options and terminology can sometimes make configuration confusing. Tags are created and controlled using both the Gateway and the Designer for configuration.

  • In the Designer, you create or import the Tags. There are several types of Tags such as an OPC Tags and Memory Tags. Each Tag has many properties and other functionality such as alarming, history, etc. Once your Tags are created, you can use them in your windows, views, and reports.
  • In the Gateway, you create and modify Tag Providers. You can create these Realtime Providers to store groupings of Tags for use in your projects either locally in Ignition or share them externally with connected Gateways. There are also Historian Providers used to store historical data for the Tags, but these are automatically created for each datasource you have. These Tag Provider configurations in the Gateway apply globally to all your projects.

The following example shows a pressureDischarge Tag in the Tag Browser and a Gauge component in the Designer. The value on the Designer component is bound to the Tag and updates in realtime. This is just a simple example of how Tag values can be represented in your SCADA designs.

Tag Providers

There are two types of Tag providers; Internal and Remote. By default, a fresh Ignition installation will have an internal Tag provider. This can be thought of as a standard internal Tag database, and stored in the Ignition Gateway. Additionally, it is possible to create Remote Tag Providers, linking one installation of Ignition to the Tags on another Ignition. This ability opens up some very flexible architectures.

Tag User Defined Types

Tag User Defined Types (UDTs) provide an object-oriented approach to Tag building, allowing you to define parameterized data types, extend and override types, and then rapidly generate instances. A change to the type definition is then inherited by all instances, drastically saving time when making routine changes. The UDTs are fully supported by Vision templates, which means you can configure templates for your custom data types and take advantage of drag-and-drop binding to rapidly build complex screens.

Tag Features

Tags work naturally and easily with Ignition to offer the following features:

Performance and Scalability Tags offer great performance on the Gateway, in Perspective Sessions, and in the Vision Client. On the Gateway, the system can support many thousands of value changes per second and millions of Tags. In runtime, Tags improve efficiency with their lightweight subscription architecture. Adding additional Clients creates a nearly negligible effect on the database and the Gateway performance.

Object-Oriented Design Use Tag UDTs (User Defined Types) to design re-usable, parameterized, and extendable data types. You can create and configure new instance Tags in seconds, saving a great amount of time over traditional Tag systems.

Powerful Alarming Model Each Tag can have any number of alarms configured on it. There are many different alarm modes accommodating simple digital alarms, analog high/low value alarms, as well as more specialty alarms like bad data quality and bit-packed alarms. The settings for alarms can bound to other Tags, making the alarm configuration dynamic.

Drag-and-Drop Screen Design You can drag and drop Tags onto a window or view to automatically create new bound components. Drag Tags onto existing components or properties to quickly bind them to the data.

Historical Logging The Tag Historian Module makes it easier than ever to store and use historical data. When you simply select a check box on a Tag, historical data is stored in an efficient format in your SQL database. This data is then available for querying through scripting, historical bindings, and reporting. Also, you can drag-and-drop Tags directly onto an many components to create trends or display historical values. Tags Historian's robust querying provides you great flexibility in how you retrieve the data.

Importing and Exporting Tags

Ignition Tags can easily be imported and exported from the Designer by selecting the More Options menu, then either the Import Tags icon or Export Tags icon. You'll be prompted to choose the Tags or folders that you want. See the Exporting and Importing Tags page for more information.

Tag Naming

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:

  • Letter - specifically, a letter as recognized by Unicode's Letter (L) category.
  • Number
  • Underscore

The second character, and every character after that can then be one of the following:

  • Letter
  • Number
  • Underscore
  • Space
  • Any of the following special characters: ', -, :, (, )

All other special characters are not allowed in a Tag name.