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

Controller

Introduction

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:

  • TS7260 Controller Board
  • AD9700 Analog Input Board
  • DIO64 discrete I/O Board
  • Thermistors
  • Relays

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.

Power

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:
FunctionWattsduty cyclewatt-hours/day
Controller system5100%120
Circulators10042%1000
Furnace Fan15017%600

Controller Board

The TS7260 is a single board computer that supports the PC-104 expansion bus. That allows additional I/O cards to be added. More information on the card is available here.


Software

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/O

The following I/O is available to the system:
Analog InputDescription
Storage tank bottomTemperature 6" above external storage tank bottom
Storage tank middleTemperature at midpoint of external storage tank
Storage tank topTemperature 6" from top of external storage tank
Solar inTemperature at storage tank inlet from solar panel
Wood outTemperature at outlet of wood boiler
Wood inTemperature at inlet of wood boiler
Oil outTemperature at outlet of oil boiler
DHWTemperature of domestic hot water heater tank, at midpoint
CombustionWood boiler combustion chamber temperature
Digital InputDescription
'Demand'High-priority zone (living space, DHW) needs heat
Hot Tub WarmHot tub is at desired temperature
Hot Tub ComfortIs heating the hot tub a priority?
Oil/Wood switchHas user elected to disable oil burner?
DHW WarmIs the Domestic Hot Water tank at temperature?
Top Floor WarmIs the top floor of the house warm?
Main Floor warm?Is the main floor of the house warm?
Bottom Floor WarmIs the basement warm?
Digital OutputDescription
DHW forceForce the DHW zone valve open - superheat the DHW tank
Hot Tub ControlAssert computer control of hot tub zone valve
Wood mode forceDisable control inputs to oil boiler
Wood recircOpen bypass valve to allow water recirculation through wood boiler
Tank circulatorTurn on storage tank circulator pump
Tank Zone ValveOpen storage tank zone valve
Hot Tub Zone ValveOpen hot tub zone valve
Oil circ forceTurn on oil boiler circulator pump

Software Architecture

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.

  • Power failure is addressed above.
  • Network failure tolerance is accomplished by having a skeletal /home directory 'underneath' the /home mount point, so critical files are available even if the network is down. None of the executables perform any file I/O except at startup.
  • Abnormal termination is addressed by partitioning the software into small, simple, and independent programs.

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.

  1. I/O Task: A very simple C program running as a 2Hz background task that handles physical I/O and low-level (think brainstem) control functions.
  2. Control Task: A higher level C program running about once every 30 seconds that contains the higher level / more complex logic and control functions
  3. Datalogger Task: A C program that performs datalogging - writing selected data to a relational database on a remote server.
  4. Web Interface: A CGI script in C that allows a web user to view system status and set various control parameters

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.

Shared Memory

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.

I/O Task

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.

Control Task

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.

Datalogger Task

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.