experiments in auto-power control for a Corretto

Ive been experimenting with automatic power control for a HG+BM
Corretto roaster. I wanted to be able to control the power from a
computer so I could produce a consistent roasting profile. I also
thought it would be fun to try and put it together :-)

The first thing I tried was using X10 control switches. I talked to
the people at smarthome.com.au, and they told me their switches could
handle 10A, that they were based on solid-state switches and that they
could be switched on and off quite quickly (several times per
second). I thought that I could control the power level by switching
on and off the HG via a X10 switch to give a percentage load. For
example, to get 80% power Id switch it on for 0.8s then off for 0.2s.

I bought some X10 gear, and tried it out. Unfortunately I found that
while the HA103 could indeed do 10A, it would only switch quite slowly
(best I could get was about one switch every 2s). The HA114 switches
faster (about 5 times per second) but only does 5A. The loud clacking
sound each time they switched also made it obvious that they used
relays, which would probably wear out quite quickly.

So I gave up on the X10 gear, and started looking for other ways to
control the power. I asked an electrical engineering friend of mine
(Paul Mackerras) and he thought Id need a custom circuit. He very
kindly designed a circuit for me, and built a power control device.

The device takes 240v in, and puts out a reduced amount of power
controlled by a serial port. To use it, you attach to the serial port
at 9600 baud and write the percentage power you want (so to get 80%
you write "80%/\/n"). I bought a cheap USB serial adapter from eBay
(just $3.87 including delivery!) and connected it to my laptop, giving
me USB control over the power level.

Pauls circuit works by using an opto-coupled triac with a PIC
micro-controller. The PIC looks for the zero crossing of the AC and
switches the power on based on a delay of a calculated number of
milliseconds after the crossing. This allows it to very accurately
deliver the amount of power requested (it has a little lookup table in
the PIC which maps the percentage power to the timing of the on-off
signals sent to the triac). Paul also set it up to monitor DTR, so it
only switches on when DTR is set. This provides some additional safety
that to ensure you dont switch on the power to the HG when you dont
want to.

Another friend (Hugh Blemings) has kindly drawn up the circuit
using gschem (after my attempts were getting nowhere!), which should
make it possible to produce a nice PCB layout for future versions. The
prototype Paul built uses veroboard. Hughs circuit if available as a
PDF and a raw gschem circuit here:

as you can see, it is heavily inspired by the CoffeeSnobs
RoastMonitor java app, with the addition of some code to do automatic
power control using a (slightly modified) PID control loop. It also
has a little simulator built in which has been tuned to roughly match
the roast profiles I get in my roaster. That makes it easier to play
with the PID control without wasting a lot of beans :-)

The code for the above is available at
http://samba.org/tridge/pyRoast/ if anyone wants to take a look. It
also contains a C prog (RawMeterReader.c) that can talk to the
CoffeeSnobs DMM to read the temperature. It only works on Linux for
now (Im running Ubuntu Karmic).

The resulting setup looks like this:

notice the little power control box in the foreground, and the pyRoast
application running in the background. The two USB cables are for the
power control and the link to the DMM.

One problem I had initially was I kept melting the temperature
probes. The solder in them melts at below 200 degrees, and the inside
of the bread machine gets hotter than that, so the solder soon comes
loose and you get very unreliable temperature readings. The problem
was caused by initially having the temperature probe inside the bread
machine, like this:

This not only caused the probe to melt, it also meant that it could
move around a fair bit while roasting. The solution was to put the
probe into the side of the bread machine

with it going through the wall of the machine as shown in the full
setup picture above. It doesnt melt any more, and it is held much
more firmly in place.

Im still playing with the ideal roasting profiles for this setup, but
the power control is working very well. It was also a lot of fun to
build, and the coffee tastes great!

Please note that you should only try to build the power control
circuit if you have the right qualifications and you understand the
circuit. Were thinking of submitting it to something like SiliconChip
magazine in the future, and maybe someone will even make a kit, but
meanwhile dont try it unless you really know what youre
doing. Building 240v circuits (even ones that are opto-isolated) is
not for beginners.

