I've been listening to Brew Strong lately and again Jamil and friends have helped improve my brewing. In particular I listened to their yeast starter program and have just pitched the healthiest yeast starter for a lager ever.

The starter was for a Dortmunder lager which was batch #3 on the new HERMAN 7 powered by BrewTroller.

I've blogged about a number of things on the BT site about this brew, but some observations for my own reference:

• To chill to lager pitching temps, I need to use ground water initially and then do the last stage (maybe below 30C) with ice water.
• What I actually did to chill was use the plate chiller with ground water and pumping ice water through it to pre-chill the ground water. It chilled everything a lot quicker than normal, but most of my ice water was depleted too soon. I had to wait a while for the ice bank to restore to get to lager temps and had to pump ice water directly through the immersion chiller to do it.
• Use a hop sack in the boil kettle to minimise hop debris and therefore trub dumping into the fermenters.
• Improve the filter at the kettle pickup to fermenter.
• Wire in the fermenter fill solenoid and remove the kettle pickup solenoid.
• Put a meter on the mash level sensor to figure out what is going on between mash fill and mash empty and record notes.
• Get some air bleed valves so that the March pump primes reliably.
• add a low point drain on the system so it will clear all trapped water.
• Use the retrieved solenoid from kettle pickup to be the mash liquor in solenoid.

All up I was happy with how the brew day went. There is still a lot of debugging to do on the BrewTroller and hardware but it is a joy to use HERMAN 7 and is by far the best HERMAN yet.

Over the last month or two I've radically changed my approach to the brewing machine and its development. I ripped up most of the solid pipe and have been hacking different configurations with hose and miscellaneous bits so that I can test changes and fine-tune before I really commit myself.

Chilling issues

One example of testing in place is the process of cooling the wort from the boil kettle. I've had a plate chiller for a couple of years but I've not been happy with its performance. Even as we approach mid-winter the best I can hope for with a single pass and normal mains water as coolant is for 30 C wort into the fermenter.

The brew day before last I tried pumping ice water from the ice bank through the chiller as wort made a single pass into the fermenter. Balancing both flow rates the best I could manage was 25C wort. About 2/3rds through I had to abandon the test because all the ice had melted from the bank. Back to mains water as coolant and then a further problem. The ice bank was needed to cool my cellar box, and with 42 litres of wort at 25C it no longer had the capacity to cool that down to lager temps.

Time for another test. While brewing on Monday I did the Jamil trick of pumping wort around the kettle (in my case via the external plate chiller) until the wort dropped to 30 C. I then substituted the mains water for water from my ice bank. It was lovely to watch the wort slowly but surely drop to 8 C and be able to pitch instantly onto my yeast slurry.

One issue with this is that the chilling process took forever. I was able to minimise water use though, so there are some trade-offs. What I intend to do next is an idea that came from a local micro. There they use a two stage chilling process. Part A via one chiller is done using domestic cold water; part B via a second chiller is done using glycol (or the ice bank in my case). So the inefficient plate chiller will do for part B, but now I need to buy an efficient plate chiller.

Changing the wort flow path

Because I haven't done this kind of chilling before, I had not really considered the chilling path (the loop out of and back into the kettle). In my current system it goes through the heat exchange coil which I'm not happy about. While I've done some serious PBW cleaning of that coil I'm not convinced it is really sanitary. I will re-plumb the system again to eliminate this as an issue.

Better filtering

Also I need to do a better job at keeping hop debris out of the plate chiller. Some improved filtering on the kettle out and the addition of a proper whirlpool paddle should improve things greatly.

Automated brewing

All these tweaks and changes are heading me towards some serious re-building towards an automated machine. I've been slowly working on the electronics based around the BrewTroller. I've also been busy doing coding for the BT guys to allow remote monitoring and eventually remote control of a BT.

Last week I took the plunge and ordered some valve solenoids from China so things are moving here. I've also had critical eyes on the current setup, particularly with fittings that I'm not happy with and taking the trouble to source the right adaptors that I might need. When HERMAN was first built I did not have suppliers of nice shiny bits at my finger tips, so now is the time to really do this job properly. I'm about to put in a serious order with Beerbelly.

