The controller for this system must provide the ability to perform all necessary I/O while being highly reliable and consuming very little power. One of the primary goals for the system is that it continue to operate safely despite any reasonably likely failure. Thus, the controller itslef must be reliable, and the entire system (controller, circulator pumps, fans, relays) must be able to operate from batteries for at least 24 hours.
The controller hardware consists of the following components:
The controller has evolved over the past few years and is the basis for the open source NoFossil Control System (NFCS). This site has a section devoted to the NFCS, while this page describes the development process that led to the NFCS hardware and software.
One of the reasons for choosing the TS7260 is that it has an onboard regulator and will operate happily on supply voltages anywhere between 4.5V and 20V. The heating system is designed to operate from a pair of 12V deep-cycle marine batteries, which conservatively provides 2000 watt-hours of usable power. The circulator pump and furnace fan are 110V, and will operate from an inverter. This imposes a penalty because the inverter causes some loss. The anticipated system power budget assumes one 4-hour fire and 10 hours of circulator operation. The power budget is as follows:
This section describes the software design. There are also pages that describe the logic and operation of the software:
Environment: Controller Card
The control system software runs on a Technologics TS-7260. This card comes with a stripped-down Linux installation in flash memory including the Apache web server. The processor is a 200MHz ARM-9. It has 32mb of ram and a 32mb flash drive. This places constraints on the size and complexity of software that can be used. The card will boot up to a serial console as delivered.
The first task is to configure the card. Initial configuration of the card includes network setup, installation of libraries, web server configuration, and other tasks. Software development is performed on a Linux workstation, and files are stored on a Linux server which also hosts a MySQL database. The /home directory from the server is mounted as /home on the TS7260. Executables and the TS7260 webserver are configured to run from directories under /home.
On the other side of the Atlantic, Jim Jackson has done great work in figuring out how to work with these cards and documenting his findings. His ARM web page is a valuable resource. In particular, the cross-compilation techniques that he describes are the foundation for work on this project.
Environment: External Hardware
In addition to the resources of the controller card, the system has two TS-9700 A/D cards providing a total of 16 channels of analog input and a TS-DIO64 providing 64 channels of digital I/O.
The oil boiler and wood boiler both have their own built-in controllers. These controllers manage combustion and circulator pump operation when either boiler is operating. These controllers are independent of the TS-7260. The software has no access to their internal states and no direct ability to affect their operation.
Environment: I/OThe following I/O is available to the system:
The TS7xxx cards are remarkable, but they do have their limitations. Limited memory, no hard disk, and no floating point all limit the card's ability to act as a general purpose computer. The software architecture must take into account these limitations as well as the most important design goal: The system must be able to perform it's basic control functions despite any reasonably likely failure. For the purposes of this discussion, 'failure' includes network failure, power failure, and abnormal termination of a software task.
Small, simple programs are easier to test and are more reliable than large programs. In this design, programs are completely independent, and communicate with each other through a 'shared memory' area described in more detail below. Only one executable is truly necessary for basic control functions.
These are the four basic programs. There are links provided to the actual source code for each.
All the software is under development, and may not agree perfectly with the web site. The web site reflects design goals, while the software may not yet implement all the planned functionality. Source files are available here. The initial implementation is a simple solar hot water heater with a circulator pump managed by the controller.
All of the above programs communicate and share data via a shared memory area. Only the I/O task interacts with the actual hardware. In the distributed Linux kernel, shared memory areas appear to be limited to 256 bytes. Shared memory contains two arrays: one array with three values for each analog input, and a second array with two values for each block of eight digital I/O lines.
Analog inputs are 12 bits. The shared memory area has a 16 bit location for the raw value as read from the card, and a floating point location for the calculated temperature. There is also a character location that contains status information (out of range / inactive).
The digital I/O array has an entry for each block of eight I/O lines. Each block contains a byte for I/O values and a byte to define direction for each line.
This task is launched at startup. It reads thermistor lookup table data and calibration data. It creates the shared memory area that all tasks use.
It also handles all basic safety-related logic (circ pump control, fan control, safety interlocks, overtemp) so that safe operation can be assured with only this program running.
In the initial implementation, this task reads analog values from the TS9700 into shared memory, and performs digital I/O to and from shared memory.
This module contains the mode logic that sets zone priority, makes oil/wood decisions, and determines major and minor operating modes. It does not communicate directly with hardware, only with shared memory.
The datalogger simply reads data from shared memory and writes it into a database. For a sample of logged data, visit the performance data page.