About tag-based NEQL bindings
Niagara has added support for tag-based bindings. Tag-based bindings use NEQL queries and resolve NEQL Ords instead of using more traditional Ord types, such as slot Path Ords.
In these descriptions, the component on which a Px view is placed is referred to as the base component. A Px view with relativized slot path Ords is more reusable than one with absolute slot path Ords but it still requires components to be positioned the same and named exactly the same on other base components Tag-based Px bindings use NEQL queries instead of slot paths for the bound ORDs. The result is that components can have different names and be placed anywhere in the station as long as there is a set of tags to identify the component and a (optional) relation to get from the base component to that bound component.
If there is not a relation between the base component and the bound component but the bound component is a descendant of the base component, a Select NEQL query can be used for the Ord binding. If the bound component is not a descendant of the base component, there must be a relation and a Traverse NEQL query will be used.

Invoked in a Px Editor view, from the Bound Ords pane by clicking the
(Neqlize Ords) button. The Neqlize Ords window attempts to find a set of tags and optionally a relation
to distinguish a component in the bound ORDs list from a search set.
The search set depends on what type of query you want.
The Neqlize Ords window shows the Before conversion value of the slot path Ords, the After conversion value of the tag-based NEQL Ords with tags and an optional relation, and the Path value shows the absolute slot path ord to that component because any previously converted NEQL queries may resolve to anywhere in the station.
Additional buttons
- Options opens the Workbench Neqlize Options window.

Refresh All refreshes all selected rows in the Neqlize Ords window.
Right-click menu options
- Edit NEQL Ord opens the Edit Neql Ord window. When selected, the Edit directly checkbox gives you full control to make changes to the Resulting Ord value of your NEQL query. When not selected, however, you can select different tags and relations to use. The query is generated based on your selections.

Refresh Row which is invoked by right-clicking on a single row.
Types of NEQL queries
There are two types of queries in NEQL:
A Traverse query uses a single relation ID and direction to get from a base component to a set of endpoints. If a component in the bound ORDs list is one of those endpoints, an algorithm compares the tags on that component to the tags on the other endpoints. If there is a set of tags that distinguishes the component from the other endpoints, that set of tags, the relation ID, and relation direction are returned. If there is not a distinguishing set of tags, another search is made with another relation on the base component.
A Select query operates on the descendants of a base component. If a component in the bound ORDs list is one of those descendants, an algorithm compares the tags on that component to tags on the other descendants. If there is a set of tags that distinguishes the component from the other descendants, that set of tags, but no relation ID or relation direction, is returned.
Within the Workbench for Px Editor, there are three query modes for finding a set of tags and optional relation:
Traverse If Possible - attempts to find a traverse query but falls back to a select query.
Traverse Only- attempts to find a traverse query only; an error is returned if the bound component is not an endpoint of one of the base component's relations or there is not a set of tags that distinguishes the bound component from other endpoints.
Select Only- attempts to find a select query only; an error is returned if the bound component is not a descendant of the base component or there is not a set of tags that distinguished the bound component from other descendants.
In addition to the query mode, you can specify certain tags and relations to exclude from the query to keep the graphic as resuable as possible. A few examples of tags and relations that limit reusability, and that are already listed in default exclusions, are shown here:
Tags:
n:name,n:displayName,n:ordInSession,hs:idRelations:
n:child,n:parent
A set of Default Excluded Tags and Relations is collected from each installed tag dictionary. A set of Custom Excluded Tags and Relations can also be specified in the station's TagDictionaryService. Additionally, a set of User Excluded Tags and Relations can be specified in the Px Editor Workbench Options.