[Frosty72]

I had an unusual problem that happened to me today. I received a call from our C Suite saying it was musty and stale. When I arrived I found all the VAV controllers were in unoccupied mode and driven shut. When I went to the wire sheet on the JACE I found the schedule was outputting an occupied command but all of the connected controllers were in unoccupied despite the command to go occupied. To fix it I had to reboot the JACE then manually set all the points to occupied. Even after rebooting they were still unoccupied with an occupied command. I'm thinking it must have been Gremlins. I have a time until next change of state field on all of my graphics pages which was showing -7670 minutes. I guess they were expecting to change 5 days ago, received the command, but for some reason they did not change. This happened on an older AX JACE running 3.7 with a bunch of Trane VV550's on a LON trunk.

I'm having another strange issue as well with the same hardware. Sometimes the controllers will lock up due to generator tests and power bumps. I'll send them a reset command to get them going again. When I send the reset command it always breaks one of the links on my wiresheet. I always have to go in and delete the broken link and add a new one to get it working again. Maybe someone got the Gremlins wet?

 

[lwarren]

Did you look in the Lon Link Manager to see if you have any unbound points?

 

[ccjb100]

SO I'm having almost this exact problem and was about to make a post about it. In my case its a completely different type of system. I have a recently upgrade 4.11 windows supervisor station. It has a number of air handler schedules, where the output links to the VAV occupied points. In my case these are BACnet devices and the schedule output is linked to in16 for the VAV's occupancy command. Since the upgrade of the station, small groups of vav's are randomly NOT going occupied even through the schedule is occupied. Everything appears completely normal with the exception that it's like the niagara links are not propagating the value from the schedule output into the in16 of the associated proxy points. This is not consistent however. The next time the schedule toggles then it may work just fine. The past two days it's been like this. It's the strangest thing. I would be very curious to see if you find anything.

 

[Right Control]

SO I'm having almost this exact problem and was about to make a post about it. In my case its a completely different type of system. I have a recently upgrade 4.11 windows supervisor station. It has a number of air handler schedules, where the output links to the VAV occupied points. In my case these are BACnet devices and the schedule output is linked to in16 for the VAV's occupancy command. Since the upgrade of the station, small groups of vav's are randomly NOT going occupied even through the schedule is occupied. Everything appears completely normal with the exception that it's like the niagara links are not propagating the value from the schedule output into the in16 of the associated proxy points. This is not consistent however. The next time the schedule toggles then it may work just fine. The past two days it's been like this. It's the strangest thing. I would be very curious to see if you find anything.

I always set a schedule tuning policy. This ensures a write after the max write time has expired. If you miss a write for some reason it will re-write and command occupancy. This has solved this for me.

 

[ccjb100]

I always set a schedule tuning policy. This ensures a write after the max write time has expired. If you miss a write for some reason it will re-write and command occupancy. This has solved this for me.

Do you mind clarifying this? How is it you set a tuning policy for schedule specifically? I'm assuming you don't mean the "execution time" that keeps an exported BACnet schedule linked to a Niagara schedule. We have that. The issue with these is the out of the scheudle links to inputs of other proxy points, and these occasionally don't change. Does setting a "max write time" in the regular BACnet network tuning policies cause wiresheet connected inputs of proxy points to update?

 

[Right Control]

Do you mind clarifying this? How is it you set a tuning policy for schedule specifically? I'm assuming you don't mean the "execution time" that keeps an exported BACnet schedule linked to a Niagara schedule. We have that. The issue with these is the out of the scheudle links to inputs of other proxy points, and these occasionally don't change. Does setting a "max write time" in the regular BACnet network tuning policies cause wiresheet connected inputs of proxy points to update?

Maybe I'm mis-understanding? So your link to the VAV box lets say BV:OccMode connected at priority 16 is going true from the schedule? But your out value is staying false if viewed from the property sheet of that point? That's what I've seen when the occupancy misses the write. Being a twice of day change your sunk until the next state change. JCI FX has a tuning policy called network input policy. Basically a re-write at the max write time interval. On non JCI jobs I duplicate the default tuning policy call it schedule policy and set the correct parameters. Then attach that policy to all my BV:OccMode points. Maybe were speaking something different here?

 

[ccjb100]

Maybe I'm mis-understanding? So your link to the VAV box lets say BV:OccMode connected at priority 16 is going true from the schedule? But your out value is staying false if viewed from the property sheet of that point? That's what I've seen when the occupancy misses the write. Being a twice of day change your sunk until the next state change. JCI FX has a tuning policy called network input policy. Basically a re-write at the max write time interval. On non JCI jobs I duplicate the default tuning policy call it schedule policy and set the correct parameters. Then attach that policy to all my BV:OccMode points. Maybe were speaking something different here?

