Style, Tips, and Techniques

The NFCS provides a very limited set of choices for programming in that there are only three types of rules. Sometimes, it may take several rules to accomplish a simple task. However, there are techniques that can reduce the number of rules and make system behavior easier to understand.

Tip #1: Use discrete outputs to hold true / false information

Very often there will be rules which result in a true / false value which will be used by subsequent rules. For instance, there might be a rule that determines that the outlet of the wood boiler is hot enough to be useful. You could create a variable named WoodBoilerHot and set it using a differential rule something like this:

This works, and because differential rules have an implied default of FALSE, the WoodBoilerHot variable will be set to false if the condition is not met. The situation is a bit more complex if you're using logical rules, since you'll need an initial rule to set the variable to false:

While both of these rule sets work, there are two reasons to use a discrete output instead of a variable to hold the WoodBoilerHot value:

1. Discrete outputs default to FALSE. There is no need to have an initialization rule.
2. The discrete output can be connected to an LED, or you can use one of the existing LEDs on the controller front panel. In this way, the value is visible. In this example, we could rename LED 1 on the front panel to WoodBoilerHot and put a label on the front panel. The status of the wood boiler would then be visible at a glance.

Tip #2: Think about important system states

Chances are that there are many system states, conditions, or modes that are important in defining or describing system operation. In programming, it helps to create variables or use discrete outputs (see above) to carry information about those system states.

For instance, one very common and important question is whether there is any heat demand. There may be many rules which depend on the question of whether any zone is calling for heat. For example, there might be a circulator that needs to run if any zone needs heat. With three zones and no system state logic, the rule set might look something like this:

That's not too bad, but the rules do look a bit repetitive. The situation becomes much worse if the circulator is only supposed to run if there is heat available form the wood boiler or heat storage. Assuming an aquastat on the boiler and storage tanks to indicate that here is heat available, the rules now look like this:

While this achieves the desired results, it's is now starting to feel cumbersome and difficult to understand. It only gets worse as additional rules and conditions are added. A better approach is to use two discrete outputs to carry system state information. The first will be true if there's any demand, and the second will be true if heat is available from storage or the wood boiler. Here's the resulting rule set:

As an added bonus, we can get a visual indication of these states if we use a discrete output that's connected to an LED. In this example, we could use LED1 and LED2 on the controller front panel and rename them to 'Demand' and 'HeatAvailable'.