And to top off my spending spree I ordered a couple of zero-crossing solid state relays from Oatley.

I've been spending a lot of time upgrading the code in my remote PC application for the brewing machine. When I first dreamed of HERMAN, I began coding in Visual Basic 3 and had all the 'intelligence' on the PC side of the machine. This was necessary because the first interface was an analog slave to whatever the PC did.

In those early days I had no idea what the ultimate aim for the machine would be and as ideas developed the code had bits and pieces added on until it became difficult to manage.

Then I began coding in VB6 and created a more powerful application with its own scripting language but eventually got to the point where it was difficult to manage. My problem with coding is that I get too many ideas and code just enough until things get done. Usually it means the code is not very elegant with lots of workarounds that ultimately come back and bite me.

With the VB6 program came a new and more powerful interface. Using a picaxe based interface meant for greater options and reliability, but some legacy code meant that most decision-making stayed at the PC end.

The latest version has seen coding in VB.net 2008 and a simpler remote application with as much decision-making as possible in the picaxe chip. This means that for the first time the brewing machine runs on its own without a PC. In fact it has run so well like this that I haven't done any coding at the PC end of things for a long time. It also means that the Windows 'blue screen of death' is no longer a tragedy.

Because the picaxe basically takes care of things, I've had both time and patience to try and code things properly as opposed to whatever workaround will work. I have found it quite painful to learn how to code in vb.net, but I'm getting there slowly.

It was the BrewTroller project that has given me renewed interest in the PC end of things. Because there is interest from others in being able to remotely monitor or control the BrewTroller machine, I've been motivated to tidy up some code.

It is not yet perfect, but the PC application now allows loading of a saved brew session log for replaying. It is quite interesting to see the data like this. The real benefit of this code is that I can test FTP communications when I'm away from the brew rig. The image below shows a picture of how a brewing network might go together. In theory it will be possible for phones and other mobile devices to not only monitor a brewing machine but to control it.

The FTP part of the code is now working in a rough manner. At the moment there is about a 10 second lag time between the main PC uploading data via FTP and a remote PC displaying that data. Soon the machines will be taking over the world

The image above shows the PC on the left sending data to an FTP site, with the laptop on the right downloading the same information about 10 seconds later.

Further to the above, I'm only a few components and a small amount of testing away from getting a solid state ball valve controller to work reliably. Automated brewing is getting closer.

The other testing I'm keen on pursuing is working out the best way to chill the kettle wort to pitching temperatures. I have a number of ideas but need tangible data before implementing a final solution in the brew house.

Other than that, I can report that the gluten-free brewing attempt was a complete disaster, and that the first lager for the season is fermenting away in the temperature controlled cellar at a very nice even 10 degrees C. The summer-time construction of the 'Bavarian cave' has been well worth it.

With renewed inspiration thanks to the BrewTroller guys, I've had a go at another prototype of a ball valve controller.

I've had a long history of dabbling with this idea. Through it I've learned a lot about mechatronics which has been both challenging and fun.

Previous attempts at automating the opening and closing of a standard 1/2" ball valve for a brewing machine have included using a servo motor with string to drive the valve lever; using a servo with gears to increase torque; using a geared motor with feedback pot to effectively build a larger servo.

None of the previous attempts were robust enough to put into the brewing machine. Problems included insufficient torque (especially as the valve gets hot), complex mechanical arrangements, expensive and labour intensive.

Quite some time ago I bought some cheap window winder motors (from car power windows) from a surplus electronics supplier. These things definitely have the grunt to open and close a ball valve no matter how hot it is. The problem with them is that they complicate the power drive arrangement (high current) and that there was still the issue of feedback - that is how to determine what position the valve was in.

I put the project on the  backburner and have been happy to manually open and close ball valves on HERMAN. The BrewTroller project re-opens the issue of how valves will be controlled.

Thanks go to Zizzle for working out a neat and simple feedback mechanism. He is using similar motors to drive his valves, and figured that motor stall current could be detected by an analog input and 'seen' as a valve endpoint.

