It always seems like there are way too many projects to work on in the home brewery.

I'd love to have built that counter-pressure bottle filler and I have the parts to do it but ...

And I still haven't finished my LPG tank conversion into a stainless fermenter, nor have I sorted out the conical shell I have for another fermenter...

And I've now done enough on the bar to allow myself to be distracted by other things ...

There are many loose ends on the BrewTroller sculpture that need sorting out. The solenoid valves need a bit of work so that I can effectively fill both mash tun and hot liquor tun and also provide a system drain point for storage, so liquor does not stay in pipes and stale.

I continue to have problems with the BrewTroller dropping out with back emf spikes from the solenoid switching. I'd really like to sort this out so that I can concentrate on brewing rather than getting back to a restore point on the BT. There are at least two things to do here - put some filter capacitors on the rotary encoder switch, and put in some filtering on the one-wire bus.

Then the pressure sensors need some attention. I suspect I am getting some pressure leaking but I also need to add some filter capacitors to the sensor. I'd then like to do some solid testing of temperatures and levels so that we can improve the level readings for the BT community.

But right now I'm not even doing work on the sculpture but rather I'm engrossed in coding for BTremote. Now that the program can load data from a ProMash file, it is close to getting recipe data uploaded to the BT without the need to use the rotary encoder for data entry. Being able to do this will be satisfying personally but will also probably please a lot of other BT users. And then after that it will be adding support for BeerSmith, and then enabling more robust control of the BT via BTremote and eventually the web.

The source code and latest build versions of BTremote are available at Google code and the wiki and forum at brewtroller.com are also a great source of information.

So many things and so little time ...

In many ways the VB6 code that used to run HERMAN was a hashed and patched together experiment to see test what the program needed to do. If you like it was an on the fly experiment to determine the feature set.

Coding like this has its problems, the least of which that it became very difficult to maintain, especially when there were large shifts in the way things were done. The VB6 code has many sections of orphaned code, relics of old control systems or symptomatic of a change in mind. Add to this that I'd never learnt to code in VB in any formal way, so many things were done without realising the consequences - like not explicitly declaring variables because I didn't need to, which made for nightmares later on trying to find bugs.

' Full Session Control
' - Quick Test
' - Mash
' - Boil
' - Cooling
' - Cleanup
'
GetMsg test.txt a

wait 10

lblProcess Gates_closed
gHLTout 0
gMTout 0
gMTin 0
gKETout 0
gACCin 0
gACCout 0
gCFCflow 0

One of the features of the last HERMAN system was a built in scripting language to automate as many aspects of the machine as were needed. Above there is an example of the start of one of the scripts. The script ran through line by line showing messages on screen to remind us of things we might forget, and it automatically controlled as much of HERMAN as it could. It was fabulously successful, although difficult to change or adapt because a reference was never written anywhere except in hard code.

In the re-coding, it has been much easier to take a step back to get perspective, and then make sure a discrete feature (like serial communications) is working properly before the next feature is implemented.

When I thought about the scripting language, I wanted to find a way to make it as simple as possible to write the control script. I'm finding that intellisense has improved a lot between visual studio 2005 and 2008, and so a way of implementing a feature-set like intellisense seemed logical.

I'm not a C# coder, but I found this DIY Intellisense article on codeproject. It was pretty close to what I was after. The script language is stored on a treeview control, and both a listbox and tooltip complete the information package. While the code could have been interoped into the HERMAN project as it is, I decided that converting it to VB would give me a greater appreciation of the code and how to customise it to my own needs. I've not quite finished the custom work, but I'm pleased with the results so far.

Like Microsoft Intellisense, HERMAN intellisense is activated when the '.' is pressed. Just in case we have forgotten what the root options are, pressing F1 at the start of a line will pop up a listbox of the root command names.

Once a valid root name is typed or selected and the '.' is pressed,  a node listbox pops up showing all options for that command. In the case above, the control node refers to the HERMAN control panel, and the hlt_heater sub-node is one of the control options.

When a parameter requiring a value is selected, pressing the '(' will open a tooltip that tells the user what is expected. In this case the command line will set a temperature target for the hot liquor tun heater, providing the prompt is followed to completion.

The intellisense has been both fun and satisfying to add in to the HERMAN feature set. Now the harder work of implementing the script needs to happen.

If there is interest I will post the code on the file section of the blog site. Otherwise check out the C# tutorial under codeproject.

I guess I'm a geek at heart, but I love coding. I think there is something special about the power held within a few lines of code. When that code instructs machines to talk to each other and then do things in the physical world it is even better. As a result, I'm like a 'pig in a puddle' now that I'm getting into some serious code construction for both the picaxe and the PC.

I've begun to implement a few intelligent processes in the picaxe. The previous versions of HERMAN relied heavily on PC decision-making, but as version 6 is meant to be able to function on its own, it is already capable of more than previous interfaces.

Kettle Power-band

One addition has been a feature that I've called an automatic kettle power-band. When we are filling the kettle after mashing, we go through a regular process where the kettle power is at 100% until just below the boil point. We then wind the power back to about 80% until it begins to boil, at which point we settle at about 65%.

The idea of the power-band is for the picaxe to automatically adjust the power level depending on kettle temperature. To begin with we have settled for three power-bands:

