I've been inspired to get my teeth into picaxe coding again and so it was time to further develop the HERMAN code. One thing that I wanted to clean up was the duty cycle timing for the kettle power - the cycle time was way too long. I had the interrupt timer operating at 1 second for clock purposes, so to speed up the kettle duty cycle the interrupt now happens more frequently to update kettle duty each minor tick. A major tick still occurs every second, triggering all other timed functions, including one-wire timing.

Once that was sorted, it was time to tackle PC to picaxe communications via the serial port. I've had picaxe to PC working for ages, but when I first tested the other direction I was perplexed at the lack of response from the picaxe. While working on the duty cycle function, I found a logic error that prevented the receive code from ever working. 

OK, so now the motivation to step forwards again. Things were not straight-forward, however. The first symptom was that data was received but the picaxe never recognised the header, so always timed out. It turned out that incoming data was mostly corrupted, through timing problems. This was eventually sorted using the calibfreq command. The manual says this command should be used with caution. Of course I forgot to read that bit ... and ended up with a picaxe I could not program for quite a while. A hard reset on the power side eventually fixed it!

In hindsight it seems blindingly obvious that I could have implemented the calibfreq for the received comms code only. I now have this working reliably.

With a header now recognised and information getting through, I ran into more problems. Most of the information sent came through ok, but it always seemed the last byte was corrupt. I still have no idea why, but I ended up shortening the data packet and sending a dummy end and now it all works.

There is more work to do to make things more robust. I intend to implement both send and receive checksums, but for now I'm happy to finally have remote control capacity for the machine.

Until a few days ago the display part of my picaxe code on the brewing machine was a mess. It had been ages since I'd coded any revisions and the display only had rudimentary information on screen. For the last three months I'd needed to plug in the laptop just to see something intelligible from the 28X1 chip.

Recently I bought an Arduino and I've been catching a few minutes here and there to learn about its capabilities. There is a lot more power in this new (to me) micro. Because of this I'd neglected further picaxe development.

A couple of things changed that. A significant revision to the Picaxe Programming Editor has meant that complex code is much easier to navigate around, and that variables are much easier to keep track of - an important thing when they are in limited supply.

So while I was looking at the new Editor, I discovered that I'd done some significant recoding for the picaxe in early November that I'd forgotten about. It never got uploaded and tested ...

So all of a sudden there were display improvements and an easier way to keep track of updates ... and I'm inspired again by the micro I know.

I've posted the current HERMAN code here. There are improvements to make, but generally I'm happy with progress. I intend to add in features like:

• start delay - allows things to be set to turn on in the early hours of the morning for a pre-heat.
• screens to allow easy entry of mash targets and times
• boil timer and hop addition settings
• better implementation of variable power on the kettle - ie. shorten the duty cycle and put it in the main program loop.

On the hardware side I've been impressed with the 'shield' idea on the Arduino. Essentially a shield is a board that can piggyback onto the base Arduino board. The connectors extend all pins, power, reset and the like. Shields can be stacked on top of each other to further extend functions. As an example, I have an internet board for my Arduino (not that I've done any experiments with it yet).

I'm not sure I will implement 'shields' in the HERMAN project although the idea of beginning small and building up is appealing. Some possible 'shields' for the HERMAN project:

• a base board with picaxe 28x1, serial programming connector, external power connector, crystal socket, reset button, power, reset and pins available on connectors.
• an input board with facilities for DS18B20 sensors and analog inputs (ie. level sensors).
• an ssr output driver board

I've reached a critical coding point using a picaxe 28x1 - I've run out of variables.

Doing small programs on a picaxe is easy, thanks to a simple but powerful basic interpreter. Because of its structure, it has a limited number of byte and word variables available. Once these have all been used, coding gets increasingly difficult. I find that good coding strategies are needed to stop me going crazy.

Once you run out of variables, you need to find a way to re-use them without corrupting data from one routine to another. Data can be stored in random access memory (RAM) addresses or EEPROM addresses to free up variable for re-use. The problem comes in the detail, and carefully working out which variables are needed where in a program, and then making sure values are stored elsewhere before moving on.

I'm taking a break from coding to do this blog to prevent myself from going crazy at this point. I've realised that adopting some of the strategies outlined below might help me sleep tonight ;-)

Rule 1:

If a piece of code is repeated, always write a subroutine to do it.

Rule 2:

Try to minimise the depth of subroutine calls. It can be hard to keep track of which routine calls another, which makes it difficult to keep variables isolated.

