topbanner.gif
Login
Username

Password




Not a member yet?
Click here to register.

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

JackH
04/23/2019 10:55 AM
Hello Ken! What's roasting?

snwcmpr
04/22/2019 5:07 AM
Hi all.

Gigimedrano
04/17/2019 6:33 AM
Hi guys, my hot top has stripper a gear.. ive only had it for a lil over a year now hot top wants 120+ for a new motor and gearbox assembly any idea? Is this normal year and some Months dont seem lik

Ray Kahuna
04/16/2019 8:04 AM
has anyone built an adjustable coffee grind press?

Nitesh
04/01/2019 10:04 PM
Hello, I have been trying to get in contact with manufacturer of HB roaster in China but failed until now. Does anyone have idea who is the manufacturer of HB roaster in China?

Users Online
Guests Online: 2

Members Online: 1
JitterzZ

Total Members: 5,920
Newest Member: xoffender
In Memory Of Ginny
Donations

Latest Donations
renatoa - 2.00
JitterzZ - 50.00
PRABHATH COFFEE WORKS - 10.00
John Despres (Scene... - 25.00
snwcmpr - 10.00

View Thread

Who is here? 1 guest(s)
 Print Thread
Easy PID tuning with Ziegler-Nichols
marcov
Hey,
I recently needed to tune the PID for my newly built popper.

After logging an open loop response with Artisan, I did not feel like printing the plot and drawing the Ziegler-Nichols "lines" manually.

So I started playing with Octave (the free version of MATLAB), and in the end I wrote a set of scripts to automatically compute Kp, Ki, Kd from an Artisan CSV log file. You also get a plot with what's need for Ziegler-Nichols (see attached picture).

You can find the code here: https://github.co...ov/pidtune

Have fun and let me know if something needs to be fixed.
marcov attached the following image:
example.jpg
 
renatoa
And some numbers for your machine ?
Better profile following ? Grin

There is a similar thread here:
https://forum.hom...ad_id=5598

... not aware that something changed since then, PID tuning is not easy, and not for a continuous moving target.
 
marcov
I got these for the step response above: : Kp = 12.10 Ki = 0.46 Kd = 79.86

I logged the step response from an empty machine, as I didn't want to "invest" some beans for the tuning.

About profile following, it's acceptable in the end.

I read some of your posts about the inadequacy of a stock PID for following a profile, and now I am curious to try out the proportional on measurement add on.
marcov attached the following image:
tuned.png
 
Wiz Kalita
The heat looks pretty jumpy, that's what I've gotten out of Ziegler-Nichols as well. As far as I understand it's made for quickly reaching a fixed target at the expense of stability in a non-integrating process. Whereas we have a moving target in a somewhat integrating process where stability is more important than responsiveness. I control on ET and use POM, Kp = 0.8, Ki = 0.2 and Kd = 0, and I have decent results on a popper. It's lagging behind the background a bit, but that's what lookahead is for.
By the way, where are your probes placed? My ET probe measures the incoming air, and it's only lower than BT if it has come loose and is touching the wall.
Wiz Kalita attached the following image:
annotation_2019-03-17_183106.png
 
mg512
Oh, nice! I have experimented a little as well with PID tuning on my roaster. See the link that renatoa posted. Admittedly the Arduino sketch is pretty rough around the edges. Since it's running the tuning algorithm on-board, there's not much memory left for more than an absolute minimal command interface, and even then I think there's a few bugs in there.

Still, for me this gave reasonable results. It's not perfect, but I don't know for sure if the remaining instabilities are due to the PID tuning, or noise on the temperature measurements, or other reasons. It's working well enough for me in any case.

More generally, I think it's worth noting that there's a fundamental difference between the dynamics of drum roasters and those of fluid bed roasters. I think difficulties with one don't necessarily correspond to difficulties with the other. Neither of them are purely on one side or the other, but drum roasters are closer to integrating processes, while fluid bed roasters are closer to self-regulating processes, for instance. (As far as I understand it.) I don't know enough about about proportional-on-measurement to say much about it, but it sounds like it is worth trying if regular PID doesn't work well enough. Don't use Ziegler-Nichols or other autotuning methods with POM though, obviously.

Marco, I would absolutely do the PID tuning with beans in the roaster! On my popcorn roaster, the dynamics are completely different if it's empty. It doesn't need to be nice beans, in fact it doesn't even need to be green beans. Any old roasted beans you have lying around? Or get the cheapest ones at the supermarket. Worst case try popcorn. ;)
 
https://www.tindie.com/products/15798/
renatoa
chickpeas... almost same roasting characteristics, less the crack, and here 5 times cheaper than coffee.
 
marcov
Wiz Kalita wrote:
I control on ET and use POM, Kp = 0.8, Ki = 0.2 and Kd = 0, and I have decent results on a popper. It's lagging behind the background a bit, but that's what lookahead is for.


How did you end up with those Kp,i,d values? I have no clue what to use in my case.

And what lookahead value are you using? I am between 5 and 10s.

Wiz Kalita wrote:
By the way, where are your probes placed? My ET probe measures the incoming air, and it's only lower than BT if it has come loose and is touching the wall.


I drilled a hole in the metal "funnel" connecting the basket to the lower heater and fan holder. My ET rate is a good predictor or the BT derivative in my case, but I don't use it for anything else a.t.m.
 
Wiz Kalita
marcov wrote:

How did you end up with those Kp,i,d values? I have no clue what to use in my case.

And what lookahead value are you using? I am between 5 and 10s.


I did some preliminary testing with a load of failed, already roasted beans, using the wild-ass-guess method. Tried to track a curve based on ET and adjusted the parameters based on how much it lagged or how unstable it was until I was satisfied, based on the figures here. ET measured before the beans is relatively independent of the bean load so it translates well to green beans. It's still not perfect and I try to tweak it sometimes. I'm not at home and can't check my laptop, but I think I use a lookahead of 12 seconds.
 
marcov
Thanks for clarifying.
Based on your values, if I understand correctly, your POM is almost like a "I" only regulator: Kp is low, and we know that T moves slowly compared to the sampling time, so the conservative effect of the PoM is very light.

BTW, at the page you linked the proportional term is computed as:
-Kp * (Input[t] - Input[t=0])
while in the PID library code it is computed as:
-Kp * (Input[t] - Input[t-1])

That's quite a big difference, isn't it?
 
renatoa
Moves slowly is relative, and depends equally on resolution, as sample time too.
RoR 10 C/min means one C degree every 6 seconds, so 0.17 C degrees per second.
Guess the sample times should be significantly different for 0.25 C resolution, or for 0.025 C resolution...

Regarding the Brad PoM implementation in his library, already wrote here:
https://forum.hom...post_67882
... that my opinion it is faulty. P term is identical to D term as formula.
 
Wiz Kalita
That's interesting, looks like an ID controller could do the same job then. ;) Still, I'm not sure what more you want from it if it actually tracks the temperature profile. My peak ROR is 60°/minute, which in roasting terms should be quite fast.
 
marcov
That's true.

On my side, I am kind of lost with PID tuning, I can't avoid the oscillations I posted in the picture above with regular PonE.

I tried to play with PonM, but I can't find a correct set of parameters with wild guess only.

I am now kind of lost. I tried 3 different PID implementations, includig the flightgear one, but it's not making things better.

I'll have to stick for some time to the manual mode, but being a engineer it hurts...
 
greencardigan
marcov wrote:
I can't avoid the oscillations I posted in the picture above with regular PonE.

I feel that all your parameters might be too high for PonE.

On my smaller (350g) air roaster I use P=5, I=0.15 and D=0
On my larger (1.5kg) air roaster I use P=4, I=0.03 and D=0

I would suggest trying something a bit higher than my 350g roaster. Maybe P=6, I=0.3, D=0.

I've never tried any auto tuning, just trial and error. I find something that is useable testing with junk beans. Then just tweak slightly each following roast and compare the resulting profiles.
 
marcov
I did some more testing and ended up using P=2, I=0.11, D=22.
I still have some overshots to fix, what would you suggest to change based on the picture?

I am using the flightgear PID, as suggested by renatoa in some other threads.


About POM, wouldn't make more sense to have a "proportional on setpoint" for our case?
marcov attached the following image:
anotherpid.jpg
 
renatoa
Wondering how you arrived to that big value for derivative term...
It could be good for a machine with preheat, to slow the drop after the charging, but for a profile starting from zero the effect is questionable.
 
renatoa
You can't avoid oscillations with PonE, is the beast nature. At setpoint the P term should be zero, and in order to drive the heater with I term mainly it must exist an error... that led to an overshoot, that clear the I term, lower the power, that led to an undershot, so another error that accumulate and drive the power up, and so on...
Brad explain well the issue in his PonM introduction, only the implementation is not right.

Being an engineer too, after reading marcov post, thought last evening about a personal vision about how a well done PonM should look... will sketch it below if anyone want to try, I don't have a roast scheduled until weekend.
So, reviewing my roasting notes, is somewhat obvious that we should have a continuous power increase proportional with setpoint value (the PonM component), and a fine tune component, the I term.
On my machine the value of this P(onM) term should be 0.40, because I have heater around 80% in the 200 C temperature ballpark of FC.
This term will give me 60% heater when dry phase ends at 150 C, which is close enough to the values I have during real roast, in the 64-66% ballpark.

So I propose to anyone interested to test this approach with a real roast, to access PID_v1.cpp, and change at line 80, from:

Download source  Code
output = kp * error;




to

Download source  Code
output = *mySetpoint * kp;




so change the P term weight from error to setpoint dependent.

Don't forget to change your actual Kp, from the big value to something computed as above, heater % / temperature at FC, the result should be close to 0.40 value, in the 0.3-0.5 ballpark, if out of these limits there is something wrong with your setup.

I term also can be estimated pretty exact, watching when you have the biggest difference between set value from profile and BT, and what interval this difference has been accumulated.
For example assuming at 150C the BT was spot on the profile, then 20 seconds later you have a 2 degrees difference, then an I term of 0.1 should compensate this and keep BT on track.

PS: this post was been typed in my morning and posted in the evening, some 10 hours later, no idea why it didn't posted first time, not firm enough click on Post perhaps...
 
greencardigan
renatoa wrote:
Regarding the Brad PoM implementation in his library, already wrote here:
https://forum.hom...post_67882
... that my opinion it is faulty. P term is identical to D term as formula.

You should raise this with Brett as an issue on the Github page? https://github.co...ID-Library

I do notice that the Artisan PonM code has the following. Note dtinput used when calculating D rather than dinput.

Download source  Code

dinput = i - self.lastInput
dtinput = dinput / dt
...
self.Pterm = self.Pterm -self.Kp * dinput
...
D = - self.Kd * dtinput




If PID cycle time is 1 second, does this mean that Brett's code (TC4 implementation) works ok in that case?
 
Wiz Kalita
marcov wrote:

Thanks for clarifying.
Based on your values, if I understand correctly, your POM is almost like a "I" only regulator: Kp is low, and we know that T moves slowly compared to the sampling time, so the conservative effect of the PoM is very light.

BTW, at the page you linked the proportional term is computed as:
-Kp * (Input[t] - Input[t=0])
while in the PID library code it is computed as:
-Kp * (Input[t] - Input[t-1])

That's quite a big difference, isn't it?


After looking at the code, I disagree with this. The reason is that output (not outputSum) is reset each loop. outputSum is not reset unless it clips, so any values added to it are integrated. In both PonE and PonM, ki * error is added to outputSum each loop and so adds up.

In PonM, output is set to 0 each loop and -kp * dInput is added to outputSum. kd * dInput is added directly to output and is not stored in the running outputSum variable. So the difference between the two is that in PonM the proportional term is given by the integral of the derivative, and this builds in t=0.

So for the two cases, the loop boils down to the following:

PonE:
Download source  Code

outputSum+= (ki * error);
output = kp * error;
output += outputSum - kd * dInput;




PonM:
Download source  Code

outputSum+= (ki * error);
outputSum-= kp * dInput;
output = 0;
output += outputSum - kd * dInput;


 
renatoa
The result of continuously integrating (sum) dInput values is, at every moment, input(t) - input(0).
Please check below how all intermediate inputs does not matter, because they clear each other:
outputSum = -(i1-i0)-(i2-i1)-(i3-i2)-...(in-1-in-2)-(in-in-1) = -(in-i0)
 
Wiz Kalita
Yes, that's what I mean.
 
Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
PID TUNING HELP - Artisan Dataloggers/Controllers/Rate of Rise Meters 30 03/26/2018 7:15 AM
PID Tuning - TC4 Dataloggers/Controllers/Rate of Rise Meters 41 12/17/2017 4:35 AM
PID tuning help - for air roaster, TC4C and Artisan Dataloggers/Controllers/Rate of Rise Meters 4 05/31/2017 12:26 AM
simple and easy cooler Bean Cooler 11 03/16/2017 1:43 AM
Bean Insert & Cooler to easy Bean Cooler 11 06/14/2016 1:26 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 © 2019 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX