Skip to main content.

Software

Although a significant amount of hardware / electronics has been created, it is useless without any software controlling it.

When I started with the design of my system I wanted to have full flexibility. I could go for a microcontroller based design, with embedded software in it, so you would not need a PC. But I have various PCs hanging around in my house, so why not use one of them (in a network configuration) for controlling your home brewery?
In this way, I have lots of flexibility. If I want some new behaviour built into my brewing program, I make an update, test it and distribute to the PC in the brewery.

Then there is always the question of the programming language to use. I do not really like the new programming languages like Java and C#/.Net (I never ever used a MS programming language and I never will!).
I normally write my programs in the C programming language, but I definitely needed a nice front-end GUI (windows, menus, all the stuff). C in itself is not really suitable for that. The solution however was to use the C++ programming language, you can use your existing C libraries and also build a nice looking program.
And if you use Borland's very very excellent Borland C++ Builder, programming becomes a lot of fun!

So the configuration is chosen, the programming language is set. What to do next?
Well, I can tell a bit about the internal structure of my brewing program (which I have called e-brew! by the way, which stands for electronic brewing).
This page consists of the following paragraphs:

1. Overview / Architecture


This picture shows the software architecture. I have tried to design it as modular as possible, so that if I ever change hardware or I2C devices, it is relatively easy to update the software.

Back to the Top of the Page

2. Main Interrupt Loop

The ebrew application needs to have tight timing requirements, since several AD conversions are done. In order to minimize noise, the AD conversions should take place at fixed time-periods. It would be nice to have a real-time embedded operating system, but Windows is far from being real-time or embedded. Fortunately, there is a nice little C++ object, called Animation Timer (TAnimTimer) that assures accurate timing down to the millisecond (0.001 second). And this is sufficient for our purposes.

So I placed this timer object on the Main Form of the ebrew application, and used the OnTimer() event to generate my Main interrupt loop. No matter what happens within the ebrew application or within Windows (besides a complete system crash), the main interrupt loop is always called every 50 milliseconds (which is 20 times per second). This is therefore the main time base within the ebrew application. Everything that is done, is related to this 50 msec. interrupt!


This picture shows a so-called structure chart of the main interrupt loop (which is called t50msec2timer()). It shows when and which functions are called from within this interrupt loop.
The main interrupt loop is called every 50 msec. But it is not economic nor desirable to do everything at the same time. For example: the PID controller function should only be called once every 5 seconds. And it is not useful to update the LED displays every 50 msec., once every second is more than fast enough.
This means that we can divide the main interrupt loop into time-slices. In every time-slice, a particular function is called. In this way, we can divide the processing of functions over time.

Since we have 20 interrupt calls per second, it makes sense to create 20 time-slices, in the structure chart they are numbered from TS1 until TS12 (TS13 till TS20 are not used yet). In time-slice TS1, a call is made to the function get_analog_input(), which retrieves the HLT volume from the AD-converter. In time-slice TS2, the same function is called, but then to retrieve the MLT volume. And so on.

Only the function Generate_IO_Signals() is called every time. This function sends some binary signals to the electronics (e.g. the Alive LED which is on for 500 msec. and off for 500 msec.).

Back to the Top of the Page

3. State Transition Diagram

According to the free online dictionary of Computing, a state transition diagram (STD) is a "A diagram consisting of circles to represent states and directed line segments to represent transitions between the states. One or more actions (outputs) may be associated with each transition.".

In terms of my brewing program, a STD is a central function, which controls the various phases of the brewing process. A state can be a 'mash rest' phase or a 'mash preheat' phase. A transition from one state to another state can be made if a certain condition is met (e.g. the 'temperature is ok'). When a transition is made to another state, a particular action can be programmed (e.g. set pump on).

Summarized: there are states, transitions between states, conditions and actions. These need to be defined for the brewing program.

The first thing to do is analyse the process and derive the unique states. For the brewing program, these states are:
The red lines in the picture are the conditions. If such a condition is TRUE, a transition to the other state is made. During this transition, the action (the green lines) is executed.
The table (upper right corner of the picture) shows which valves need to be open (1) or closed (0) in a particular state. By designing such a table, the behaviour of the various valves becomes very defined. You always know exactly when a valve is open or closed, given the state the STD is in.

There are many more details to tell about this state transition diagram, but this will be sufficient (I hope) to give you an idea about the functionality. The STD is called once every second from the main timer interrupt loop.

Back to the Top of the Page

4. Graphical User Interface (GUI)

The main interrupt loop and the state transition diagram are the heart and soul of the brewing program. But to make this flexible and easy to use when brewing, a nice front-end GUI is needed. Well, here is a screen-shot of the ebrew program:

There is a lot of information displayed on this screen, which is ideal when you are brewing and you need some specific information:

4.1 The menu-bar of the ebrew program

The menu-bar of the ebrew program contains the following menu-items:

Back to the Top of the Page