One strategy is to set 'flags' to indicate a subroutine call if there needs to be a shift in call order.

Rule 3:

Make each procedure or subroutine a sealed unit - that is peek (get from RAM) all variable values at the start of the routine, and poke (store in RAM) them all at the end, freeing all variables up for other routines. If there needs to be any global variables, make sure there are good reasons for them.

Rule 4:

Start afresh with a clean slate and slowly re-build the complexity, rather than try to re-build an already complex piece of work.

The result:

After a couple of solid days of re-coding, I am still at a lesser-functioning piece of code. What I do have, though, is a much cleaner, and easily expandable piece of work. It is painful to go through the process, but if done properly will be worth it because the code will be much easier to maintain.

I went back through the PID coding on the picaxe tonight to try and replicate the bug that caused the heat chamber to apply 100% power when it was already too hot!

Total = P - I MIN 0

 

where P=0

and I=5 (ie. -5)

• Each module does all that is necessary for a localised task.
  • Tasks are separated into these discrete blocks of responsibility: Tun controllers (Mash, Hot Liquor, Heat Chamber, Kettle); Valve controllers (for each controllable ball, gate or solenoid liquor valve); Display controller; miscellaneous controllers as needed (such as hop dropper).
  • This means that a tun control module (for example hot liquor) needs to read liquor temperatures, level of liquor, and be able to control the heating element as a stand alone system.
• Each module is biased to be verbose in its network reporting.
  • When a module records a change in a sensor, that information is reported on the network bus
  • Module handshaking is done via a clear to send line - a module will send information at the earliest clear opportunity
  • Modules take the initiative in sending information.
• A PC connected to the network may operate as a network controller.
  • While each module operates as a stand alone unit, the PC is capable of coordinating tasks. A complex task might be controlling valves to fill the hot liquor tun, and sensing when that tun is full, and then stopping the fill.
• A PC on the network only sends information on the network occasionally
  • Minimising traffic to the modules will minimise "interuptions" to normal module processing.
  • The task of coordination is not complex in terms of information flow, so communication only needs to be occasional.
• A dedicated Picaxe module may be employed in place of the PC as a network controller
  • This unit would monitor network traffic to provide information display
  • This unit would coordinate tasks across modules as per the PC
  • Ideally the PC and this module would be able to work together

To achieve these aims, processes that 'distract' a module from performing its normal work is minimised. There are a number of picaxe related issues that need to be resolved:

• potential 'lock-up' of serial in communications
• time delays during serial-in communications if this is frequent
• 750mS time delays in reading DS18B20 temperature probes

Minimising the serial in communications has already been mentioned. Given the recent announcement of the X1 range of picaxe chips, it would appear that a 28X1 is an ideal candidate for a picaxe network controller. The scratch pad and background serial communications features mean it is likely an ideal buffer for PC communications, should a PC be optionally attached as a network controller. The added timer functions suggest it may be possible to ultimately code an X1 as a fully automated controller.

Synchronisation issues regarding serial in on the remaining modules would be minimised with a serial break sent by the PC/picaxe controller that triggers interrupts on these modules.

It has taken some time to work through temperature sensing issues. I have long liked the simple accuracy of the DS18B20s but have not been happy with the reading delay time that has caused picaxe chips to wait for 750mS until a response is received. Analog probes are quick to read, but generally need to be amplified to get the accuracy I've desired. Jurgen Kranenborg has provided the inspiration needed in his article on 2-wire networking (see previous blog).

Where I had originally been planning discrete connections from the tun module picaxes to temperature and level sensors, this can now be simplified in architecture by connecting these to a sub-network. This architecture also solves the 750mS processing delay problem by using additional 08M picaxe chips as sensor buffers. The tun (or other) module can address a particular sensor and request information, and after an appropriate time delay can then read that information. Using a sub-network adds versatility. This could mean that temperature analysis could be simple or complex using the same physical architecture. As mentioned in the 'Further musing on temperature sensing' blog, the heat chamber might benefit from complex temperature analysis, while the hot liquor tun may only require simple temperature measurements.

This sub-network idea could also prove useful for level measurement. It may turn out that the accuracy of a capacitive sensor would be enhanced with a long 'count' time compared to a short one. A process of requesting, continuing processing, and reading the result may be advantageous.

A sub-network may also be useful for adding extra display information. Each tun module could benefit from having a 3 digit LED display that shows either temperature or power levels. While this information may be available on the picaxe controller LCD, a local display may prove more practical.