Niagara PX Point Bindings: A Practical ORD Checklist

A polished equipment graphic can still show the wrong temperature or animate the wrong fan. Before handover, treat every visible value as a connection that needs evidence. This checklist starts with a single AHU and follows its points from the station to the operator screen.

Start with a small binding schedule

List the equipment identifier, point purpose, station ORD, expected data type, units and display behavior. Keep command and feedback in separate rows. A fan enable command tells you what the controller was asked to do; a run-status point is the evidence you intend the animation to represent. Name both explicitly instead of calling each one “Fan.”

Prove the ORD at its source

Copy the actual point ORD from Workbench rather than reconstructing a path from the equipment label. Resolve it in the target station and compare the source value with the displayed value. For example, station:|slot:/Drivers/BacnetNetwork/AHU1/points/SupplyAirTemp is an illustrative absolute path, not a path that will exist on every job.

Absolute slot paths identify a specific location. Reusable graphics need deliberate binding context: a relative binding that works under one equipment component can resolve differently under another. Tridium also supports tag-based PX bindings from Niagara 4.9; these use NEQL and require appropriate dictionaries, tags and relationships. Do not assume a graphic targeting Niagara 4.8 can use that later feature.

Match the value to the widget

• Numeric: confirm units, precision and the engineering range before choosing a gauge or color scale.
• Boolean: establish which state means running, enabled, open or alarmed. Do not infer that meaning from a green icon.
• Enum: review the actual states rather than treating every nonzero value as On.
• Status: plan how unavailable, faulted or stale data appears. An attractive last-known value is not proof of a healthy connection.

Use CSV matching as a review aid

For AHU Builder, import the point list and inspect the proposed equipment matches before exporting. Similar identifiers such as AHU1 and AHU10 deserve an explicit check. Open the properties of important sensors, fans and dampers and verify their ORDs and binding type. Keep the reviewed CSV with the project so another engineer can reproduce the mapping.

Test the operator experience

Open the exported PX page using the intended operator account, not only an administrator session. Check read access, navigation and any permitted commands separately. In a safe test station, exercise representative normal and unavailable states; do not force live plant equipment just to demonstrate an animation.

Record the station version, tested account role, graphic revision and exceptions. Resolve one binding at a time when troubleshooting: first the point, then its path, then its display mapping. This keeps a rendering issue from being mistaken for a controls problem.

Next step

Use the AHU Builder Lite demo and product guide to explore the workflow, or visit the technical FAQ for export and installation help. A graphic presents controls data; it does not replace sequence programming or commissioning.

Technical reference: Tridium — Easy Tag-Based Graphics. Examples and the checklist above are NiagaraUI editorial guidance.