I've 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 I'd 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 I'd 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 don't switch on the power to the HG when you don't
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:

http://samba.org/tridge/pyRoast/ppppd.pdf
http://samba.org/tridge/pyRoast/ppppd.sch

I wrote a little python app to control the whole thing.



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 (I'm 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 doesn't melt any more, and it is held much
more firmly in place.

I'm 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. We're thinking of submitting it to something like SiliconChip
magazine in the future, and maybe someone will even make a kit, but
meanwhile don't try it unless you really know what you're
doing. Building 240v circuits (even ones that are opto-isolated) is
not for beginners.

I'd also like to say a big thank you to CoffeeSnobs for all the ideas that
went into the above. I wouldn't 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.

Wow, that is awesome, thats quite a talent you have there!, could you show us a roast profile of an actual roast? this could change everything..................again

Well DONE X 2

warren

he does have something in the pipline, he illuded to it in another thread, but this one is the OP's mod of the CS Java software, cool hey!

Hi Andrew

Looks great!!

I have a good mate who's 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)

Im deciding whether to go your route or the Aurduino route - your's looks quite and elegant solution.
Cheers
Mokka

reubster wrote on Dec 2^nd, 2009, 12:06pm:


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 first crack. 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 first crack and second crack. This where it is really, really useful. I can sit almost anywhere between first crack and second crack for however long I like.
The PID can also be used for "experimenting". I can run the roast quickly to a high temp before first crack and use the PID to hold the temp so it doesn't run into first crack too early. It ain't 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.

Hi Mike,

speleomike wrote on Dec 1^st, 2009, 10:56pm:


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

Cheers, Tridge

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 I'd burned it out. It turned out that I'd 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. I'm 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, I'm currently experimenting with
different PID values and methods of control. The key problem
is that PID control doesn't really take good account of a long
lag between applied heat and temperature change. I've 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 haven't 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.

I'll 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 I'll 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 don't 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

reubster wrote on Dec 2^nd, 2009, 12:06pm:

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
don't 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 I'm getting more stable roast profiles.

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

Cheers, Tridge

For those of you mad enough to try and build one of these, here is
the PIC code in source and hex formats:

http://samba.org/tridge/pyRoast/pic-source.asm
http://samba.org/tridge/pyRoast/pic-code.hex

As I mentioned previously, only attempt this if you have appropriate
qualifications and experience for working with 240v circuits! This
is not a circuit for amateurs.

Cheers, Tridge

I've now adapted the power control box and pyRoast for making
chocolate truffles. My wife is delighted

See http://coffeesnobs.com.au/YaBB.pl?num=1263085051 for the details.

Cheers, Tridge

Now ya have to move on the the Turbo oven!