Not a member yet?
Click here to register.

Forgotten your password?
Request a new one here.
You must login to post a message.

02/04/2023 1:40 PM
Welcome, ediblemanager

02/02/2023 4:22 PM
bcoffeedrinker Welcome

01/31/2023 1:17 AM

01/29/2023 4:55 AM
Welcome, drygrounds and CarlHaberfeld,

01/28/2023 5:42 AM
ramsamorrow, VirTERM and Columbia, coffee drink

In Memory Of Ginny

Latest Donations
dmccallum - 10.00
JackH - 25.00
snwcmpr - 10.00
Anonymous - 2.00
Anonymous - 5.00
Users Online
Guests Online: 18

Members Online: 0

Total Members: 7,788
Newest Member: ediblemanager

View Thread

Who is here? 1 guest(s)
 Print Thread
aArtisanAutotune: PID Autotuning for aArtisan (CR3 / TC4)
Figuring out decent PID parameters for aArtisan and other home roasting Arduino sketches can be tedious. I have written a small sketch that does it automatically using a choice of several industry standard PID tuning algorithms. It is available here:

The sketch works with TC4 or CR3 based setups, and is flashed to the Arduino instead of the usual aArtisan / aArtisanQ_PID sketch. (Once autotuning is complete you flash back the original sketch.) It is very limited at the moment: Only OT1, OT2 and IO3 are supported, the heater (control variable) has to be on OT1. Only TC channels 1 and 2 seem to work properly. No ZCD / AC fan support (except setting the fan to 100% duty cycle).

Feel free to give this a go if you are interested, and do let me know how you are getting on with it. Keep an eye on your roaster during the autotune process - absolutely no guarantees that this sketch won't overheat it!

How it works: The PID Autotuning algorithm works by starting with the roaster already in "equilibrium", i.e. with the heater output constant and the temperature stable somewhere in the range that will be of interest in practice. The algorithm then successively increases then decreases the heater output above and below this steady state level, and measures the system's response. From this some reasonable PID parameters can be computed. Multiple algorithms are available that might give slightly different results.


* Copy the user.h from your aArtisan sketch into the directory with the aArtisanAutotune sketch. Not all settings from this file will be applicable to this sketch, but some (e.g. PID_CHAN) do matter.
* Make sure you have all libraries required for the aArtisan sketch installed, as well as this Autotune library:
* Compile and flash onto your Arduino.
* Connect in Arduino Serial Monitor.
* You must first get the roaster to some steady state that is reflective of what will be happening during roasts, i.e. pre-heat it to somewhere in the usual roast temperature range and wait for the temperature to settle. Use "OT1 xxx", "OT2 xxx" and "IO3 xxx" commands to turn on fan (if needed) and adjust heater level to achieve desired equilibrium temperature. Note that you must use exactly one whitespace and three digits, e.g. "OT1 050", not "OT1 50".
* Use "TUNE xxxxx yyyyy zzzzz n" to start the tuning algorithm, where xxxxx gives the size of the output step, yyyyy gives the noise band, zzzzz gives the lookback, and n selects the tuning algorithm. See below for more details. Again you must use the exact number of digits for each parameter (e.g. "12.34", "00012", "12345" are all okay, but "123" is not.) Example: TUNE 10.00 5.000 30.00 1
* The sketch will output status to the serial console periodically, in format Ambient Temperature, TC Temperatures 1-4, Levels OT1, OT2, IO3. TC channels 3 & 4 might have wrong readings due to a bug. Check this to make sure the temperatures stay safe; if your roaster is overheating unplug it immediately and restart with a smaller output step / higher fan duty.
* When the tuning is done the computed PID parameters will be displayed on the serial console. Note this down for future use.
* Reflash your aArtisan sketch and use the computed parameters in Artisan.

The TUNE command:

TUNE xxxxx yyyyy zzzzz n

xxxxx gives how far to step the output. Choose this based on your real-world usage. If your roast usually is between 60 and 80 percent heater output, pre-heat the heater to 70 percent output, and use 10 percent output step.

yyyyy gives the noise band, i.e. how much temperature readings will fluctuate due to random noise. This will likely be a few degrees or so.

zzzzz gives how far the algorithm should look back for peak detection. Try 30 seconds as a start and see if it works.

n lets you select among different tuning algorithms. Ziegler Nichols PID (1) worked for me, the full list is:


E.g. TUNE 10.00 5.000 30.00 1
Edited by mg512 on 07/12/2018 10:43 AM
The problem is not finding the PID parameters, because the PID implementation itself is flawed, not appropriate for such process with a continuously moving target point, and should be replaced with other paradigm.

For example, if almost all are obsessed about RoR evolution, why not focus on control of the rate itself ? instead temperature setpoints, the main reason of PID usage spread.
I got a confirmation of this approach from all fellow roasters in my community, some of them pros, who confirmed me that during roast they watch more carefully the trending lines than the profile graph itself ;)
Edited by renatoa on 07/07/2018 6:39 AM