So ... back to designing an automated ball valve ...

The first thing to do was confirm the motor had sufficient torque to drive the valve. A simple coupling was made between motor and valve arm via some square section aluminium and polymorph plastic to 'weld' things in place. A simple test jig was built from scrap timber and the motor was wired up to a 12V battery via a three position switch (open-off-close).

Success! The motor certainly has a lot of grunt. Here are some figures:

• stalled current 4.25 A
• operate current 1.6 A
• transition time around 500mS

To make the valve capable of being opened and closed by a controller, I decided a picaxe 08M would be ideal for handling control logic. The 08M is a small, cheap and easy to program pic based processor. To handle the switching I found a couple of 12V 5A DPDT relays. I had a ULN2003 in the parts bin, so this handled the interface between picaxe and relays.

The interface looks for an earth to open the valve. This can be either the control line (ie. from a BrewTroller) or with the switch under manual control. A high on the line will close the valve.

The picaxe remembers which state it is in, and if a changed state has been requested the motor drives the appropriate direction for 500mS. At this stage I'm not sensing a motor stall to switch the unit off, but this is simple to do.

And here it is in action ...

And the code:

#picaxe 08m



'     ************************************ 
'     *                                  *
'     *   Ball valve actuator   V 0.01   *
'     *   for automated brewing system   *
'     *           10-May-2009            *
'     *                                  *
'     *        by Arnie W                *
'     *                                  *
'     ************************************


' - uses window winder motor coupled to ball valve
' - and 08M picaxe
'
' high on control input will put valve in closed position
' low on control input will open valve
'
' - motor is only actuated when a change of state is needed
' - control input may be via external microcontroller or 
' - local 'manual' switch

' Define inputs
' =============

symbol iStall=4    'adc input - feedback from motor
symbol iControl=pin3    'high = close; low=open (via microcontroller or local 'manual' switch
        'NOTE: this version does not utilise feedback to 'deactuate' the valve


' Define outputs
' ==============

symbol oActuate=1    'motor on/off control - low=off; high=on
symbol oMode=2    'motor direction control - high=open; low=close


' Define constants
' ================

symbol DURATION=50    'time that actuator is energised (x10 milliseconds)
symbol OPENED=0
symbol CLOSED=1
symbol CLOSING=2
symbol OPENING=3

symbol OPEN=0
symbol CLOSE=1


' Define variables
' ================

symbol bState=b0    'state of ball valve - 0=opened; 1=closed; 2=closing; 3=opening
symbol bCurrDur=b1    'index used during transition


' Initialise
' ==========

' put valve into known state
' - the valve is treated as being open and will apply a close command

' update state and actuate
bState=CLOSING
gosub subActuate


' Main program loop

main:

    'check for change of state
    
    if bState=CLOSED then
        if iControl=OPEN then
            bState=OPENING
            gosub subActuate
        endif    
    else
        if iControl=CLOSE then
            bState=CLOSING
            gosub subActuate
        endif
    endif
    
    pause 10
    
    goto main
    

' Actuate sub

subActuate:
    
    if bState=CLOSING then
        low oMode    'set to close
    else
        high oMode    'set to open
    endif
    
    pause 20        'ensure mode is switched prior to actuating
    
    high oActuate    'actuate motor
    
    ' timing loop
    for b1 = 1 to DURATION
        pause 10    'time in milliseconds
    next
    
    ' transition complete
    low oMode
    low oActuate
    
    ' update state
    if bState=CLOSING then
        'valve is now closed
        bState=CLOSED
    elseif bState=OPENING then
        'valve is now open
        bState=OPENED
    endif
    
    return

We made Jess' party beer on Monday and pretty much everything went to plan. Our dough-in temps are now regularly spot-on which is really pleasing. The image to the left shows the mash liquor at strike, dough-in, and then 60 minutes at saccarification temps. The small blip on the right of the graph is the circulation of colder liquor - liquor that has been at rest in the external plumbing for 60 minutes. The step to the right is to mash out temperature.

