First post here, long time controls guy, part time Niagara user. Started my career using AX for many years, moved controls companies and didn’t use Niagara for quite some time. Went back and got my N4 cert a few years ago and have only used it a handful of times since.
My issue right now is when I’m duplicating controllers, I’m having issues with objects polling data from controllers and it looks like it’s pushing down values from the copied controller to the new ones. This is on an MSTP network with Siemens DXR VAV controllers.
For example, I have analog writable points for airflow setpoints on a VAV. I duplicate the device and either change the new device ID or do a discover and match devices. Then I’m seeing the setpoints match the original controller setpoints. I’m also seeing several points in fault. I’m trying to get ahead of this by posting this today so I should be able to attach some screen shots tomorrow.
On the same project, I also have some 3rd party integrations to Aaon units with VCCX-454 BACnet/IP controllers. There are some points that the name ends in “override” and appear to work as an override to some of the outputs. However, when I release these to auto and it looks like it’s writing null, the output stays at the last overridden value and I can’t get it to release to point to automatic(fan speed in one case). I’m not sure if I should be troubleshooting the niagara side or jump to the manufacturer.
I’m thinking maybe I need to setup some tuning policies rather than the default. Not sure else where to start.
I didn’t fully figure out what was going on with the VAV controllers and why straight duplication didn’t work, but I did find a few issues. I had some points that just needed to use the “Set” command to change the fallback value and when I was testing this it left values in the fallback for that VAV. When I copied the blocks, it copied them with the fallback values and wrote them to the next VAVs. This is bad for things like airflow setpoints. So I ended up just going in and setting the fallback to null using the checkbox. When copied, it will read the value and then still allow for writing to the value at the fallback priority. I also had a numeric writable block I used for a point that was not writeable. Even though I hid all of the override actions, those blocks faulted because the point was not writeable and I think that block was trying to write to the point when created.
Ultimately the best workflow I found was:
Get all of the blocks configured exactly as they need to be with histories, alarms, override access for each type of controller. In my case I have 2, 1 with CO2/RH/Temp sensors and 1 with just Temp.
Discover the devices and add them to the network, move them to controller folders if using.
Copy the blocks from the points folder in the wire view and paste into other points folders for same style devices.
Use program service enable histories, add graphic views (new slot), etc.