Id also like to say a big thank you to CoffeeSnobs for all the ideas that
went into the above. I wouldnt have tried to build this without seeing
all the great results everyone else got with a Corretto roaster,
and seeing the nice CS Java RoastMonitor app.

Re: experiments in auto-power control for a Corretto

author=646279747775100 link=1259627838/0#0 date=1259627838]Ive been experimenting with automatic power control for a HG+BM
Corretto roaster. I wanted to be able to control the power from a
computer so I could produce a consistent roasting profile. I also
thought it would be fun to try and put it together :-)

Id also like to say a big thank you to CoffeeSnobs for all the ideas that
went into the above. I wouldnt have tried to build this without seeing
all the great results everyone else got with a Corretto roaster,
and seeing the nice CS Java RoastMonitor app.

Bloody Ripper.. *I would suggest you follow up with SiliconChip as I would like to see you get some brownie points for the effort you and ya mates have put into it..

Will do some research as I can see that it could also assist in a mod to teh KKTO and add some level of technology to that system as well. Would be great to manage the heating... But the knockout would be to also be able to control the fan *;) ie. Dual output..*(Windows version is due when ? *;))

Re: experiments in auto-power control for a Corretto

Hi Andrew

Will you have nice roasted coffee from your Coretto in your room at the Linux Conf in Wellington? :-)

I had tried to use a triac based clipsal light dimmer for better manual temperature for my GeneCafe but it kept tripping the Gene fuse. There are quite a few Clipsal light dimmers and some are for inductive and some for capacitive loads and*think I used the wrong one so I gave up.

I started a few weeks ago to write a Python gui using Qt for my roaster as Im using the older serial DMM. It would have also forced me to learn learn Qt4 over Tkinker :-) I like your Python program.
(bugger though, Lenny only has python-kde3)

Re: experiments in auto-power control for a Corretto

Great stuff AT,

I confess, I cant read the code [NFI] but I understand the electronics and have thought alot about this kind of control solution myself.
Coupla questions:

How does the HG behave under reduced cycle [eg 80%]?
ie Do you notice a different sound, fan speed etc.
Im just wondering as JavaB tried PID control of the HG element [not fan] some time back, and wasnt happy with the results [IIRC cool air blew over the beans when PID output was low]
As your controller is not On/Off it should resolve that problem.

Regarding your "look up table":
1. Is the PIDs set point effectively "tracking" in accordance with the tabulated profile?
2. Do you increase the sampling/calculation resoultion in the time between FC & SC...It strikes me that this will be the most critical and hardest to control period [due to the exothermic reaction]?

How repeatable is a profile for a different bean mass or a different bean type [not that you would use the same profile for different beans]?
Can you post some actual roast profiles?

Temp control of an HG element will be pretty fast due to the low thermal mass, do you think your system will work with a higher thermal mass such as a Turbo Oven element?
If it will work, using this controller in a "closed" system ala SCTO/KKTO would be about the perfect roasting solution.

Re: experiments in auto-power control for a Corretto

Originally Posted by 6077677061667760120 link=1259627839/7#7 date=1259715994

Great stuff AT,

I confess, I cant read the code [NFI] but I understand the electronics and have thought alot about this kind of control solution myself.
Coupla questions:

How does the HG behave under reduced cycle [eg 80%]?
ie Do you notice a different sound, fan speed etc.
Im just wondering as JavaB tried PID control of the HG element [not fan] some time back, and wasnt happy with the results [IIRC cool air blew over the beans when PID output was low]
As your *controller is not On/Off it should *resolve that problem.

Regarding your "look up table":
1. Is the PIDs set point effectively "tracking" *in accordance with the tabulated profile?
2. Do you increase the sampling/calculation resoultion in the time between FC & SC...It strikes me that this will be the most critical and hardest to control period [due to the exothermic reaction]?