Our main interest was in the wort from kettle to fermenter. We have had two problems - spoilage bacteria lurking in old lines and an inability to chill down to pitching temperatures.

The wort stability test has proven the first problem is solved - as long as we stay vigilant that is. After three days of excessive heat, it is not showing any signs of spoilage. The complete re-work of plumbing and clean processes are no doubt working.

The second one is not so straight-forward. We did a two-step chill of wort before it hit the fermenter. Both steps were done with the plate chiller, the first pass through via tap water for chilling, the second pass through via chilling water pumped from the ice bath.

It did not work as well as hoped. The flow rate from the ice bath was nowhere near enough to provide effective chilling. The wort could only be trickled at the slowest rate to attain our pitching temperature. As a result, only 8 litres of slowly collected fermentable was done this way for the sake of our starter step. The remainder was collected about 5 degrees C high and slowly chilled overnight in the cellar.

I've been thinking about possible solutions. The batch before this we added ice to the hot liquor tun and patched the heat exchange coil into the chilling water path to 'pre-cool' the tap water. This actually worked a whole lot better than the pump solution. I think we might need to re-plumb the system to make this step easy, as all this re-jigging of plumbing during a brew session is getting tiresome. The last session was 7.5 hours long for a standard batch and I was pretty tired by the end of it.

Anyway, the cellar is doing its magic and our blonde ale is promising the goods. We think Jess will be pleased.

I've now had a few weeks to assess the performance of the cellar and bar. The cellar is an insulated box (old freezer) with a PC radiator and fan used to blow cold air into the cavity. A temperature controller switches a pump and fan combination when the cellar warms above the setpoint. The ice water that is pumped through the radiator comes from the ice bank.

The ice bank builds up ice around the edges of its' water container as means of creating an ice bank that can be melted during periods of high demand. I accidentally created a high demand incident over the last few days because I plugged the radiator fan & pump into the wrong controller output. This meant that they ran continually, eventually melting the ice bank completely. I had wondered why the cellar temperature had dropped to 7-8 deg C. The ambient temperature was 25 degrees, so on a really hot day it might max out the ice bank if I'm trying to keep the cellar at a cool 11C.

The photo above shows the cellar is at 13C and the ambient temperature is around 18C (the two controllers at left).

At all other times the ice bank has not shown any signs of melting under load. The font can be flooded with cold water continuously and the cellar radiator can be working and we can pour beer and flash chill from cellar to serving temperature - all without putting too much strain on the system. I'm sure I can add a fermenter cooling coil to that without too many dramas.

There are some improvements to do yet. I need to install lighting inside the cellar so I can inspect kegs and check for condensation. I need to install collectors for condensation. At the moment I suspect there is condensation where the cold air blows into the cavity, and there is significant condensation on hoses to the flooded font connection.

I am pretty certain that this system could also be run with a standard chest freezer providing the cooling plant in place of the ice bank. I had a good freezer for a short time before the ice bank arrived. With it I was able to chill a 12 litre container of glycol to below zero from about 25C in just a couple of hours. The tricky issue would be how to prevent things outside the glycol from freezing as the glycol will most often be warmer than its surrounds. I went with the ice bank to eliminate that engineering challenge.

... and the really satisfying thing was that for both the New Year's Eve party and Leah's party a couple of days later, we had people hang about in the garage around the bar which has never happened before.

It has been quite a frustrating week, although I think my Zen meditation is really paying off, because I've literally been quite 'Zen' about it all.

First of all, our gas ducted heater failed and so the serviceman arrived on Monday to fix it. I'd been doing some coding on the Visual Basic part of HERMAN and was thankfully making frequent backups. At one point, the service guy tripped the house power, and my main PC crashed, never to boot up again.

I'm not sure what happened, as we have tripped the power out often with our various tests. I guess that XP must have been in the middle of some critical file write when it happened. Anyway, over $1000 to fix the heater (ouch) and about three days to rebuild the PC, and I've almost fully recovered.

I had a backup of my entire machine that was about 6 weeks old. Since then I had done a lot of tweaking using Ccleaner, I'd installed VB express 2008 and I'd generated a lot of new data. Lesson to self: Must back up more often!

