AHB Wiki: PID Tuning

[TheWiggman]

Because...
P = 500, D = 0.45 - quick ramp but never actually got to target after an hour within 5°C
P = 100, D = 2.00 - slow to ramp, huge overshoot
P = 500, D = 2.00 - quicker to ramp, some overshoot

P = 400, D = 1.00 - moderate ramp, slowly got to target with no overshoot

Main reason I changed P was to see the impact it might have. From what I can gather P and D are related, else wouldn't I max out P to 10000 or what-not? Yes I have referred to the manual, but follow my logic...
Assume P is a powerhouse in isolation then wouldn't it make more sense to just keep pushing P up until I hit overshoot? Then -

• Increase P until I get some overshoot and get a decent ramp rate
• Increase D to remove overshoot. Doughs up system
• Increase P to improve ramp and reduce doughiness, D reduces overshoot.
• Increase D to wind down overshoot
• Repeat

Depending on how i want my system to behave there'll be an ideal P for an ideal D. Hence I'm trying to find that point - which I'd argue I'm nearly at. With D at 1 I'll try P at 600 tonight and see how this behaves, then adjust accordingly if required but this will be based on observation. A tiny bit of overshoot doesn't bother me (as long as it's controlled) but I do want it to ramp quickly to raise the temp of the mash as quickly as possible, which lags a fair way behind the HEx out.

Quick note - my simple mind is getting confused with the term 'gain' in the manual and posts as I've always thought each K value (KP, KI, KD) was the gain for the proportional, integral and derivative terms respectively. However in the manual you refer to P, I and D values in those words ("Set the P value...") and also refer to the gain. It's had me a bit lost anyway, might be worth clarifying.

 

[Adr_0]

You are 100% correct that P and D are related. It makes it harder to see they impact of what you're doing if you're changing both, so I suggested keeping P at 500. There are probably 10 others perfect pairs of P/D values.

I'm sorry about the terminology - I guess I was trying to talk in concepts and capture different types of controllers. P will always be proportional gain, but you enter in value in your controller - either or.

Integral could be a gain, time or resets/time - and the structure of the calculation influences this too. Integral can be tough to get your head around, and you are shooting blindly if you don't know the units. Luckily we don't need it... But it's a good question to ask ("Which units are we dealing with here?") if you work in industry with controllers.

D is also gain, but similarly it's evaluated over seconds or minutes - again very dependent on the configuration of the system, and the value you enter will depend on this. It can also be evaluated as the change in error, or the change in temperature which should be 'summed' differently - just to throw another spanner in the works.

Incidentally, do you have a copy of the code for the controller output calculation, if you're using Arduino?

 

[TheWiggman]

Not sure how much you've played with Arduino, but the PID library is actually a pretty clever one.

Coding examples of the library by the creator here: https://github.com/br3ttb/Arduino-PID-Library/
Details of the functionality here: http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/

Those links probably show the library coding somewhere but I suppose if you have access to the library, if you have the right software you inadvertently have the code right?

 

[Adr_0]

Code looks good. Looks like change in PV/temperature is used instead of change in error. Interestingly though they normalise the ki and kd to 1 second, but still apply it on the same time (100ms). I'm not sure if a longer sample time would be better - it depends on the resolution or minimum change registered on the temperature probe. Might make it jumpier than it should be.

I think your path is ok, to go for P of 500/600 and the D = 1.

P = 500, D = 0.45 - (normalised ratio of 111:1) quick ramp but never actually got to target after an hour within 5°C
P = 400, D = 1.00 - (normalised ratio of 40:1) moderate ramp, slowly got to target with no overshoot
P = 500, D = 2.00 - (normalised ratio of 25:1) quicker to ramp, some overshoot
P = 100, D = 2.00 - (normalised ratio of 5:1) slow to ramp, huge overshoot
*these ratios include normalisation back to 1 second for the kd gain

Have you implemented the code exactly as published in those links? If the change in error is defined and used with 'kd' it should be "ITerm + kd * derror "; similarly it should definitely not be "ITerm + kd * dinput " or " ITerm - kd * derror ". If it's not this, I suspect your problem is that there with the overshoot examples there was not enough gain to keep it under control, and with a sample time of 0.1s your kd gets multiplied by 10.

There is possibly a lot of drive on the initial setpoint change that is ending up as heat in your HEX, then when your coil hits setpoint you still have this sitting there. If you have extra drive from the Derivative action in the intial ramp, this could be made worse.

 

[TheWiggman]

You'll have to ask Mr Wibble that, it's his program I'm using.
Here's an interesting one... I played with the demo sketches and used P and D only as per the original trials Mr Wibble had in there. I didn't have all my flashy screens and such, so had the unit plugged into an SSR and left the controller do its thing. It NEVER got to the target. I hooked it up to my PC and forced a temp value / input (i.e one that would remain constant) to see what the PID would output.
It didn't change.
A big difference between the target and the feedback resulted in 100% output on the controller. If I moved the input up to say within 10% the output would drop to 90% but would never change. If however I added some I the output would creep up until it got to 100% no matter how close to the target it was. Proper PID control. So at the moment I have that set to 0.01 just so it behaves properly, but I'm still not sure why I have to.

 

[Adr_0]

I don't quite know what you mean about 'proper PID control'. I think I understand what you were doing, but correct me if I'm wrong...

It sounds like you have a constant temperature forced, and presumably a constant set point, so a constant error.

Looking at the code this will calculate out to a particular control output (100%, 90%) purely based on the error. Given the temperature is being forced, if is constant, the error is constant so the output is constant.

 

[Adr_0]

And in this case, the I would be the only thing to drive the output any differently. Each iteration of the code will add the error x ki, so will add to the output. This should get to 100%, but the temperature still won't change.

Again, correct me if I'm wrong in my understanding of what you're trying.

The PID control Wiki should cover why brewing systems do not benefit from Integral.

 

[TheWiggman]

I don't quite know what you mean about 'proper PID control'. I think I understand what you were doing, but correct me if I'm wrong...

It sounds like you have a constant temperature forced, and presumably a constant set point, so a constant error.

Looking at the code this will calculate out to a particular control output (100%, 90%) purely based on the error. Given the temperature is being forced, if is constant, the error is constant so the output is constant.

Constant temperature forced, yes. From what you're saying then this behaviour is correct. This is not appropriate behaviour however, and not being a process engineer I can only explain in terms of what I see. From what I can see there is a benefit to integral control which I'm happy to be constructively challenged.

In the manual refer to this pic -



This model assumes there is no heat loss in the system. In reality there is, and there will always be a slight difference between the input temp and the output temp. This difference will be significant to start with but it will creep slowly until it gets to say 0.1°C. To move this temp from 65.9°C to 66°C it will be necessary to add energy, and with a constant output approaching zero it means mathematically the system will stabilise to below the target temp. My observations without any integral control is that the system won't stabilise on the target temp, it will get close but never get there. I've still got my HERMS with 14.5l of water in it I didn't get a chance to brew with on the weekend so I'll run another temp test tonight.

FYI P = 600, I = 0.1, D = 2 resulted in 0.2°C overshoot but stabilised exactly on 40.0°C after about 10 mins of overshoot. The mash tun lagged by about 2°C when the HExout was within 1°C of target. I'm happy with that. I'll try tonight with no 'I' and report back.

 

[Adr_0]

Constant temperature forced, yes. From what you're saying then this behaviour is correct. This is not appropriate behaviour however
Step through the code and calculate what you think the output would be if you had a constant temperature. Think also about what would happen to the 'input' value if there is nothing acting on it - i.e. if it's forced to a constant value, and not being a process engineer I can only explain in terms of what I see. From what I can see there is a benefit to integral control which I'm happy to be constructively challenged.

In the manual refer to this pic -

System.png

This model assumes there is no heat loss in the system. In reality there is, and there will always be a slight difference between the input temp and the output temp. This difference will be significant to start with but it will creep slowly until it gets to say 0.1°C. To move this temp from 65.9°C to 66°C it will be necessary to add energy, and with a constant output approaching zero it means mathematically the system will stabilise to below the target temp. My observations without any integral control is that the system won't stabilise on the target temp, it will get close but never get there. I've still got my HERMS with 14.5l of water in it I didn't get a chance to brew with on the weekend so I'll run another temp test tonight.

FYI P = 600, I = 0.1, D = 2 resulted in 0.2°C overshoot but stabilised exactly on 40.0°C after about 10 mins of overshoot. The mash tun lagged by about 2°C when the HExout was within 1°C of target. I'm happy with that. I'll try tonight with no 'I' and report back.

You raise a good point - there is definitely energy leaving the system, but it doesn't make the system self-regulatory, and doesn't result in a steady-state error. The main thing that would make it self-regulatory is a mass flow - going back to the heat balance equations in the Wiki. Considering the energy lost from the mash tun walls, pipe, etc., we're still left with a °C/min steady temperature drop, rather than a °C steady state error in a flowing system. In the Wiki it talks about insulation. Insulation is analagous to energy - it can completely remove that energy loss (W or J/s). If you only use a bit, putting it between your sensing temperature probe and your mash tun will help with getting these temps as close as possible.

Read the very next part in the Wiki past the diagram. Practically speaking, you could very well use a very long integral time (30, 60min) or - considering the arduino is in gain - a very small gain. The reality is that it doesn't correct any steady state error, and only contributes to overshoot. The very small amount that would be appropriate might as well be zero. I have tried to keep things simple, but I can appreciate it's sometimes fun to over-complicate things.

The loss to surroundings is a °C/min, and a proportional output on the element also gives °C/min which can be balanced perfectly. I think the problem you are seeing is either being caused by the Derivative action on the controller - have you actually tried it with P only? - or is the result of flow mixing of this temperature in the mash tun. Your answer depends on where you're measuring with your controller.

Which brings me to my next point... if you control on the coil outlet temperature, there is no reason why you can't get to a setpoint and hold this very well with P or PD. The mash tun will take a while to catch up - likely a very long time with a low flowrate - as it's relying on the mechanism of mixing. To get a good response in your mash tun, you can either use extra temperature or a high flow - so a bit of overshoot in your coil will probably help you if you get it right. If your system has inherent overshoot, why introduce more with I? That's what D is for, or P.

And finally, the response you described (0.2°C overshoot for ~10min, settling down to the SP) can be achieved with PD only - or possibly even P only. If you read through the Wiki you will realise that my overall tone is to keep it simple and you'd be surprised how well P will do. If you have inherent overshoot, D will help out. Adding any sort of I will introduce overshoot, which makes things unncessarily complex. Your system sounds like it has some inherent overshoot (caused by lag) so I would have suggested you're on the right track with the system you have trying for a P of 500/600 and a D around 1... but you're ultimately welcome to try whatever you wish.

 

[TheWiggman]

When I've tried to describe PID (or any discrete component of it) to others I've likened it to standing in a room with a heater on the other side. The heater heats up the space between you and it. If you turn if off once you're comfortable, the heat will continue to travel and disperse through the room resulting in more heat than you want. By the time you're comfortable again and you turn it back on, it takes a while to heat back up and you get too cold.

Back to mashing, I think where my logic is differing here is that I am assuming that when the element stops heating that there will be no increase in temperature of the output from then on. If this were true then my comments in post 28 holds - I have looked through the code, and you will never reach target temp with P only (because when the error is zero the output will be zero). If residual energy remains in the HEx vessel such that the temperature is higher than the target that will still transfer heat to the mash, there is potential overshoot if P is too high.

Time for a play again tonight.

 

[Adr_0]

When I've tried to describe PID (or any discrete component of it) to others I've likened it to standing in a room with a heater on the other side. The heater heats up the space between you and it. If you turn if off once you're comfortable, the heat will continue to travel and disperse through the room resulting in more heat than you want. By the time you're comfortable again and you turn it back on, it takes a while to heat back up and you get too cold.

Well no, you're just describing a system with a lot of capacitance (a long time constant) and/or a long deadtime, using on/off control. PID control should be able to use a 0-100% output on the heater, consider the ramp rate and distance from the setpoint, and get the temperature correct.

Back to mashing, I think where my logic is differing here is that I am assuming that when the element stops heating that there will be no increase in temperature of the output from then on. If this were true then my comments in post 28 holds - I have looked through the code, and you will never reach target temp with P only (because when the error is zero the output will be zero). If residual energy remains in the HEx vessel such that the temperature is higher than the target that will still transfer heat to the mash, there is potential overshoot if P is too high.

Think about what you're saying here - when the error is 0 (setpoint - temperature) you are at setpoint/target, so you want your output to be zero. Now if you're controlling off the coil, your mash tun won't necessarily be at the target temperature, but with a high enough flowrate it should introduce cold wort into the HEX, so should actually still have an output on it which will slowly start to decrease.

The system will stop increasing in temperature only if your deadtime/lag is 0 or less than 10 seconds. My STC-1000 (which I use for measurement only) takes about 30-40s just to measure the temperature change, but hopefully your probe is faster than that. But a mixed 1V or RIMS is generally like this. With HERMS there are also capacitance contributors in the HEX vessel and coil, so in reality you will likely overshoot once you've stopped heating - the reason is, as you pointed out, the heat still being retained in the HEX water a few degrees above your setpoint, then heating the wort and overshooting your setpoint.

The correct amount of derivative, coded and set properly, and with enough gain to keep things moving, should notice that the temperature is still rising quite sharply before it gets to the setpoint, so should have wound things back before you get there.

Time for a play again tonight.

When you say 'never reach the target', I'm thinking that you're coming from below, over-damped, so it takes a while to get there. But yes with lag in the system you can overshoot, so I guess you could say 'never reach the target' with overshoot considered. But I have to absolutely hammer the point home that the P will ultimately drive it to the setpoint. The best way to think of this with a home brewery is: for a given steady output, there is a constant rate of change. If you're still stuck in the world of traditional/self-regulating systems, you think of a given output and having a new temperature possibly with a steady-state error. But what if this given output is actually driving at a constant slope up? Your output will be wound back (less slope) and then you're at setpoint, possibly with very minor adjustments to the output/slope - but if you've got a bit of heat loss to the surroundings, this gives you a chance of holding a constant temperature. This is the crux of it: with no mass change in the system, the energy accumulates so you are either constantly warming up or constantly cooling (think up/down straight slopes) so one way or another the P will get you there - it's not stuck with an offset (parallel) because it's constantly sloping up to the setpoint or down away from it.

Trust me - I'm an engineer.

 

[TheWiggman]

Look I don't want to get in a slinging match about this so I'll make a few comments and leave it there.

"Well no, you're just describing a system with a lot of capacitance (a long time constant) and/or a long deadtime, using on/off control. PID control should be able to use a 0-100% output on the heater, consider the ramp rate and distance from the setpoint, and get the temperature correct." - control method is irrelevant, the example was meant to demonstrate why predictive control is required in a system.

"Think about what you're saying here - when the error is 0 (setpoint - temperature) you are at setpoint/target, so you want your output to be zero. " - I understand completely what I'm saying, I don't agree with you. If energy is being lost in the system you need to feed energy into the system at the same rate as the loss the maintain the setpoint. Otherwise an STC-100 will suffice.

 

[Adr_0]

Look I don't want to get in a slinging match about this so I'll make a few comments and leave it there.

"Well no, you're just describing a system with a lot of capacitance (a long time constant) and/or a long deadtime, using on/off control. PID control should be able to use a 0-100% output on the heater, consider the ramp rate and distance from the setpoint, and get the temperature correct." - control method is irrelevant, the example was meant to demonstrate why predictive control is required in a system.

"Think about what you're saying here - when the error is 0 (setpoint - temperature) you are at setpoint/target, so you want your output to be zero. " - I understand completely what I'm saying, I don't agree with you. If energy is being lost in the system you need to feed energy into the system at the same rate as the loss the maintain the setpoint. Otherwise an STC-100 will suffice.

Look, I'm sorry - I misunderstood what you were saying in the heater/wall example, but yes we're on the same page there.

With heat loss to surroundings, yes this will essentially result in a 'residual' output from the controller to balance - but this can be balanced with P control, it does not need I control (which will accumulate and cause overshoot). I still don't know what you mean about never hitting the target with P alone - you will. And in the case of overshoot, yes this could well be because the Proportional gain is too high on a laggy system - the solution to which is some D.

I think you were on the right track in post #21 - hopefully the 600/500 and 2/1 will do the job.

 

[TheWiggman]

Sweet as.
I ran it tonight at P = 600 only and it got close to 35° C but never quite made it. Got to 34.85°C and sat there for about 30 mins which for all intents and purposes is fine. But still didn't get there. I'll do a brew this weekend and report back.

 

[Adr_0]

Sweet as.
I ran it tonight at P = 600 only and it got close to 35° C but never quite made it. Got to 34.85°C and sat there for about 30 mins which for all intents and purposes is fine. But still didn't get there. I'll do a brew this weekend and report back.

Cool, good to hear. Could even try moarr gainz, say 700 or 800?

 

[mr_wibble]

Sweet as.
I ran it tonight at P = 600 only and it got close to 35° C but never quite made it. Got to 34.85°C and sat there for about 30 mins which for all intents and purposes is fine. But still didn't get there. I'll do a brew this weekend and report back.

So you mean P=600, I=0, D=0 ?

You've probably said it already, but what water volume and element are you testing with? (1800watt?)

thanks,
-kt

 

[TheWiggman]

Yes to all the above.

 

[angus_grant]

Just wanted to post a big thanks for the PID write-up. Formalised what I mostly understood from the various papers and parts on the internet.

Tweaked my PID settings and everything looks pretty sweet. 0.06 degree overshoot which I guess I'll live with.

There are actually 2 lines (blue and yellow) in the line graph but they are so close is hard to differentiate them.

 

[Adr_0]

Sweet as! Happy with your step response for larger steps and into the 60's?

 

[angus_grant]

The P value might need some tweaking for higher temps as it took about 2 mins to get from 59 to 60.

Not really worried about that too much. I'll probably end up around 550 or so.

I'll then have to tweak the numbers again once I add grist to the mix. I've just been testing straight water at the moment.

May not even use I or D values at this stage as per wiki. Maybe a fairly small D value of I end up cracking please for faster ramp rates.