Deploying Niagara PX Graphics: From Export to Operator Handover
A graphics package is ready to test when the files finish exporting. It is ready to hand over when an operator can open the right page, trust its values and use only the controls their role allows. Keep those milestones separate.
Keep the package together
Save the editable builder project, exported ZIP and the exact application version in your job folder. Extract the package before importing it. A PX file can reference separate images and animations; copying just the page can leave a convincing layout with missing equipment. Preserve the supplied directory structure until you have deliberately reviewed and changed each reference.
Deploy to a reversible location
Back up the target station and use a distinct test folder or view. Reusing an existing filename can replace a working image even when the new PX page has a different name. Record the destination paths and keep the previous package available until the replacement passes the agreed tests.
Check three layers separately
- Assets: confirm the shell, ductwork, static components and animations are visible. If one image is missing, inspect that image reference and file location first.
- Bindings: compare key values with the actual source points. Check units, Boolean interpretation, enum states and the distinction between command and feedback.
- Access: open the view as the intended operator. A successful administrator test does not establish that normal users can read the same points or use the same actions.
A symptom-first troubleshooting guide
The page opens, but an image is missing
Check the referenced filename, folder, case and station file access. Confirm that the matching asset was included in the transfer. Reload after the correction before changing the graphic itself.
The equipment is visible, but a value is blank
Resolve the point ORD in the target station. Verify the binding context and data type, then test access using the operator role. Do not replace a failed binding with a fixed normal-looking number.
The animation runs in the wrong state
Compare the bound point with the intended meaning of the animation. A command, run proof and fault are different signals. Review state mapping and test both normal states in a safe environment.
The view works locally but differs through the supervisor
Review the remote station route and the deployed Niagara architecture. Tridium documents PX ORD translation for virtual views in its multi-tier system database work; this is distinct from simply copying a local slot path. Confirm the supported mechanism for your release before changing bindings.
Review at the actual display size
Open the final page at the operator screen resolution and browser zoom. Check clipped names, overlapping point bezels, useful text size and navigation targets. For a rendered equipment background, export enough pixels for its intended display area; scaling a small image upward does not restore detail. Avoid oversized assets that add transfer and rendering cost without a visible benefit.
Document the handover
Record the station build, required modules, page and asset locations, graphics version, tested account role and outstanding exceptions. Include the saved project and reviewed point list in the customer's agreed deliverables. The tests should demonstrate what was checked rather than simply state “graphics complete.”
Explore AHU Builder for equipment graphics or compare dashboard previews. For package-specific questions, use the technical FAQ or contact support.
Technical reference: TridiumTalk — Niagara 4.13 Multi-Tiered System Database. The deployment checklist is NiagaraUI editorial guidance; verify the actual target station before production use.