The good thing is that the hard drive had not completely failed, in fact it is now fine again. It was simply that Windows would not boot. So I managed to salvage all my data, including all my outlook emails and contacts, stuff that I rely on way too much.

Anyway, the HERMAN project continues to develop. The VB application now has a functioning graphing module that can load saved session data, or show live data during a session. A picture does not really show all that much, but behind the screen shot lies a steep learning curve using zedgraph. Some things are well documented, and others I could only figure out through some arduous trial and error.

The shot above shows 25 seconds of data logging and the file load and last buttons are now working. The load button loads up a saved session file for reviewing after the brew day. The last button reverts back to live data. Having explained this, I think it would make more sense to replace 'last' with 'live'.

The new checkboxes on the right side of the graph enable instant viewing of the various temperatures and setpoints. This is very handy when analysing system performance.

One other thing we noticed when brewing with HERMAN is that the control panel adc values change with the number of outputs switched on. What this means is that different switches down the ladder need to be pressed to get the result expected. I had hoped to look into this in detail by now, but with the PC problems I've not had the chance. At the moment it is an interesting and quirky feature that is a challenge to workaround during brew day .

But for the moment I'm interested in getting code working between the PC and the picaxe so that the PC can do the same job as the control panel anyway.

It was fabulous to be brewing again last week, but I missed not having log data of the brew session. Now that the loop flow issue is resolved, the extra data helps to tune system performance.

Before brewing again (Monday just gone) I made sure the software was capable of storing a data log. Since Monday, I've been playing around with a way to show pretty graphs that are worth analysing.

With the old VB6 software, I coded all the graphing myself. It worked ok, but was not all that flexible or easy to use. After some net searching, I came across a nifty opensource control called zedgraph. While I've struggled a bit to find relevant bits of documentation on this control, I've persisted as it is very versatile and also free.

The graph above shows data that extracted from my csv log file of Monday's brewing session. The blue line is the mash setpoint, and the thicker red line shows actual temperatures.

Pre-heat rate

Between minutes 30 and 40, the mash liquor temperature (liquor only, no grains yet) rises from around 63.8 degrees C up to 68.0. This means that it takes about 2.5 minutes to raise the liquor temperature one degree. The graph does not show what the hot liquor tun temperature is at this point, but that will affect the operation of the heat exchange coil.

Dough-in

Under Promash I've got a thermal heat loss setting of 0 because the mash tun is pre-heated. The calculator there suggested that with liquor of 68C I would dough-in to 62C. The rapid drop in mash temperature between minutes 40 and 44 shows dough-in. The temperature was higher than calculated, resting at 62.8C. I suspect that the mash tun actually becomes a 'heat bank' because it is an Igloo insulated vessel (10 US gallons; 38 litres).

Temperature rest 1

The flat line between 44 and 60 minutes shows the insulated vessel holding temperature with no recirculating liquor. HERMAN is currently set to stop the pump operating if the target is high. Generally speaking, recirculating is more likely to add heat, depending on the hot liquor tun temperature.

The small drop just after 60 minutes is because the pump has been restarted and it is the effect of cooler liquor still in the system making its way past the mash thermometer. It suggests there is a two minute lag between cause and effect, something worth noting for a PID loop if I decide to go that way again.

Step to rest 2

The mash rises 6 degrees in only about 6 minutes. This is much quicker than during pre-heat because the mash tun has now absorbed a lot of heat. While the mash target was set to 68C, the mash overshoots this by one extra degree. Without the data to hand, I think the hot liquor tun was set quite high, possibly 80 degrees, which means it delivered too much heat. For the next brew I hope to be able to group HLT temperatures and manifold (mash liquor in) temperatures together on the same graph. This will help to improve process control even more.

Overall I am very happy with progress to date. Continuing to gather good information will help with the kind of consistency I'm after.

