HERMAN

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.

Even though it has been ages since my last blog entry I've been busy building and inventing. One of the things that has taken my attention is putting together a BrewTroller control panel.

There is more information at the BT forum here.

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

When the current HERMAN machine was being built, I was confident enough with my plumbing layout to create a final system, hard plumbed in copper. It took a lot of time and effort to create the beautiful sculpture.

But things change. Although 200+ all grain brews count for a lot, sometimes changed circumstances can radically alter the preferred layout. A couple in particular come to mind. While this machine was originally designed to automate the process of filling hot liquor tun and mash tuns with water, for various reasons that will have to wait for the next generation machine. Another change has come about through changed cleaning and sanitation practices.

For a long time I've been resisting the idea that Jamil Zainichef espouses about recirculating kettle wort to both chill quickly and whirlpool the kettle. He uses an immersion chiller, but the principle still applies to our plate chiller. A continuous flow loop is via the kettle outlet, to a pump and then back into the kettle. Our loop just adds an external chiller.

I've not been keen on this idea because years ago this method gave rise to off batches. I hadn't realised that grain was caught in the pump impeller, and that grain went off. Anything post boil needs to be biologically clean and sanitised.

Recently PBW and star-san have become available in Australia. I have been really impressed with both products, and particularly PBW. My stained kettle is now sparkling through using it. I am confident enough to try a loop through the pump, although I will take the head apart first, just to make sure.

Anyway, the layout below is the third version of the current machine. As time goes by it is getting simplified. There is now no direct connection between water in and the rest of the plumbing, although it can be patched in if needed. The 'cold liquor out' line is a flexible hose that can be used anywhere in the system, even to spray down if needed.

I've also had a three way valve for ages, and it was crying to be used at the top of the tree as shown on the diagram. Liquor is only ever directed either into the mash tun or the kettle, never both at once.

We are brewing tomorrow, so I must go and check that pump head.