I bit the bullet this morning and went through the tutorial I mentioned last entry as an attempt at understanding how VB and .NET handle multi-threading. I must admit there are some grey edges to what seemed to work, but after about 6 hours of both learning and coding, I now have HERMAN running serial receives asynchronously. It is very pleasing to see rock-solid performance, with no trouble to synchronise comms and stay synchronised with the picaxe.

There is downloadable code available here which formed the basis of the new HERMAN code. I don't think it is worth posting the current HERMAN code, but if anyone specifically wants a look just let me know. It is still a bare bones product, although looking nicer and functioning better by the day.

Coding is not really that exciting for bystanders watching, or those reading on blog sites, so I will spare the details.

The next step for HERMAN hardware will likely be sorting out the LCD. I had the 40x2 display working on the test bench but for some reason it has not worked yet on HERMAN. It is not as simple as I'd anticipated because it requires a negative voltage on the contrast line. To supply this I'd wired in the -12V line from the PC power supply and with a couple of resistors thought all would be fine. I'm not sure at this point what the problem is, but I was not all that happy with the solution - it is far from elegant.

I found some circuitry on the web the other day that looks like it will be the solution I was seeking.

This circuit snippet is from a driver board for a graphical LCD that Microzed supply for the picaxe. The 7660S IC is available from Farnell Australia for $1.45 per unit, so it looks like an easy way forward.

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.

We brewed an IPA today and all went well, including hitting an efficiency of 79%, by far our best for a long time. The recirculating loop is doing its job well now.

While brewing though, the quaint idiosyncrasies of the control panel no longer seemed quaint, as several times we needed to power down HERMAN just to regain control. I realised that I'd been too focused on VB coding and not focused enough on fixing simpler things.

Anyway, with the machine cleaned up from the brew, I was determined to figure out what was going wrong.

The control panel itself was not at fault. As outputs were turned on, the supply rail varied by small amounts down, just enough to upset the analog to digital readings from the control panel. A double check with a battery pack produced the same effect as the PC power supply.

Unplugging the solid state relay interface cleared the fault, so I was getting closer. The interface box was actually the first part of the HERMAN 6 rebuild and was built over a year ago. I vaguely remembered having problems with it back then, and uncovered a circuit that was not quite right.

The original problem was subtle. The solid state relays have a drive voltage of 4-7 volts DC. The idea above is that a picaxe output directly drives the SSR to switch the AC load. The problem is that the LED (D1) needs a limiting resistor in place. I pulled off the cover of the interface and found resistors soldered onto the legs of the various LEDs.

Considering that the SSRs were ok to run from 4 volts, I decided to try some 150 ohm resistors on the drive line. I only had 180 ohms on hand, so they were plugged into the breadboard.

And presto, problem solved!

The supply voltage is now rock solid. The control panel now works no matter how many outputs are on. And I have lots of ideas about tweaks on the machine before we brew next ...

Some things to do:

• Add some hysteresis to the pump control while recirculating.
• Improve the receive communications on the VB program. At the moment it is missing every second send, and often getting out of sync.
• Improve the live graphing. Currently the brew is providing too much information and it is slowing down my tired old laptop too much.

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.