Restarting the server is causing my points to go null/off?

Owned by Christopher Simonian
Last updated: Aug 12, 2021 by Kimberly Cruz (Unlicensed)
3 min read

Problem:

When FIN is rebooted, all priority levels that aren't 1, 8, or def get nulled out.

  • If there isn't any other control logic or function in FIN writing a value to the priority array, that value could stay null until intervened. 

  • If FIN is being used to control another system, such as a Niagara station or a BACnet controller, it could write that null value down to the point in that lower system or device.

Similarly, when Niagara is rebooted, all Niagara priority levels that aren't 1, 8, or Fallback get nulled out if there isn't any other control logic or function in Niagara linked to them to rewrite the value. This is because only slots In1, In8, and Fallback are persistent properties. All other slots in the priority array are set as transient properties.

  • If FIN is writing to level 16 in Niagara, and the Niagara station is restarted, In16 will go to null until the next time FIN Stack writes the value again. 

By default, FIN will write to priority 16 in Niagara, so when/if the FIN server is rebooted, it might send out a null to In16.

If there is control logic in Niagara that is linked into In16 as well, whoever gets the last write to the input wins.

  • So if FIN is restarted, then it sends a null to the point(s), and nulls out any control logic on those points until the next write (whether that write comes from Niagara or from FIN)



EXAMPLE:

In the example below, we show basically what is happening in the background. 

The Niagara control logic is writing to In16...and FIN is also writing to In16.

Basically, whoever writes last wins. 

Solution:

To resolve this, there are a number of steps that can be taken to ensure that something is in control of your points, and nothing goes to a null or off state on accident.

  1. You should only allow one system to be in control of your facility. If you are using FIN as the controlling system, you should not have anything in Niagara that is taking control of your points. If you have purposely put some control functions in Niagara that might compete with FINfor control given certain unusual circumstances, you should ensure that FIN is always writing to the priority array at a level higher than anything in Niagara.*

  2. In your Niagara points, you should ensure to set default values so that setpoints and equipment fail to a known and deliberate state or value. 

  3. In FIN, connected writable points should also be set to have default values. That will ensure that upon a FIN restart, some specific value will be written to the connected Niagara points and not a null value.


*In FIN, there is a connector feature that allows you to assign a defaultWriteLevel to the connector.  If you do that, whenever any point is added from the connector into the FIN database, it automatically gets the assigned priority set in its bacnetWriteLevel or haystackWriteLevel.