After using the correct Ignition reference method, engineers can identify static tag consumers, separate project changes from tag usage, and avoid deleting a tag based on an incomplete text search. Follow the reference from the project resource to the tag path, then use runtime observation when a path can be constructed dynamically.
Where does an Ignition tag request travel?
A project resource initiates the request. A binding, script, template instance, gateway script, historian configuration, or another module-owned resource supplies or constructs a tag path. Ignition resolves that path through the tag system, after which the associated provider and communication path handle the read or write.
Layer one comes first when the immediate symptom is a communication error. Check the device connection and tag quality before treating the tag as unused. A bad communication path says nothing about whether projects, scripts, or history services still reference the tag.
| Path element | Question to answer | Useful record |
|---|---|---|
| Project resource | Which binding, script, screen, or template contains the reference? | Resource name and property or script location |
| Tag address | Is the complete path stored literally or assembled at runtime? | Literal path, expression inputs, and parameters |
| Gateway service | Does a gateway script, historian, or another service access it? | Service configuration and observed access |
| Network connection | Is the communication error below the tag-reference layer? | Connection state, tag quality, and diagnostics |
| Port | Does the affected connection reach its configured endpoint? | Configured port and connection diagnostics; no port value is specified here |
| Time basis | Is the question about present configuration or historical use? | Static scan time or a defined observation interval |
Which cross-reference approach answers the question?
| Approach | Answers | Strength | Boundary |
|---|---|---|---|
| Tag Reference Tracker | Which Ignition resource uses a tag | Purpose-built tag-to-resource identification | Dynamically constructed paths can prevent a complete static result |
| Designer Find/Replace | Where a literal name or path appears in searchable project content | Useful for targeted searches and manual cross-reference lists | A spelling variant, indirect reference, or runtime-built path may not match |
| Version control in Ignition 8 | Which resources changed between project versions | Some resources are stored as text; scripts can expose the exact change | Change history is not a tag-usage inventory |
| Export-file scanner | Potential static occurrences in an exported snapshot | Could produce an offline, sortable inventory for formats it understands | Module-defined serialized resources prevent a universal external parser |
| Runtime access observation | Whether configured services have accessed a tag during an interval | Captures paths that exist only at runtime | No native 30-day access report is established here; instrumentation must record the access |
Use the Tag Reference Tracker as the primary static method when the installed Ignition build contains it. Use Find/Replace to corroborate literal references and investigate naming fragments. Use version control separately to compare revisions. For a deletion decision, combine static results with runtime observation because no static parser can prove that dynamically generated code will never address a tag.
Why is an exported-project scanner incomplete?
Ignition project exports are not uniformly searchable source trees. Project resources can use serialized encodings selected by the module that created them. A resource may expand into XML that contains recursively nested binary encodings, and third-party modules can define additional resource formats.
An external scanner therefore needs a decoder for every participating resource type and serialization choice. Treating the export as plain text will find readable strings while silently skipping references held in binary or nested structures. Even a decoder that understands every current format still cannot resolve arbitrary tag paths assembled from variables, template parameters, string operations, or runtime data.
An export scan remains useful as a timestamped snapshot when its coverage is declared. Its output can list one row per occurrence and include the tag, resource, property or script location, and scan time. It must not be presented as proof that an omitted tag has no consumer.
Which method should be used for each Ignition version?
The Tag Reference Tracker was announced for the 8.1.34 release, with merged code scheduled for a nightly build beginning the morning of 10/26/2023. Check the installed version and confirm that the tool is present before planning the workflow around it. A nightly build and a production release are separate deployment choices; apply the site’s normal qualification process before changing a production gateway or Designer installation.
On an installation without the tracker, search in the Designer with Find/Replace. Copying Find/Replace results was fixed in 8.1.1, allowing results to be transferred into a spreadsheet for sorting and review. Search the complete tag path first, then the tag name and relevant path fragments. Record duplicate occurrences individually when the deliverable requires an occurrence count.
Use Ignition 8 version-control data when the engineering question is “what changed?” Some project resources are text-based, so scripts can show exact edits. Version control does not count template instances, prove current tag usage, or decode every module-owned resource into a meaningful textual difference.
How should the cross-reference procedure be run?
- Capture the installed Ignition version and identify whether the Tag Reference Tracker is available. Record the project revision or export timestamp so the result has a defined configuration baseline.
- Check the physical and communication path for any tag reporting a communication error. Record its quality and connection state independently from the usage investigation.
- Run the Tag Reference Tracker for the target tag when available. Capture every returned resource and the location of the reference.
- Run Designer Find/Replace for the full path, bare tag name, and stable path fragments. Copy the results when the installed version supports it, then normalize them into columns for project, resource, reference type, and tag path.
- Inspect scripts, template parameters, indirect bindings, and expressions that concatenate or substitute path elements. Trace each input capable of producing the target path.
- Review gateway-level consumers, including gateway scripts and historian configuration. These consumers may exist outside the screen or project resource currently under review.
- If removal is planned, observe or instrument runtime access for an interval matched to the process cycle. The proposed
30 daysis a decision criterion, not a guarantee: a monthly, seasonal, alarm-driven, or maintenance-only path may remain dormant for that entire interval. - Disable or redirect confirmed consumers before deleting the tag. Preserve the baseline and cross-reference result so the change can be audited or reversed.
How is the result verified without a false negative?
| Check | Pass condition | Recurring pitfall |
|---|---|---|
| Tracker result | Every reported resource has been reviewed | Treating an empty static result as proof of zero runtime use |
| Find/Replace | Full paths, names, and stable fragments were searched | Searching only one textual spelling |
| Templates | Definitions and deployed instances were counted separately | Confusing one template definition with its instance count |
| Version comparison | Changed resources and exact textual changes were recorded where available | Using a project diff as a usage report |
| Runtime review | The observation interval covers relevant operating modes | Missing infrequent, conditional, or seasonal execution |
| Communication | Bad quality was diagnosed independently of reference status | Deleting a tag because its device path is offline |
FAQ
What happens if Ignition builds a tag path at runtime?
A static cross-reference can miss it because the complete address is absent from stored resources. Trace the variables and template parameters that build the path, then record runtime access during the relevant operating modes.
What happens if Find/Replace returns no tag references?
Search the full path, bare name, and stable fragments, then inspect indirect bindings and scripts. Copying Find/Replace results is available from 8.1.1, but an empty text search does not clear a tag for deletion.
What happens if the Tag Reference Tracker finds nothing?
Review gateway scripts, historian configuration, template parameters, and runtime-built paths. Observe the tag across the required process cycle, disable confirmed consumers, and run the tracker and runtime check again as the final verification step.