renatoa wrote:

The problem is not finding the PID parameters, because the PID implementation itself is flawed, not appropriate for such process with a continuously moving target point, and should be replaced with other paradigm.

Are you sure about that? My understanding is that PID can deal with moving set points; just that there is a tradeoff between good set point tracking and good disturbance rejection. Hence the importance of fine-tuning the parameters.
Pretty sure, abandoned PID long time ago, tired to fight against its logic.

The coffee roasting process is a type of process called Integrating Processes, so are called the processes where the output controls the rate of change.
Our bad luck was that the PID idea was been borrowed from industry probably, where such processes are not so common, but guess what, they are the rule in the hobby areas ! the most obvious example being the 3D printer head temperature control.
So what's wrong with PID and an Integrating Process... ? it overshots as a rule, by its own nature ! You can play with coefficient to minimize overshots, but not remove them completely, and RoR magnifies these overshots awfully...

A particular issue of the PID implementation in the two most popular roasting software, Artisan and TC4, is they don't use the complete PID formula, which has 4 terms, not only three.
There is an additional bias/offset/younameit term which is missing, the result being the control become too dependent on I factor, which make it sluggish, the bigger the I the most latency is added. And prone to overshot...
Let's give an example with the default values, which are the most popular, that many people don't even change them Grin P = 5, I = 0.2
How we should read these values... if we assume we start from ambiant temperature 25C and we have a first setpoint at say 150C, the P term 5 will drive the output to 100% until the difference is 20 degrees, so until 130C. From there the output will decrease proportionally, 5% every degree. So at 140C the output will be 50%, and here we have a first issue... what if my machine needs 60% power to keep system temperature at 140C ? who will bring the 10% difference ? The I term, obviously, but its action not instant ! The 0.2 value of I term tell as that for 10 degrees error the I term will add 2% to the output every second, cumulative, thus we need 5 seconds to make the missing 10%.
Even worse, when we reach setpoint, the P term is zero, no more contribution to output, which must be maintained by I term alone, even more latency added...
And also take care that in those 5 seconds the setpoint moved away by 1 degree !
Was just a simplistic example, for those not aware what boils inside a control system, but I hope clear enough to understand the traps of the classic PID.

There is a partial cure, that can make things better, to introduce this fourth proportional permanent bias term, and make it proportional with setpoint, not with error ! This trick is called Proportional On Measurement, and exists in PID theory for decades, is not a recent invention.
For example a cruise control of a car works this way, they have a fuel flow that increase proportional with the speed (temperature in our case) and a very small drops flow correction to keep the speed constant around the value set by the pilot.
The PID code of Arduino and TC4 are based on the work of a guy called Brett Beauregard, who did a very popular library for Arduino, he was been credited for his work. The lack of this term proportional with the input was actually borrowed from Brett code, not a fault of the Artisan/TC4 authors.
Brett added Proportional on Measurement to his PID for more than one year now, wondering why roasting software hesitate to adopt it, when the changes are some lines of code only... but some big mind twisting in the tuning philosophy... Grin
PoM would be the most immediate solution to the PID problem I exposed above, that's why I mentioned it, but my very personal preference goes into a complete different direction/approach.
As I already told in a past post, a roasting profile can be described by a fairly simple thermodynamic equation. For every equation we can compute the first derivative, i.e. the rate of rise. All I need to do is to calculate the rate for a given point of the roast, specified by temperature, not by time, compare this future expected growth with the trend of past 15 seconds window values, and perform a small, within 1-2 percents, correction of the heater pwm.
Edited by renatoa on 07/07/2018 9:31 AM


renatoa wrote:
The coffee roasting process is a type of process called Integrating Processes, so are called the processes where the output controls the rate of change.

Hot air roasters are not integrating processes.

Anyway, this would get off topic, so I'd suggest we leave it or move the discussion elswhere. I'm not saying autotuning solves all control problems in home roasting; but for those struggling with tuning their PID it might be a useful thing to try. Let's keep this topic for discussing the autotuning sketch.

One point to note: I've found PID performance much better if temperature and initial set point are close together. I.e. either pre-heat the roaster & beans to whatever temperature the background profile starts at, or having the background profile start at room temperature.
The last paragraph tells a lot about a PID ability to follow a profile.

Let's consider the case of a machine with preheat... when the beans are loaded a PID will drop the power completely, which is the first wrong thing it does, the manual roasting guys will tell you that the last PWM% used to stabilise the machine to preheat temperature, say 40% for 200C, must be maintained until TP.
Sure, this is not the PID role, to think so out of the box it was been designed... that's why I say we no more need PID thinking.