1. Up to 95 deg C - power initially at 100%
2. Over 95 and up to 98 deg C - power initially at 80%
3. Over 98 deg C - power initially at 65%

Hopefully this feature will help avoid boilovers although that remains to be seen. It might need some extra attention for that to work such as a lower power level for the first 15 minutes of boiling, but that remains to be seen. I intend to report back after the next brew about how effective it is.

The power-bands are still variable, the difference is that the kettle now automatically runs through three phases in the boil sequence. If, for example, we wanted to run the kettle at 75% power for a slower than normal fill, any power adjustment that is done while the kettle is less than 95 degrees will affect only the first power-band. This means that the kettle will automatically switch to 80% and 65% as it moves through phases 2 and 3. As another example, if we determine that 60% is a good rolling boil on a hot summers day, only the third power-band will be affected by this adjustment if the level is set while we are at boil.

The following picaxe code snippet shows that how I've dealt with the three distinct power phases.

subSavePowerBandSetting:

    'work out which power band we are in based on kettle temperature and then save it.
        
    get SP_wKetTemp, word wTemp    'get current kettle temperature
    if wTemp < 950 then
        'we are in powerband A
        put SP_bKETpwrBandA, bKetPwr
    elseif wTemp < 980 then
        'we are in powerband B
        put SP_bKETpwrBandB, bKetPwr
    else
        'we are in powerband C
        put SP_bKETpwrBandC, bKetPwr
    endif
       
    return

Pump hysteresis

With the 28X1 I've got the temperature probes updating every second via the one wire read commands. This means that the mash temperature might oscillate +- 0.1 degrees each read, which at times has caused the pump to turn off and on each second.

I've added some new picaxe code to keep the pump running until mash temperature is hit, and then not coming back on until it drops 0.2 degrees. It may only need a 0.1 hysteresis as temperatures are very stable with the ds18b20s while mashing, but that is a simple code change.

        '==================
        '1. Pump management
        '==================
    
        'check to see if pump is operating under auto control
        if btPump=1 then    'pump is on - operate in auto off/on mode depending on temperatures

            'get temperature and setpoint values
            get SP_wMashTemp, word wTemp    'save value
            get SP_wMashSet, word wSetT
            
            'If mash is over set temperature, the pump cycles off
            if wTemp >= wSetT then    
                'pump is off (set output status to off and leave switch in on position)
                low oPUMPssr
                'sertxd ("pump off ", #wTemp)
                
            else
                'add in some temperature hysteresis (0.2 deg C)
                wSetT=wSetT-2
                 if wTemp < wSetT then
                    'pump is on (mode=1)
                    high oPUMPssr
                    'sertxd ("pump on ", #wTemp)
                endif
            endif
            
            'put SP_bSSRstatus, bSSRstatus
            
        endif

Graphing

As mentioned in the last blog entry, the coding for graphing has been improved. I'm using zedgraph to provide nice graphs of temperatures over time. Pressing the 'live' button starts logging to a filename based on the current date. A new log entry is created every 20 seconds and the graph updates when each new record is logged.

Any previous log file can be reviewed by pressing the 'review' button, the difference being it does not update like a 'live' log.

The graph above shows a test done using water recirculating through the heat exchange coil in the hot liquor tun and returning to the mash tun. With the HLT averaging 70 degrees C, the mash liquor hit 66.5 degrees C when everything was stable. This means that the system heat loss at these temperatures is 3.5 degrees C. The system heat loss looked to be around 5 or 6 degrees at mash out temperatures but the test was inconclusive due to insufficient time for the system to stabilise.

Communications

The most significant coding changes since the last blog entry are to do with communications. I am slowly learning about the vagaries of the serialport under .net. The code now reads about 95% reliably and is quicker to right itself than before. I am happy for the moment, but it really needs to be coded asynchronously, which means I have a bit more learning ahead of me. I found a promising tutorial about this here.

Next steps

As far as coding goes, the next step is likely to be getting two-way communications going so that the PC can update the picaxe.

Probably the next hardware step will be to find out why the LCD module is not working. At the moment the PC is functioning as our information screen. Beyond that I think we will begin work on the various tun modules which incorporates features like level sensors and floats.

As I begin this blog entry, HERMAN is up and working again and is in pre-heat mode, ready to brew.

I'm not in the laundry where we brew, but can see what is happening on the machine via Windows remote desktop. The mash liquor is currently 65.8 degrees C, and I'll be ready to dough-in when it reaches 72.

It has been so much easier to fine-tune things from my main PC compared to the laptop in the laundry. I've even enjoyed coding in VB.NET 2008 thanks to tutorials and code samples from Dr_Acula and Garrett.

I've figure the machine is currently in an alpha state because there are still features to implement. The LCD is not yet functional, so I'm relying on the VB program to tell me what is going on. The new control panel is a dream to use, especially when coupled with the X1 processor. The main control board is still built on an experimenter breadboard, but it seems to be very reliable so there is no rush to design a final PCB.

(The mash liquor is now 67.2 degrees C.)

I've posted the code for both the picaxe and the VB monitor here. At present the VB code is only a rough monitor of picaxe communications. It cannot control the picaxe yet, although that is probably the next feature I will implement. It doesn't log data but that too is high on the list for coding.

Anyway I'm very happy to have reached this point. From here the feature set just makes for more pleasurable brewing.