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