So the problem is back one step from what you describe. It's the out value of the SCHEDULE that isn't propagating through a link TO the in16 on on the proxy point. So on a wire sheet you would see the OUT from the schedule show occupied, then you follow the link to the in16 on the proxy point....but it will still show unoccupied at at in16....it somehow it hasn't gotten the value through the link. This happens to just a handful of random points (although they tend to all be consecutive/back to back points, perhaps 5 or ten points) at each schedule change....but it's not always the same ones, so it's like sometimes it works and sometimes the value doesn't get through on a handful of points. It seems like there should be something built into the logic that would realize a value hasn't propagated through a link and then update it on another 'pass' through the program. This doesn't seem to be the case. It's very strange and quite frustrating. Its happening regularly since i upgraded to 4.11, although i think it was very occasionally happening before that in small amounts. But now it's every day.

I did note last night that the server where this station is running....will about every minute or so show Niagara station launcher shooting up to a very high CPU usage for about 3-5 seconds then drops back down again.

 

[ccjb100]

So the problem is back one step from what you describe. It's the out value of the SCHEDULE that isn't propagating through a link TO the in16 on on the proxy point. So on a wire sheet you would see the OUT from the schedule show occupied, then you follow the link to the in16 on the proxy point....but it will still show unoccupied at at in16....it somehow it hasn't gotten the value through the link. This happens to just a handful of random points (although they tend to all be consecutive/back to back points, perhaps 5 or ten points) at each schedule change....but it's not always the same ones, so it's like sometimes it works and sometimes the value doesn't get through on a handful of points. It seems like there should be something built into the logic that would realize a value hasn't propagated through a link and then update it on another 'pass' through the program. This doesn't seem to be the case. It's very strange and quite frustrating. Its happening regularly since i upgraded to 4.11, although i think it was very occasionally happening before that in small amounts. But now it's every day.

I did note last night that the server where this station is running....will about every minute or so show Niagara station launcher shooting up to a very high CPU usage for about 3-5 seconds then drops back down again.

Update....i discovered tonight that when certain system graphics are being displayed the niagara station launcher CPU spikes and stays at 100%. This matches the CPU usage in the station resource manager. Specifically VAV summary screens. In this case it's Distech Envysion for EC-net, and on the display are a series of node lists. I am starting to think the maxed CPU is jamming up the station causing the links to not work sometimes. I need to dig in to this.

 

[CtrlPuffer]

I would agree with RightControl and say make sure you create a BACnet tuning policy called something like Write5Mins, and set its maximum write time to 5 minutes. Use this policy on the VAV occ point (this is where the work is being done). I have seen the same problem happen when this type of tuning policy has not been used for Occupancy points on a VAV or similar. Also if you were to write to any kind of dumb IO, you need to use a tuning policy with a max write time (not the default 0 seconds, which won't write again).

 

[Frosty72]

It's not a binding issue. Everything is bound on this station. What I've noticed is it seems to be happening with the Trane controllers only. I have some Circons linked to the same schedule that were unaffected.

 

[Right Control]

Update....i discovered tonight that when certain system graphics are being displayed the niagara station launcher CPU spikes and stays at 100%. This matches the CPU usage in the station resource manager. Specifically VAV summary screens. In this case it's Distech Envysion for EC-net, and on the display are a series of node lists. I am starting to think the maxed CPU is jamming up the station causing the links to not work sometimes. I need to dig in to this.

Yeah you might be onto something? Haven’t done a ECnet job with Envysion in awhile. Does it behave better if you roll it back to 4.10? Wondering if something is up with 4.11?


Sent from my iPhone using Tapatalk

 

[CtrlPuffer]

Sorry Frosty, I was responding to the BACnet problem. On the BACnet write issue, there may or may not be another problem too, but make sure first you that the BACnet proxy point on the VAV for Occupancy is setup with a tuning policy as described - max 5 minutes write.

Frosty, sorry I don't do much with Lon.

 

[Frosty72]

I upgraded my supervisor to Windows 11 in February so we have that in common. I had a lot of issues with my new supervisor crashing multiple times per week which I solved by removing the GPU. Something was wrong with either the GPU or the video driver because it hasn't crashed since I removed it. I'm using the integrated Intel graphics which are fine for Niagara. I'm going to try adjusting my tuning policy. This JACE was setup by Trane 13 years ago and I haven't looked at the tuning policy till now. The default policy was set to 0 for min and max. I set the min write time to 5 sec and the max to 5 min. Hopefully it will help.

 

[Right Control]

I upgraded my supervisor to Windows 11 in February so we have that in common. I had a lot of issues with my new supervisor crashing multiple times per week which I solved by removing the GPU. Something was wrong with either the GPU or the video driver because it hasn't crashed since I removed it. I'm using the integrated Intel graphics which are fine for Niagara. I'm going to try adjusting my tuning policy. This JACE was setup by Trane 13 years ago and I haven't looked at the tuning policy till now. The default policy was set to 0 for min and max. I set the min write time to 5 sec and the max to 5 min. Hopefully it will help.

Be careful there. The default tuning policy is attached to all proxy points. If all points are set for a max write time of 5 mins no bueno. You need to make another one by duplicating the default and then attach it to specific points you want to adhere to the new tuning policy.


Sent from my iPhone using Tapatalk