The biggest benefit from export tag usage is on jobs where JACE stations under a Supervisor are largely “replicated”, often with many such subordinate stations. Such jobs may have scores of JACEs, or even hundreds or more—and possibly even multiple “tiered” subordinate Supervisor stations. Further, export tags allow an operating Supervisor to be dynamically expanded with additional subordinates (JACEs, typically), without doing the work on the Supervisor station itself.

Export tag usage is not limited to such large jobs, however. One particular type of export tag may be useful even on jobs where each subordinate (JACE) station is thoroughly unique. Specifically, the PxViewTag allows PxViews served from a subordinate station to be also dynamically served from the Supervisor, with very little engineering effort.

Export tags are added in subordinate (typically JACE) stations. The Supervisor uses only one component from the exportTags palette: the SupervisorExportTagNetworkExt component.

That depends upon the export tag type—for the most “advanced” export tag, the PxViewTag, you drop it onto the same folder (or container) that has the Px view. You drop other export tag types at different spots, for example, drop a HistoryImportTag onto a point’s history extension, or drop a PointTag onto a proxy point under some driver network.

Essentially, export tags determine which station objects (components, histories, files) should be represented in a particular Supervisor, under its NiagaraStation component for that subordinate station. Included is any folder structure needed under that NiagaraStation, which you can model first in the subordinate station in its “profile.bog file”. In that same file, you also specify any “non-default” property values needed in that NiagaraStation, including properties in its “device extension” components. Then, when the export tag “Join” command is given, those objects (along with their folder structure), are implemented in the Supervisor station.

While engineering, and particularly while learning about export tags, the Join process is often an iterative process. In other words, you typically issue many export tag Joins before a NiagaraStation is considered “done”. Each Join dynamically modifies the NiagaraStation in the Supervisor, as needed.

Note that each Join is “merged” with the existing NiagaraStation representation in the Supervisor station. This includes Niagara components that were created in “the traditional way” as well as those made from use of export tags. Therefore, it is possible to have a “hybrid-sourced” representation of a subordinate station in a Supervisor’s NiagaraNetwork, where some items were added by export tags in the subordinate station, and other items were added by engineering in the Supervisor station.

This is not recommended, because of the extra memory consumed by the “Supervisor” JACE. Also, because JACEs are not typically licensed for Niagara “virtual” components, they could not take advantage of “PxViewTags”.