About component naming

In a NiagaraAX station, components should be properly named using the following set of rules:

Only alphanumeric (A-Z, a-z, 0-9) and underscore (_) characters are used—spaces, hyphens, or other symbols characters (e.g: %, &, ., #, and so on) are illegal in component names. For further details, see the next section Escaped names.
The first character in the name must be a letter (not a numeral).
Name must be unique for every component within the same parent component. Workbench automatically enforces this rule, via a popup error dialog.
Naming is case-sensitive—for example, zone21 and Zone21 are unique names.
Case differences among names affect “name sorts” in table-based views, which order by ASCII code sequence, that is capital letters (A-Z) first, lower case (a-z) following.

To convey multiple-word names without using spaces, naming “conventions” such as “CamelCase” and/or underscores are often used, as needed. Examples of such component names are:

Floor1 or Floor_1
ReturnAirTemp or Return_Air_Temp
Zone201_SAT or Zone_201_SAT

Escaped names

Workbench does allow you to name components “improperly,” such as with spaces or other non-alphanumeric characters, without any warning. Further, various NiagaraAX drivers have “learn” features to automate the creation of points, some of which (by default) may also have such “improper” names—reflective of the “native name” of the source object. For example, a BACnet proxy point might have the default name “Zone 6 RH%” that matches the actual (native) BACnet object’s name.

In any case, be aware that the “actual” component name has all illegal characters “escaped” using a “$” character, along with the ASCII code for that character, in hexadecimal. The proxy point mentioned above, for example, will have the name “Zone$206RH$25”, where the $20 escapes the space and the $25 escapes the %. You can see these escaped names in the slot sheet of the component’s parent container. Or, with the component selected, look at its ord (shortcut Ctrl-L) to see its actual name. Other examples include the dash character “-” which is “$2d” and anytime you begin a name with a number, the “$3” is appended to the front of the name.

For the most part, this “escaped name” scheme is transparent to users. Whenever the name is displayed to the user, say in the Nav side bar, property sheet, wire sheet, or a point manger, the component’s name is “unescaped” by replacing the code (say, $20) with the actual ASCII character (say, a space). This way, the user sees “Zone 6 RH%” and so on. This is the component’s “display name.”

In some cases, escaped names lead to confusion. You should avoid them if possible (rename using rules—see About component naming). For example, if you add history extensions to escaped-named points, you see those escape codes listed for source points when accessing the History Ext Manager (although associated histories use the display names). Or, if you are building Px pages and manually typing in ords in Px widgets, you probably know source points by “display names” only. If you manually type in an ord without the actual (escaped) name, the widget binding fails with an error.

If this sounds too complicated, remember that “drag and drop” operations resolve escaped names without problems—for example, drag any point onto a Px page to get its proper ord.