xGoat
More tea please.

Temperature-Controlled Wedding Cake Baking

My friend Elisabeth was recently responsible for baking a layer of a wedding cake. Wedding cakes are not like normal cakes. They tend to be quite large and regarded as quite important. So Elisabeth did a couple of practice runs of baking this cake, which was good for the occupants of this house as there was much yummy cake to go round. During these practice sessions it became apparent that the temperature control of our kitchen’s cheap gas oven was not suited to mission-critical situations. Using hot water causes our on-demand boiler to come on, which lowers the gas pressure reaching the oven, resulting in it cooling down. I had a shower during the second attempt, which resulted in the pressure going so low that the oven turned itself completely off. It turns out that, like electronic components, cakes also have temperature profiles that should be stuck to when processing them!

Ideally the oven would control the amount of gas being burnt based on the difference between the temperature within the oven and the desired temperature. However, cheap ovens are cheap. They work on the assumption that the gas supply has a constant pressure, and the room temperature is constant over all time. Furthermore, again because they’re cheap, these ovens do nothing in response to differing thermal masses. It seems that our cheap oven’s “temperature” knob just adjusts the target pressure of a gas pressure regulator. The relationship between the position of the temperature knob and the gas pressure is extremely non-linear, and bears much resemblance to its close relative, the all-too-familiar and highly-sensitive shower temperature control.

I decided that was was needed was a better temperature controller for the oven. This was quite clearly a situation demanding the fusion of some amusing mechanical hacking and electronics. Pulling the knob off the oven revealed a brass rod with two flats on its sides. I decided that the easiest way for me to motorise this was to mount a pulley on it. With Jeff having recently moved to London, I’d been left particularly latheless and so scoured the internets for suitable pulleys. The online shopping experience for mechanical parts isn’t anything like the world of online shopping for electronic parts. It is a world pretty much completely devoid of parametric search, and is full of websites that feel like they’re still being served from the same BBC Micro they were designed on… (That’s not to say that online electronic component shopping is a gold standard however — it’s got an awful long way to go, and unfortunately competition is not fierce within it.) Also, one gets the disconcerting sense that there are still a lot of fax machines involved in the mechanical parts world. After pushing myself through the HPC Gears website, which is still very much adheres to ye olde “the paper catalogue is the one true way” line of thinking (sigh), I found the pulley I was looking for. I was pleasantly surprised to find that I could order a single pulley, rather than 9000.

So, it was Sunday evening. The cake needed to be baked on Wednesday. Everything I ordered at this point would arrive on Tuesday (because ubiquitous 24/7 UAV-based shipping networks still belong to the future…). So I spent a couple of hours making sure I’d either got or ordered all the bits I needed. This is the final list of things that I ended up using:

Luckily, the postal service functioned well, and everything did indeed arrive by Tuesday. So on Tuesday evening, Johannes and I hacked the mechanical situation together:

Next came the electronic and software side of things. This was reasonably straightforward. The MAX6675 has a simple SPI interface, which we talked to using the FTDI adapter. Hacking this together at high-speed, I decided to just use the bit-bang mode of the adapter. This is the most conceptually simple mode, as one just sets, clears, and reads pins on the adapter. I could have got the FTDI module to perform all the clocking of the MAX6675 itself, but this additional complexity really wasn’t worth it for an unneeded efficiency/speed improvement.

Interfacing with the motor controller didn’t take too long. The documentation about the Pololu motor controller seems unnecessarily convoluted to me. All I wanted was a table of the different commands that I could send to it over its USB connection. Pololu give a long manual for the board, in which the different commands are spread out, and interlaced with screenshots of various graphical programs that I had no interest in using.

Initially, I had plans to add a AS5030 magnetic rotary to provide feedback on the position of the temperature knob. It turned out the end-stops of the oven’s knob were sufficient for us to drive into them a bit. So we could easily get to “min” and “max” without feedback. It was about three in the morning by the time we’d got the mechanical, motor control, and thermocouple situation configured. Pressure to ship combined with sleepy haze lead to us abandoning the AS5030 plan, which was OK because we could just oscillate between min and max to control the temperature. This is known as bang-bang control. Our testing convinced us that we could get the oven to stay within something like ±5°C, which was definitely accurate enough for what we wanted.

Whilst Elisabeth was busy mixing the cake, the control loop was set to heat the oven to 160°C and keep it there. The mixture was put in the oven, and the system was left to run for two and half hours. By “left” I mean that Johannes had a constant eye on it throughout the baking procedure — this was an important cake! All was well, and the cake baked successfully:

Bring On The Graphs!

Of course, whilst the cake was baking, we logged all the available data to disk (you can download it too… for some reason… find it at the bottom of this post). Below is a plot of the temperature of the oven read through the thermocouple throughout the whole process. The black line is the temperature, and the red shaded areas show where the knob was set to “max”. The knob was set to “min” in the white areas.

So you should be able to see from the above graph that the cake stayed around the temperature it should have throughout the whole process. There are a couple of more interesting events in there. If we zoom into the left-hand end of that graph (at the beginning of the baking experience), we can see what happened when the oven door was opened to put the cake in. Here you can see how quickly an oven will cool down when it is opened.

The other interesting bit is when the cake was removed from the oven. The control and logging stuff was turned off for a short period after the removal, so there’s a bit of a gap in the data as well:

So, now for some analysis of the above data. Here’s a histogram of the temperatures sampled during the periods of time when the oven door wasn’t open and the cake was installed:

Some stats from that:

So, a range of 11.5°C. Not bad for a night’s hacking. Elisabeth decorated the layer of cake, and transported it to the wedding, where it was combined with two other layers of cake baked by different people. News on the grapevine is that Elisabeth will be posting some photos on her blog any day now ;-)

There are two repositories of source related to this project:

And the data is available in this CSV file. The columns are as follows: time (seconds), temperature (°C), and whether the knob was on max or not. Enjoy.

Posted at 10:29 pm on Wednesday 28th December 2011
3 Comments

Site by Rob Gilton. © 2008 - 2019