How repeatable is a profile for a different bean mass or a different bean type [not that you would use the same profile for different beans]?
Can you post some actual roast profiles?

Temp control of an HG element will be pretty fast due to the low thermal mass, do you think your system will work with a higher thermal mass such as a Turbo Oven element?
If it will work, using this controller in a "closed" system ala SCTO/KKTO would be about the perfect roasting solution.

Cheers Reuben

I have put a PID on my Coretto. But unlike Andrews contraption the PID controls a SSR. The SSR then switches the HG and the BM element.

The lag time on the element is about 30-60 seconds before I see a change in temperature gradient.

After a lot of roasts I find that I use the PID in a different way to I intended. I control the ramp to first crack manually, with the ability to switch the BM element off/on and the HG off/low/high.

The most common way I roast is to leave the element on and the HG low all the way to FC. If the roast is running slow I put the HG high for a few moments every 30 secs. Running too fast I use the PID to then slow the roast down.
The PID is then used to control between FC and SC. This where it is really, really useful. I can sit almost anywhere between FC and SC for however long I like.
The PID can also be used for "experimenting". I can run the roast quickly to a high temp before FC and use the PID to hold the temp so it doesnt run into FC too early. It aint perfect. It does over run but you learn how much it over runs, where and when to set it.

So I basically use it more like a brake. It allows me to control the roast more easily. It also picks up temperature changes before I can, more importantly the rate of temp change, very usefully to stop runaways.

Re: experiments in auto-power control for a Corretto

Hi Mike,

Originally Posted by 3B382D242D272521232D480 link=1259627839/5#5 date=1259668563

I had tried to use a triac based clipsal light dimmer for better manual temperature for my GeneCafe but it kept tripping the Gene fuse. There are quite a few Clipsal light dimmers and some are for inductive and some for capacitive loads and*think I used the wrong one so I gave up. *

I looked a bit at light dimmers, but I couldnt find one that could
be computer controlled and would take 10 amps. Did you find a 10A
one? I think youd want one for a resistive load (as a heat gun is
really just a big resistor).

Re: experiments in auto-power control for a Corretto

Originally Posted by 4D57535150535B525C3E0 link=1259627839/6#6 date=1259714112

I have a good mate whos an electronics engineer and could help me build one.

What is the approx cost of the parts ? *(excluding the DMM of course which I have)

Paul bought the parts, and I think it cost him a total of $86
(including the case and all the connectors), but he didnt really
attempt to find the cheapest suppliers. When he later looked up some
cheaper suppliers he thought it would probably be possible to do it
for around $60 or $70.

If you do build one, you will need the PIC program code to load
into the PIC (Ill put that one the website soon).

You also may want to hold off till next week, as we attached
the power controller to a CRO today, and noticed some strangeness
in the waveform when it was doing above about 90% of power. Paul
is going to look into it, and may change some of the component values
to ensure the triac stays happy over the full power range.

Re: experiments in auto-power control for a Corretto

Hi Reuben.

It is fine at power levels of 80% or so. The place where it gets into
trouble is at much lower levels, say 20% or so. It seems to depend
on the heatgun. While roasting yesterday my Ryobi HG stopped
working completely when the power control was below 20%, and
I thought Id burned it out. It turned out that Id just tripped the
over-temperature sensor in it, and it came good again a bit
later. Paul and I suspect that what happens is that the fan cuts out
before the heating elements does, so the element gets too hot
if running at really low powers. Im thinking of adding a lower limit
to the power I put out in the python code to avoid this (ie. if
the control code decides to put out a power level below 25% then
just do 0%).

My Ozito HG seems less a bit less sensitive to this, so it seems to
depend on the model of HG.

Regarding the PID control, Im currently experimenting with
different PID values and methods of control. The key problem
is that PID control doesnt really take good account of a long
lag between applied heat and temperature change. Ive noticed
that the lag is of the order of 15s or so between when you raise
the power the and temperature starts its full ramp up. This means
that with normal PID control you get oscillation.