Also the behaviour just above TP... a PID will not start to pump power when the profile approach, to lower the temperature drop speed, and make a nice seamless landing on the profile. Instead, will let the drop to continue, because an undershot must happen to start some output, without error it is not able to pump anything into heater.

This behaviour can't be changed by any pid coefficients I am afraid...
I don't have first-hand experience with drum roasters; with my popcorn roaster PID does very well. But again, I think a full discussion of the merits of PID vs. other control algorithms would be way beyond the scope of this topic. Let's discuss Autotuning here.
Tom Coxon (Roastlogger) did extensive work with PID within Roastlogger for small electrically heated drum roasters and a while back was trying to set things up to allow applying multiple PID settings to a roast session. One setting at start of roast once the roaster was warmed up through end of drying then one up through just prior to start of 1C then during 1C and another between 1C and end of roast. I never heard how this ended up and if people were having success with it. Obviously with a drum roaster with it's inherently large hysteresis, PID is a huge challenge but I had very good luck with my 1 lb fluidbed controlled by a Fuji PXR4 using multiple ramps and a single PID setting up until 1C . The problematic bean temperature sag occurring at 1C always has the ability to give a controller anxiety issues and ends up losing it's way from there on.

Glad to hear you're delving into this subject as it has stumped many over the years. It has the reputation of being black magic and unsolvable for many.

1/2 lb and 1 lb drum, Siemens Sirocco fluidbed, presspot, chemex, cajun biggin brewer from the backwoods of Louisiana
Granted, a drum roaster can't respond the temp changes quick enough but with the right air roaster and proper setup, I don't think you can match the control a TC4 and RoastLogger will give you. At least not with anything available to the average home roaster.
I know the way I have mine, I can match any profile and hit any setpoint within a second or two.
Thanks for the encouragement, Allen! Multiple different PID parameters might be one approach. You could still try autotuning all of them. ;) Something more elaborate than PID would be best of course. I have some ideas on that (but little time), and will certainly keep looking into it.

What exactly happens at first crack with bean temperature? I haven't really paid too much attention to that yet, since my popcorn roaster is way too loud to hear the cracks anyway...

Ben, just to make sure I understand correctly: You are saying that automatic PID control with Roastlogger is the best you can do? Or that manual control is best and PID won't be able to match it?
I'm saying I use the TC-4 and RoastLogger to control my roasters heat and A/C fan speed but I do it in a way that most say won't work. However, Tom Coxon, the guy that developed RoastLogger says I have the best control he's ever seen. I corresponded with him regularly when I first started using the TC4 years ago. He even made changes to the program on my request, making the 60 second delay at the start optional because that 60 second delay screwed up and air roaster and the option to turn the heat turn off automatically at end of roast.
He asked me about writing a users guide on how I controlled mine and was looking at doing that, but have met so much controversy on my method I decided you couldn't pay me to write one. Just like the comment, a PID only works when controlling a steady state and can't be used to control a curve. So, I just keep on keep on using my PID to control what it "can't control", with very good results.

A couple of things I do: Most of which others claim you can't do.
I use T1 as Bean Temp and my reference
I use RoR for calculation after the initial start point but sometimes use other methods for the initial start
I use a very sensitive, fast responding bead probe for my bean temp but location for it is very critical. Location of the bead on the Probe was the hardest part of the whole setup to find. A quarter to a half inch in any direction from where it's at and it's not right.


renatoa wrote:
For example, if almost all are obsessed about RoR evolution, why not focus on control of the rate itself ?

Isn't the RoR a "relative" value in the sense that you could have the same RoR curve for different temperature curves, for example in case one temperature curve having a constant offset to another one both would have the same RoR curve, right? Confused.
Two curves having same allure but shifted in time means different start, a longer charge for one than for the other. Nothing to influence the final result that much.

What is more important to note in both cases, is that when we read RoR 15 at minute 3 or 4 we can't make any judgement based on this information only, but when we read RoR 15 at 150C, then we are in game... I know I must decrease RoR by one degree in the next some seconds.
Thanks for sharing your work, I think getting the controller optimised is essential, regardless of the flavour chosen or of the method of generating control variable which, of course, is compared to setpoint temperature.
I can't immediately comment on using the sketch because I just realised I have the wrong thermocouple interface in my hardware.
Maybe it's worth adding to your top post that another sketch must be installed from github into Arduino's library folder. Thanks again !
The way I do mine is:
Say my turn temp is 140F and end of dry (beans at their lightest color) is 300F and I want it to hit that in 4.00 minutes.. I make a setpoint of 280F to give the roaster time to respond to the next RoR, and use I use a RoR between the 140 and the 280 that will let the bean temp hit 300F in exactly 4:00 minutes. My next set point is when the beans are their deepest yellow, say 320 in 5:00, I use a RoR that will hit that exactly. My next would be just as the mallard is just to a cinnamon, say 340F in 6:00, I use a RoR that will meet that. From there. say I want a rolling FC at 9:30, and that's at 390F for the beans I'm roasting, I set a RoR that will hit that exactly. Then I set the RoR I want for development and end the roast manually when I reach the temp I want. All my setpoints are several degrees below my desired point so the roaster has time to change to the next desired RoR.
I can make a half dozen back to back roast and every set point and temp will be within seconds of each other.
Now, like I said before, this is not in a constant arc, it's straight lines with bends at each setpoint, but the bean temps are on a constant increase there are never any decreases in the temp.
If you want to complicate the whole process with a whole bunch of setpoints, you can make it give you the steady arc you get with a drum roaster or using a set environmental temp and time that would give you that arc
Edited by BenKeith on 07/12/2018 11:17 AM
Does anyone got usable result with this mgerstgrasser Autotuner ?
What values results for a specific machine, hotgun for example, if possible, to match what I tried to tune today?

