I am a bit confused by your last statement, so let me see if I am clear on this. You are suggesting that I decrease my integral gain? It is currently close to zero at 1.50. I have found that I need the integral or it just wont reach the temperature without it. I suppose i could go into the decimal area only something like 0.89.
You stated that my system is slow and true it may not be relative but I thought it was quite fast. I am driving from around 0C to 40C in less than 2 minutes. This is heating a unit of liquid and aluminum in a room temperature environment. I can run the other direction in almost as much time as well. Could you enlighten me a bit more on the significance of having a slow or fast system.
Here is a plot with very little min and max values it never reached 40.00C after overshooting it once
Have a look at the third figure and read the text:
"The integral term (when added to the proportional term) accelerates the movement of the process towards setpoint and eliminates the residual steady-state error that occurs with a proportional only controller. However, since the integral term is responding to accumulated errors from the past, it can cause the present value to overshoot the setpoint value (cross over the setpoint and then create a deviation in the other direction). "
Then looking at the section on loop tuning you will see that increasing Ki increases overshoot. So yes I think you should reduce it, don't get hung up on the specific numbers, why shouldnt it be small, if it gets really small perhaps it is telling you the integration time is a bit short.
And your system is slow compared to a Segway or a cruise missle but I wasn't criticizing, it is fast for a heating system.
Graham
Post Edited (Graham Stabler) : 7/9/2008 5:10:49 PM GMT
Graham This is great information. The integrals meaning is more clearer to me. I had a hunch that it was a record of the error from the past. As far as the system speed I was not taking it as criticizing just wanted more specific reasons to clarify your reasons for bringing it up. I am not offended and it is true compared to a cruise missile its super slow, ill keep this in mind when the missile project come my way next time [noparse]:)[/noparse]
So if the integral is the past then then is it logical to state that the derivate is the future?Many have said that the derivate would not be needed in my prototype and though I don't expect rapid changes in the unit should I put more efforts in testing the derivate? It may be used for rapid changes but perhaps a bit of future telling so that i dont overshoot the desired temperature?
The derivative of a function is another function giving the slope or steepness of the origional function. So let's say we take that literally and take the derivative of our altitude as we drive along a road. If the derivative or slope is large and positive then we can predict that our altitude is going to get bigger (we are going up a hill). The greater the slope the greater we might expect this change to be.
So in the controller a steep slope in the error suggests it could get big quickly, that means we had better do something about it if we want to keep the error in check. However this has the potential disadvantage that we might overreact. If we do then we overshoot.
I suspect that derivative is not going to be required in your system unless something is likely to upset the temperature violently, if opening the door does make a large difference over a short time then perhaps you could use a little but I suspect the gain should be low to keep overshoot in check in normal operation and to prevent oscillation.
How about creating a 3stage integral?!
Say, for a setpoint of 50degC, if your temp is >10degC different, then use a Kint of XXX. IF your temp is >3degC but <10degC, use a Kint of XX. For temp differences of <3degC use a Kint of X.
For our radar systems we do something similar to this. It means that when we command a large change, the motors run fast to get us there quickly, then reduce the error gain as we get closer. So there is less chance of us overshooting (although this is sometimes wanted in mechanical situations).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ <FONT>Steve
What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
Lee Travino after the second time being hit by lightning!
Graham Stabler. Yea, I think that leaving the derivative small is the best choice so far. I just thought it would help keep the integral in check by predicting the future and reacting against the integral.
steve_b. This is a great idea and will be my last resort. I have seen some people zero out the integral when the specific condition calls for it. Like when driving to 50c zero out the integral at 45c. My notion was that the max and min values on the intergral would have the same effect as zeroing or as you mention.
- A friend suggested to me that a squared law relative to ambient temperature is what the integral part is fighting (Due to heat loss). I'm thinking you could modify the error into the accumulator or what the integral output represents based on the difference between setpoint and room temperature. This should help linearise the function which can only help performance.
- Further to Steve's idea of dynamic gain and your own favourable results with bounding the accumulator you could try resetting the accumulator whenever the proportional output exceeds some level, say 50%, instead of the tight bounding. This allows for bigger ranges of setpoint while still allowing a strongish gain. Or maybe copying the proportional output to the accumulator at this crossing (This would need a post-gain accumulator).
I should be able to answer questions quicker now,
Evan
Ah, a variant of the prediction ideas is the feedforward components. In servos it is usually a part of the derivative component. However, there is no reason not to make one to your own spec. You could easily have the squared law applied to this part. The way I see it is this would be part of the proportional component, providing a constant output offset dependant on the temperature difference from ambient.
PID in and of itself has no anticipation of future desired changes in output. It is always and only driving down the road by just looking in the rear view mirror.
Within a given "scan" of the process, the Proportional term produces an output which is proportional to the error found during the single scan. The Integral term produces an output proportional to what the error has accumulated to be in all preceding scans (in practice usually a filtered value of the last n scans, where n scans is low integer multiple of the integer gain expressed as a time constant), and the derivative produces an output proportional to the change in the process variable (or change in the error, or change in the rate of change of the error--all three ways work and have their advantages).
For your process, I would ignore the PID until the process value was within a certain value of the setpoint and just keep the output on at 100%, and the turn control of the output over to the PID once the PV was within an experimentally found tolerance band. That would be a first, quick stab at it.
For a very repeatable process, I would graph a schedule of time at 100% output vs. error to be eliminated and then begin to elapse that scheduled time at a "initializing button press", and then turn it over to the PID at the end of that time.
tperkins said...
PID in and of itself has no anticipation of future desired changes in output. It is always and only driving down the road by just looking in the rear view mirror.
Nice way to put it but D is still a prediction of sorts because if you see you are turning sharply in your rear view you can predict that without some serious correction it will get worse in the future. Gradients don't change instantaneously so they do suggest what might be coming even if it isn't the same as knowing the road ahead.
The I term can be limited especially in your case. Temperature is so slow to change. In my UAV project I worked with the autopilot designer to limit the I term in the altitude loop. What we did was really simple.
Put a cap on the accumulated error. In my case, and I don't know yours to well but, I limited the error to +1000 and -1000 that way the error never got out of hand. The UAV would descend at a slow rate (for good reason). When this happened the accumulated error got so big that it would overshoot the target by 200 feet sometimes. By limiting the maximum and minimum error accumulation, the UAV would only overshoot by 20 feet.
hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Digital Technology Group
Also,· I ran into your problem regarding your overshoot magnified by you D term.·
If your D term calculation does not have the current error minus the last error divided by the time constant then the D term will overshoot.
alot of d term calcs look like this:
dterm = KD * (errterm - lasterr)
this is in error.·
This is the proper math for the dterm.· The (.01) is the time from last measurement.· Mine is constant so i don't have a variable there.
dterm = (KD * ((CurrentError·- LastError) / 0.1))
where KD is the D term Gain
CurrentError is the current measured error
Last Error is the Current Error measured on the last PID cycle.
This made all the difference in the world and you will see it the first time you use it.· However, this will also lead to an unstable PID loop if used wrong which is normal in PID tuning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Digital Technology Group
Umm, there is essentially no difference in those two equations. /0.1 is the same as having (10.0 * KD), it's still a fixed constant multiplier.
What would really make a difference is if the time constant was used to define a filter length/strength applied to the errors so as to spread the derivative effect over more than one sample.
Comments
I am a bit confused by your last statement, so let me see if I am clear on this. You are suggesting that I decrease my integral gain? It is currently close to zero at 1.50. I have found that I need the integral or it just wont reach the temperature without it. I suppose i could go into the decimal area only something like 0.89.
You stated that my system is slow and true it may not be relative but I thought it was quite fast. I am driving from around 0C to 40C in less than 2 minutes. This is heating a unit of liquid and aluminum in a room temperature environment. I can run the other direction in almost as much time as well. Could you enlighten me a bit more on the significance of having a slow or fast system.
Here is a plot with very little min and max values it never reached 40.00C after overshooting it once
Thanks
·
Have a look here
en.wikipedia.org/wiki/PID_controller
Have a look at the third figure and read the text:
"The integral term (when added to the proportional term) accelerates the movement of the process towards setpoint and eliminates the residual steady-state error that occurs with a proportional only controller. However, since the integral term is responding to accumulated errors from the past, it can cause the present value to overshoot the setpoint value (cross over the setpoint and then create a deviation in the other direction). "
Then looking at the section on loop tuning you will see that increasing Ki increases overshoot. So yes I think you should reduce it, don't get hung up on the specific numbers, why shouldnt it be small, if it gets really small perhaps it is telling you the integration time is a bit short.
And your system is slow compared to a Segway or a cruise missle but I wasn't criticizing, it is fast for a heating system.
Graham
Post Edited (Graham Stabler) : 7/9/2008 5:10:49 PM GMT
So if the integral is the past then then is it logical to state that the derivate is the future?Many have said that the derivate would not be needed in my prototype and though I don't expect rapid changes in the unit should I put more efforts in testing the derivate? It may be used for rapid changes but perhaps a bit of future telling so that i dont overshoot the desired temperature?
Fred Ill give this a look over thanks
The derivative of a function is another function giving the slope or steepness of the origional function. So let's say we take that literally and take the derivative of our altitude as we drive along a road. If the derivative or slope is large and positive then we can predict that our altitude is going to get bigger (we are going up a hill). The greater the slope the greater we might expect this change to be.
So in the controller a steep slope in the error suggests it could get big quickly, that means we had better do something about it if we want to keep the error in check. However this has the potential disadvantage that we might overreact. If we do then we overshoot.
I suspect that derivative is not going to be required in your system unless something is likely to upset the temperature violently, if opening the door does make a large difference over a short time then perhaps you could use a little but I suspect the gain should be low to keep overshoot in check in normal operation and to prevent oscillation.
Graham
Say, for a setpoint of 50degC, if your temp is >10degC different, then use a Kint of XXX. IF your temp is >3degC but <10degC, use a Kint of XX. For temp differences of <3degC use a Kint of X.
For our radar systems we do something similar to this. It means that when we command a large change, the motors run fast to get us there quickly, then reduce the error gain as we get closer. So there is less chance of us overshooting (although this is sometimes wanted in mechanical situations).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<FONT>Steve
What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
Lee Travino after the second time being hit by lightning!
steve_b. This is a great idea and will be my last resort. I have seen some people zero out the integral when the specific condition calls for it. Like when driving to 50c zero out the integral at 45c. My notion was that the max and min values on the intergral would have the same effect as zeroing or as you mention.
More testing today so wish me luck.
I don't think you want the parts of your controller to fight each other, the error is the enemy [noparse]:)[/noparse]
- A friend suggested to me that a squared law relative to ambient temperature is what the integral part is fighting (Due to heat loss). I'm thinking you could modify the error into the accumulator or what the integral output represents based on the difference between setpoint and room temperature. This should help linearise the function which can only help performance.
- Further to Steve's idea of dynamic gain and your own favourable results with bounding the accumulator you could try resetting the accumulator whenever the proportional output exceeds some level, say 50%, instead of the tight bounding. This allows for bigger ranges of setpoint while still allowing a strongish gain. Or maybe copying the proportional output to the accumulator at this crossing (This would need a post-gain accumulator).
I should be able to answer questions quicker now,
Evan
Evan
Within a given "scan" of the process, the Proportional term produces an output which is proportional to the error found during the single scan. The Integral term produces an output proportional to what the error has accumulated to be in all preceding scans (in practice usually a filtered value of the last n scans, where n scans is low integer multiple of the integer gain expressed as a time constant), and the derivative produces an output proportional to the change in the process variable (or change in the error, or change in the rate of change of the error--all three ways work and have their advantages).
For your process, I would ignore the PID until the process value was within a certain value of the setpoint and just keep the output on at 100%, and the turn control of the output over to the PID once the PV was within an experimentally found tolerance band. That would be a first, quick stab at it.
For a very repeatable process, I would graph a schedule of time at 100% output vs. error to be eliminated and then begin to elapse that scheduled time at a "initializing button press", and then turn it over to the PID at the end of that time.
Yours, TDP
Nice way to put it but D is still a prediction of sorts because if you see you are turning sharply in your rear view you can predict that without some serious correction it will get worse in the future. Gradients don't change instantaneously so they do suggest what might be coming even if it isn't the same as knowing the road ahead.
Graham
Put a cap on the accumulated error. In my case, and I don't know yours to well but, I limited the error to +1000 and -1000 that way the error never got out of hand. The UAV would descend at a slow rate (for good reason). When this happened the accumulated error got so big that it would overshoot the target by 200 feet sometimes. By limiting the maximum and minimum error accumulation, the UAV would only overshoot by 20 feet.
hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Digital Technology Group
http://forums.parallax.com/forums/default.aspx?f=25&m=270711
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Digital Technology Group
If your D term calculation does not have the current error minus the last error divided by the time constant then the D term will overshoot.
alot of d term calcs look like this:
dterm = KD * (errterm - lasterr)
this is in error.·
This is the proper math for the dterm.· The (.01) is the time from last measurement.· Mine is constant so i don't have a variable there.
dterm = (KD * ((CurrentError·- LastError) / 0.1))
where KD is the D term Gain
CurrentError is the current measured error
Last Error is the Current Error measured on the last PID cycle.
This made all the difference in the world and you will see it the first time you use it.· However, this will also lead to an unstable PID loop if used wrong which is normal in PID tuning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Digital Technology Group
What would really make a difference is if the time constant was used to define a filter length/strength applied to the errors so as to spread the derivative effect over more than one sample.
Evan