The python code has a built in simulator to make it easier to
try to tune the PID control, and it can also run with an speedup
multiplier, so you can watch a simulated roast at (for example)
50x speed, allowing you to see the effect of varying the PID
parameters.

To illustrate, here is a screenshot with a loaded profile from a real
roast (in blue) and a simulated run (in red).

This example shows quite a few interesting features. First off, the
little steps in the real profile every 2 minutes are because the BM
program reverses direction every 2 minutes, which sweeps some
"cold" beans over the thermocouple. I havent built that effect
into the simulator yet (alternatively I could hack the BM to not
do this!).

You can also see large oscillations in the real profile of about 5 degrees
once it gets close to its target temperature (in the above the target
profile for both the real and simulated roasts was set to a simple
flat 210 degrees). Both the simulated and real roasts used the same
PID control code (well, not strictly "PID", but a variant on the theme).
The good news is that the simulator is tracking the real roast fairly
well, which means the simulator is producing a somewhat reasonable
emulation of the behavior of the roaster. The bad news is that the
control code itself is doing a lousy job of converging on the target
temperature.

Ill play with the control code a bit more soon, and hopefully
will get something that produces a much smoother match
to the target with the simulator. Then Ill try it again with a
real roast and see if it matches what the simulator produces.

At the moment my simulator is based on a simple
"bucket brigade" system that slowly propagates heat
along a series of buckets, with the HG power applied
at one end of the series and the thermocouple readout
coming from the other end. That is basically a very crude
one-dimensional model of a roaster. If you are interested
in how it would react with different thermal masses
and other roasters then I suggest you play with the simulator
to try to match the characteristics of your roaster.

There is also lots of scope for making the simulator much
more accurate, as we have plenty of CPU power to play
with (one advantage of doing this on a laptop, rather than
on a system like an arduino). It appeals to the CS/physics
geek in me that I get to play with thermal simulations while
building a coffee roaster :-)

If you want to play with it, you dont need to build any of the
hardware to run pyRoast as a simulator. Just install the right
pyQt packages, and run it like this:

*./pyRoast.py --simulate --target=210 --speedup=50

Currently Linux only, though it should be possible to port to
windows if I replace the current KDE plot widget with something
based on PyQwt *(which works on windows).

Cheers, Tridge

Originally Posted by 1106160110170611630 link=1259627839/7#7 date=1259715994

How does the HG behave under reduced cycle [eg 80%]?
ie Do you notice a different sound, fan speed etc.
Im just wondering as JavaB tried PID control of the HG element [not fan] some time back, and wasnt happy with the results [IIRC cool air blew over the beans when PID output was low]
As your *controller is not On/Off it should *resolve that problem.

Regarding your "look up table":
1. Is the PIDs set point effectively "tracking" *in accordance with the tabulated profile?
2. Do you increase the sampling/calculation resoultion in the time between first crack & SC...It strikes me that this will be the most critical and hardest to control period [due to the exothermic reaction]?

How repeatable is a profile for a different bean mass or a different bean type [not that you would use the same profile for different beans]?
Can you post some actual roast profiles?

Temp control of an HG element will be pretty fast due to the low thermal mass, do you think your system will work with a higher thermal mass such as a Turbo Oven element?
If it will work, using this controller in a "closed" system ala SCTO/KKTO would be about the perfect roasting solution.

Re: experiments in auto-power control for a Corretto

Originally Posted by 3720302736312037450 link=1259627839/7#7 date=1259715994

Do you notice a different sound, fan speed etc.

yes, the sound of the HG varies noticeably as the power level
changes, changing in both pitch and volume. I think this
is just the fan changing speed.

1. Is the PIDs set point effectively "tracking" *in accordance with the tabulated profile?

yes, you can either load a full profile (with the --profile command
line option), in which case the power control code uses that profile
as the target, or you can use --target=NNN which is just shorthand
for a flat profile at a fixed temperature.