I ran some preliminary tests with the new coding tonight to get a feel for how HERMAN is functioning in this latest configuration. A thread on the Aussie homebrewers forum I read today got me thinking about how many different combinations of machine I've had over the last 7 years ... Talk about a 7 year itch!!! I think I have tried just about every configuration of HERMS and RIMS in that time.

The first iteration was a standard HERMS with a heat exchange coil in the hot liquor tun. The HLT was 25 litres and heater 2400W. This seemed too slow, so when the rig was upgraded to a 40 litre HLT, I converted to a separate heat exchanger with a volume of 15 litres and a 3600W element. But it seems I'm never satisfied ...

The next configuration was RIMS with a heat chamber fitted with a 3600W element that was almost impossible to control. The number of mishaps rose in proportion to the grunt available .

And so back, full circle. Now a 40 litre HLT with a 3600W element and some trickery to pre-heat prior to a step change in the mash.

I've tested tonight with just water. When grains are added to the mix they have a greater thermal lag and capacity - which means everything happens slower. It takes longer to heat a grain bed, and it takes longer to cool one. The time to heat is not so much my concern at this stage, rather the possibility of overshoot.

With the water run, I assumed a generous system heat loss of 5 degrees C. This means the machine should be able to reach the target mash temperature with comfort, rather than take forever inching its way to target, and never quite making it. I suspect this is a good way to run the machine, with a margin of error.

I stablised the rig with mash temperature at 62C. With a step to 69C in mind, I set the HLT at a generous target of 83C. I had figured this number out in my head, and it made sense at the time, but I can't work it out now . The HLT was allowed to heat to this temperature prior to changing the mash target to 69C.

It took 12 minutes for the machine to step up the 7 degrees in the mash. During a real mash, this will take longer due to the thermal mass of the grains. During this time, the HLT only dropped down to 81C, so the heating element is nearly capable of matching the heat required for the step.

My initial impression is that a varying HLT target might have some value - such as if the mash is 5 degrees lower than target, the HLT might be targeted at 10 degrees higher (taking into account system losses - ie. 10 + 5 degrees higher).

Before committing to this, I intend to run the following test:

• stablise mash at 62C
• preheat HLT to 69 + 2*7 + 5 = 88C
• set mash target to 69C
• set HLT target to 69C + 5 = 74C
• log the results with particular interest on final HLT temperature and time taken for mash step.
• work out what to do next.

The HERMAN project has been going on for a lot longer than the blog site here. This means that there is a lot of information missing from these pages. Garret Sever in a recent blog mentioned a power supply module that he bought for his picaxe based brewing sculpture. It reminded me that our own power supply has not yet found its way into a blog entry.

I can't claim credit for the circuit design - I think it came from a poster on the picaxe forum. We did design and build the circuit that is below and attached it onto a PC power supply. PC supplies are great because they are cheap and plentiful and can supply both 5V and 12V at many amps. If needed, there is also a -12V rail and 3.3V rail for added versatility.

With our supply we decided that the 12V rail would be used to supply anything that was potentially noisy or demanded a bit of current flow. This includes things like relays, solenoids and motors. If these components needed a different voltage, say 5V, we would still use the 12V line and use a regulator to drop it. This design philosophy means that the 5V line can be used solely for logic (picaxe and any other logic gates needed) and can be suitably filtered to provide a clean rail that the picaxe demands.

We decided that a PC supply on its own was not as clean as we wanted, so the circuit below was added.

Click on the circuit for a full-sized version. The original ExpressPCB schematic file is available under files/HERMAN6/Design.

The circuit board was made using ExpressPCB software, which was the best I had available to me at the time. I'm happy to have pensioned it off though. Below is the mechanical drawing, but if you want to make a board you can find the *.pcb alongside the schematic.

The completed PC supply with extra filtering is shown below. The black wire link at the top rear right connected to the screw terminal block is the control to switch on the supply. The link here ensures it is on as long as mains power is supplied, but we intend to extend this switch to our control panel.

The image below shows wiring of PC supply components. It is the green wire on pin 14 of the left-most connector that is used to power the supply on and off. You can click on the image to see it full size.

Overall, we think the PC supply makes an ideal power unit for a picaxe based brewing sculpture.