My input parameters were 48% PWM, where the temperature is about 215 C degrees, and +/- 10% step, i.e. 38-58%, with a temperature swing about 200-230 C.
No usable values for P/I, both infinite, but process not failed, nor converged, finished ok, but unrealistic values.
The ultimate gain found is 1.32, and ultimate period 37.55
According to other knowledge sources, this should led to P = 0.6 and I = 32 ! Hard to swallow values either...

Analysing the code, I think there is something fishy about the way how the oscillations are created... they seems forced, instead free/self-sustained, as should be, according to theory...
Will dig more, but until then, any success story ?
Edited by renatoa on 08/29/2018 1:22 PM
... reply instead edit... mistake
Wiz Kalita
I'm getting some very strange results with the autotuning. When I use Artisan with the firmware PID I get ok results with kp = 0.9, ki = 0.6, kd = 0.4. When I tried Ziegler Nichols PID autotuning with these initial settings I got the following output:

amplitude 17.50
absMin 184.75
absMax 221.04
convergence criterion 0.04
ultimate gain 1.37
ultimate period 159.09
TUNING DONE!! kp = 0.42802162; ki = 0.00538092; kd = 8.51166534

With these settings, the output flickers on and off occasionally and it never gets much higher than room temperature. Am I doing something drastically wrong? Modified popcorn popper.
159 seconds cycle time for a popper, the fastest and lowest inertia machine, sound unreal...
Wiz Kalita
I agree that it's very strange, but it does take forever for it to converge. If I set the output directly and leave it, it's still increasing a little after five minutes. What are more common PID parameters people use?
Toothbrush and a particular machine PID does not share Grin

Even on a given machine a PID values set is optimal only for a part of the profile, was already enough rant that PID philosophy does not suit a sliding setpoint application.
Better tune yourself the manual, boring, time consuming way.


Wiz Kalita wrote:

I agree that it's very strange, but it does take forever for it to converge. If I set the output directly and leave it, it's still increasing a little after five minutes. What are more common PID parameters people use?

Whoops, apparently I didn't turn notifications on for this thread, only just saw your post as well as Renatoa's.

Renatoa: Which method did you use that gave the infinite values?

Wiz Kalita: I'm not sure what went wrong with your results. For comparison, what I got on my own popcorn machine roaster is kp=5.00, ki=0.09, kd=32.00. So your results look like they are similar relative to one another (kd large, ki tiny, kp somewhere in between), but just much smaller.

For both of you, maybe try a larger output step (e.g. set the heater to 50 and use 50 as an output step). When I wrote down the instructions I made up numbers more or less, as I wasn't sure anymor which settings I used myself to be honest. I made this sketch a few months ago for my own usage and didn't look at it much after that, only published it recently after someone asked for it for their CR3 board.


mg512 wrote:
Whoops, apparently I didn't turn notifications on for this thread, only just saw your post as well as Renatoa's.

Thread notifications seem to automatically turn themselves off after some time. Maybe a month?? It's annyoing.
Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
Setting up TC4 / Arduino / aArtisan ROASTING SOFTWARE APPS 11 07/11/2020 7:58 AM
Installing aArtisan hiccups with htc/tc4c Dataloggers/Controllers/Rate of Rise Meters 3 06/16/2015 5:34 AM
What hardware to buy for aArtisan? ROASTING SOFTWARE APPS 7 02/04/2015 4:28 PM
TC4 with aArtisan and ambient temp Dataloggers/Controllers/Rate of Rise Meters 9 09/30/2014 4:32 PM
aArtisan won't get RoastLogger temps in "F" Dataloggers/Controllers/Rate of Rise Meters 5 06/25/2014 10:53 PM
Homeroasters Association Logo, and all Content, Images, and Icons © 2005-2016 Homeroasters Association - Logos are the property of their respective owners.
Powered by PHP-Fusion Copyright © 2023 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX
Hosted by skpacman