The control code Im playing with at the moment uses the slope
of the temperature curve (with some smoothing) to predict
the temperature at a point in the future (Ive been experimenting with
how far in the future, but 20s seems OK). It then uses the difference
between that predicted future temperature and the loaded profile (or
target) as the input to the control code.

2. Do you increase the sampling/calculation resoultion in the time between first crack & SC...It strikes me that this will be the most critical and hardest to control period [due to the exothermic reaction]?

no, the DMM gives temperature samples every 0.5s, and I just
do the control calculations at the same frequency, but using a
smoothed version of the DMM temperature output.

How repeatable is a profile for a different bean mass or a different bean type [not that you would use the same profile for different beans]?
Can you post some actual roast profiles?

Ive only done a few real roasts with this setup so far, and Im really
just aiming to get the simulator right so I can then develop the control
code more using the simulator. That wastes a lot less beans, and
there is only so much coffee I can drink :-)

The few roasts I have done seem fairly repeatable, though of course
I keep playing with the control code, so most times I have different
control code than the last roast, and that can have a big impact
on the resulting temperature profile.

If it will work, using this controller in a "closed" system ala SCTO/KKTO would be about the perfect roasting solution.

I dont see why it wouldnt work, as long as you adjust the control
parameters to match the roaster.

updated circuit

As I mentioned above, Paul and I found that the circuit gave a lousy
waveform at higher power levels when we looked at it with a CRO.

Paul has found the problem, and has modified the circuit to fix the
problem. The problem turned out to be in the zero-crossing
circuitry. If the PIC turns the power on soon after zero is crossed,
then then the triac would get too small an input, and strangely enough
would actually turn on later (and at a randomly varying time) than if
you wait to turn it on when there is enough power.

The fix for the circuit is here:

*http://samba.org/tridge/pyRoast/fix-zc.png

Hugh is going to redo the circuit diagram to incorporate this change (I
dont know enough about circuit design to even work out where
the above change fits!). Hugh is also working on producing a PCB
layout for the circuit.

With the above change the CRO shows a really nice waveform at
all power levels, and Im getting more stable roast profiles.

Ive also made some improvements to the pyRoast.py code, although
the power control code still needs more work.

Re: experiments in auto-power control for a Corretto

Thanks for keeping us posted on your experiments Tridge.
It looks to be a great system and I am looking forward to the next update.

Perhaps you know already but it is really easy to add multiple thermocouple channels directly to a PIC using the Max6675 chips.
Perhaps a monitor of the heater output temperature or ambient might be useful ? Always fun to have more numbers to play with.

Re: experiments in auto-power control for a Corretto

Hi Tridge -

Have you considered cracking open the HG and hacking it to control the fan and heating element separately?

This could help with the overheating issue you described - keep the fan at a relatively high speed, while lowering the temperature of the heating element. Although maybe this would put too much cool air over the beans?

Re: experiments in auto-power control for a Corretto

Hi all

Just a heads up for those interested in the nexus of coffee and Linux. Andrew Tridgell will be speaking as usual at the Linux Conference this week but this time it will be about using "Penguin powered coffee!"
https://conf.linux.org.au/programme/schedule/view_talk/95?day=friday

Shame my wife and I are missing the Linux Conf this year. Its in Brisbane and hopefully all will go very well for the organisers and the attendees.

I have used a modified (hacked!) version to control a 'KKTO-like' roaster. I used a USB thermocouple and a USB relay (which operates a second 240V relay) to control the heat. It's only on-off... or 0 / 100% power. But it works.

This afternoon it succesfully followed a roast profile (that I had to make up based on a previous roast). Next step is to have it roast without a profile but with an estimated first crack temp (eg full heat till say 30 degrees below estimated first crack temp, then slow the temperature change... till say 2 degrees below estimated first crack temp then slow the temp change more till say 10 degrees above estimated first crack.... then maybe sound an alarm to say it's time to turn it off?

I took a screen shot (which will show that I still have some 'tweaking' to do) but I don't know how to load the photo to this post without using a URL?