Home
Wood Heating
Choices
Data
System Design
Controller
Control Logic
Software Design
Electrical Schematic
Simple system w/ storage
Domestic Hot Water
Heat Storage
Solar Hot Water
Introduction
System Components
User Guide
Programming Guide
Failsafe Design
Sample Application
LM35 Sensor Assembly
Pinout Info
Poor Man's VS Circ
Journal
Plastic Pipe Collector
Thermistors
Forum Solar-TodayWood-TodayBurn Planner
<Prev Table Of Contents Next>

Introduction

This document is a guide to programming the NFCS. It is a companion to the sample application document. This document is focused on the process of creating, testing, and fine-tuning the rules that determine NFCS behavior.

Software Architecture

A detailed knowledge of NFCS software architecture is NOT necessary in order to program and use the system, but it can be helpful to understand the basic components that make the NFCS work. If you want to jump immediately into creating rules you can skip this section.

The NFCS software makes use of shared memory and configuration files. There are several tasks which communicate via a block of shared memory. Each task can also read configuration files from disk as needed. Tasks are completely independent of each other and do not communicate except through shared memory.

For example, there is an I/O task which manages all of the physical inputs and outputs. It reads all of the sensors and discrete inputs and puts their values into shared memory. It reads values for discrete outputs from shared memory and sets the physical outputs accordingly.

In order to do this, it reads data from configuration files to determine what types of sensors are connected and what calibration values should be applied to the raw sensor signals.

This task does not depend on any other task. It doesn't know about rules or datalogging or anything else. You as a programmer cannot communicate directly with this task. Your interaction is entirely through the web interface, which allows you to change the contents of the configuration files.

In the same way, the control task(s) don't have any direct interaction with the physical hardware. They read the rules from configuration files, and read and write values to shared memory.

Configuration Files

All system behavior is determined by configuration files. The configuration files are simple comma separated value (csv) files that can be downloaded into a spreadsheet. In fact, you could configure and program a NCFS system by simply editing the configuration files with a spreadsheet or text editor. You can see the contents of any configuration file by clicking on it on the 'System' tab of the Web Interface.

Control Task

In programming, we are concerned with defining the behavior of the 'control' task. That task reads several configuration files that contain rules. It then implements the logic defined by those rules based on values in shared memory, and sets specified shared memory values as a result.

Shared Memory

Shared memory contains four types of data:

  1. Values for physical inputs and outputs
  2. Variables that are used by the control task
  3. Flags that tell tasks to take specific actions
  4. Command and status data for individual tasks

Any task can read any data that it needs from shared memory. However, only a single task should write data to any specific shared memory location. There are some exceptions, but in general each value is 'owned' by a specific task that is responsible for writing data to it. For instance, the I/O task is responsible for writing sensor data into shared memory.

<Prev Table Of Contents Next>