Note
One PX sheet for every AHU
A graphic drawn for one air handler and copied twenty times is twenty graphics to maintain. The difference between that and one sheet is how its ORDs were bound.
- PX graphics
- Standard sheets
- Reuse
Why the copies happen
When you bind a widget with the Px Editor tools, the ORD you get is absolute by default. It looks like this:
station:|slot:/Logic/HousingUnit/AirHandler/DamperPosition
That path resolves to one unique component, always, wherever the sheet is used from. Attach the same sheet to a different air handler and every widget on it still points at the first one. The graphic is not broken — it is doing exactly what it was told — so the usual response is to copy the file, re-point every binding, and do it again for the next unit.
What relative binding changes
A relative ORD resolves against the parent ORD of the view it is in. The same sheet, opened as the view of AHU-02, resolves its bindings under AHU-02. One file serves every identically shaped piece of plant on the site.
You do not have to retype anything to get there. In Edit mode, the Bound Ords area of the Px Editor lists the sheet's bindings and has a Relativize Ords button; it opens a window listing every ORD that can be relativised, and the paths in the Bound Ords area shorten when you accept.
The catch, and it is the whole job. Relative binding works only
where the child slot names match. DamperPosition has to be called
DamperPosition under every air handler, not Damper Pos
under one and DmpPos under the next. The reusable graphic is a
consequence of a naming standard, not a substitute for one.
When one sheet is not quite enough: ORD variables
Relativising handles "the same sheet against different equipment". The other case is a sheet that embeds a smaller sheet several times over, each instance pointed at something different — a plant overview holding four identical pump panels. That is what ORD variables are for.
Inside the child sheet, the variable part of a binding is written
$(name) — for example $(Child1)/Variable1. The parent
embeds the child with a PxInclude widget and supplies a value for
each variable, so the same child file renders against a different branch of the
tree in each instance.
What this is worth
The saving is not in drawing time; drawing the second copy is quick. It is in everything afterwards. A relatively-bound standard sheet means a change to how an AHU is presented — a new alarm indicator, a corrected unit, a different colour rule — is made once and appears on every AHU on the site. Twenty copies mean twenty edits and, in practice, nineteen: one always gets missed, and the one that got missed is the one the client opens.
Retrofitting an estate that was built the other way
- Pick the best existing sheet rather than starting again. Whichever copy has had the most correction applied to it is the one closest to what everybody actually wanted.
- Fix the naming first. Relativising against inconsistent slot names produces a sheet that works on some units and shows nulls on others, which is worse than the copies because it looks finished.
- Relativise, then test against the odd one out — the unit with the extra sensor or the missing valve, not the one the sheet was drawn from.
- Repoint the navigation, then delete the copies. Leaving them in place guarantees somebody edits one in two years' time and cannot work out why nothing changed on screen.
Related
Where this comes up in the work
PX graphics
Niagara PX graphics as a reusable template set: standard sheets per plant type, relative-ORD binding, navigation hierarchy and a graphics standard.
bajaux widgets
Custom Niagara web widgets built with bajaux and BajaScript: HTML5 dashboards, navigation, equipment views and charts, bound to live station ORDs and BQL.
More notes
Other things worth writing down
Which Niagara version to stamp a module for
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
- Module development
- Mixed estates
- Build tooling
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
Pure Java, or it will not run on a JACE
A controller is an ARM host with a fraction of a server's memory. Native libraries, JNI and heavyweight dependencies do not survive the move from a PC.
- JACE
- Controllers
- Module development
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.