Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Thanks for all. typo corrected.
-
The BladeForums.com 2024 Traditional Knife is ready to order! See this thread for details: https://www.bladeforums.com/threads/bladeforums-2024-traditional-knife.2003187/
Price is $300 ea (shipped within CONUS). If you live outside the US, I will contact you after your order for extra shipping charges.
Order here: https://www.bladeforums.com/help/2024-traditional/ - Order as many as you like, we have plenty.
PID Controllers - Everything You Wanted to Know, But Were Afraid to Ask
- Thread starter Cushing H.
- Start date
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Finally, time to talk about the integral portion of PID controllers.
I do not like this mathematical form, but because most (if not all) of the commercial PID controllers use use it, I need to introduce what is known as the “standard form” of the PID algorithm:
Because I am not for now going to talk about the derivative function, I will cut that out, and shorten this equation to the following:
Here, as before, u(t) is the instantaneous value of the output of the controller, which can be of any value, positive, or negative, but if greater than 100, just becomes “100” (because you can not turn that heater on any more than max), and if negative, becomes “0” (unless you have refrigeration handy). Kp is the same as before (the proportional constant), but now we have a new thing, “Ti” which is called the “integral time” (more about this later). Notice that because of the parenthesis, the Kp actually multiplies the integral term, so that the term in front of the integral actually is “Kp / Ti”
Going back to a “word-form” of the equation, this reads like this:
Controller output = Kp * (current difference in temperature from the setpoint)
+ (Kp/Ti) * ( the sum of ALL previous differences in temperature from the setpoint)
(again as with the other form, deviations from setpoint to lower temperatures are taken to be positive values. This starts getting really important with the integral term)
So – what is the “sum of all previous differences in temperature from the setpoint” ??
The wording is a little misleading. This really means multiplying the difference from the setpoint by the amount of time that difference was present.
It is kind of like driving a car. You have somewhere to go, and the speed limit is 60mph (yes, in this example you are driving at 60 max ). You find yourself day dreaming about that next knife you are going to design, and your speed drops to 55 mpg (5 mph below “setpoint”). And you do not notice for 5 minutes. You are behind (distance wise) from where you “should” have been. But … you are not “5 mph” behind (you can not “catch up” to where you “should be” by just going back up to 60 mph). Neither are you “5 minutes” behind (you can not “catch up” by just driving 5 more minutes, because the amount of distance traveled at 55 is less than you “would” have traveled at 60 mph).
What you are is (sorry about this) 5 mph * 5 min = 25 mph-min (the product of the two) behind where you should be. You know this intuitively when you step on the gas and go 70 until you are “caught up” … but the PID algorithm does this math explicitly.
The algorithm is not really even doing an integral – it is just keeping an ongoing sum, based on the multiple of the Cycle Rate (remember that from the last post) and the “current error from setpoint” at the end of the control cycle.
Lets take an example of an oven running at a setpoint of 100 degrees (F) and with a cycle time of 2 seconds. All is fine, then at “time 0” something happens (element burns out, the wind cooling it picks up a lot, you spill your full cup of iced tea on it (that was for you southerners)) and the thing starts cooling. Two seconds later, when the cycle time has expired, a plot of what happened looks like this:
The controller is going to say “the temperature has been too low by 10 degrees for 2 seconds, so the accumulated error is 10 degree * 2 sec = 20 degree-sec. things (for some reason) continue cooling off, and in another 2 seconds the temperature is now down to 80 degrees:
The controller is going to now “say”: “I have been below setpoint by 20 degrees for two seconds (the two seconds since the last beginning of a control cycle), or 20 degrees * 2 sec = 40 degree-sec.
It takes this, and ADDS it to the previous recorded total error of 20 degree-sec, or:
20 degree-sec + 40 degree-sec = 60 degree-sec (accumulated error).
Things continue cooling off for another 2 seconds, bringing the oven now to 70 degrees:
NOW, the PID is going to say: “I have been below setpoint by 30 degrees for 2 seconds”, or 30 degrees * 2 sec = 60 degree-sec.
It takes this and adds it to the previously calculated accumulated error (60 degree-sec), or:
New accumulated error = old accumulated error + new incremental error
120 deg-sec = 60 deg-sec + 60 deg-sec
So the new accumulated error is now 120 degree-seconds. From here, the PID just goes merrily along, adding new error to the accumulated error sum as long as the temperature is below the setpoint.
So what happens when the temperature finally gets back up to the setpoint?????
Lets continue this (very hypothetical example) and assume that at the next control time (in this case the 8 second mark), the oven temperature has miraculously returned to setpoint, and the “current error” is now zero.
We need to go back to our “word equation”:
Controller output = Kp * (current difference in temperature from the setpoint)
+ (Kp/Ti) * ( the sum of ALL previous differences in temperature from the setpoint)
In this hypothetical example (with the instantaneous return to the setpoint), the “current difference” is zero when the setpoint is reached. HOWEVER, the “sum of all previous errors is “120 degree-sec”. Lets assume for now that this weird ratio of Kp/Ti equals 1.0 then in our word equation we have:
Controller output = 0
+ 1.0 * 120 degree-sec
= 120
Even though the temperature is at setpoint, the controller output is 120, which since it is greater than 100, is just effectively 100 – or “full on” for the electric element.
The oven just goes merrily on heating even though it is above setpoint.
While the oven is above setpoint, the contributions to the accumulated error are negative, but it will take some time for the accumulated error to return to zero, and until that happens, the value of the “controller output” will be greater than zero – and the heating element will continue to be “on” for some (or all ) of the control period (cycle period).
An important point to keep in mind is that this “running sum” of accumulated error starts the second the PID is turned on (or maybe, if you are lucky, when the setpoint is changed – but the manuals do not say…..). So – if you have an oven that is fully cold, and you turn it on, and it takes a long time to come up to setpoint that accumulated error term can be huge … and force the oven to just continue heating for a long time, even if the oven is well above setpoint (this I think is possibly what happened with Ken with his lead melting pot continuing to heat even when above setpoint).
Another thing that can happen is that if the oven is over setpoint for long enough, a big negative accumulated error can accumulate, which will force the controller output to be negative (i.e. “off”) even when considerably below the temperature setpoint. In this case, you can get into some really weird large up-and-down swings around the setpoint, while that accumulated error term while that accumulated error “lags behind” and forces a delay in when the heating element turns off or on.
Oh … and that weird ratio of Kp/Ti ? Well, it is just the way it is with that form (the term Ti is supposed to have some physical meaning (the time the exponential term will take to return the temperature to setpoint- hence its units are "seconds" - but it does not work that clearly in practice). But, if the manual for your controller says that the units of Ti are "seconds" - then you KNOW the controller is using this "standard form". You have a little bit of a difficult time with this form, because the values of BOTH Kp and Ti affect how much influence the integral sum has… and you can NOT turn off the integral term, because you HAVE to have Kp greater than zero (otherwise you do not have a proportional band defined), AND you can not set Ti equal to zero (because 1/zero = infinity). In the case of the Auber controller, all you can to is set the value of Ti to the largest value (1999 seconds), and hope that you have reduced the integral term to a minimum contribution.
I’m out of time again. The above was mostly words, but hopefully it made sense for the most part. Tomorrow I will try to pull out that PID emulator and give some examples of what this term is doing. I suspect that right now I am saying the term is just “bad”. Not true – under the right circumstances it can help create really, really tight control at the setpoint. But under the wrong circumstances it can create some real havoc that just looks unexplained (until the above helps you to understand what it might be doing in your circumstance…..)
I do not like this mathematical form, but because most (if not all) of the commercial PID controllers use use it, I need to introduce what is known as the “standard form” of the PID algorithm:
Because I am not for now going to talk about the derivative function, I will cut that out, and shorten this equation to the following:
Here, as before, u(t) is the instantaneous value of the output of the controller, which can be of any value, positive, or negative, but if greater than 100, just becomes “100” (because you can not turn that heater on any more than max), and if negative, becomes “0” (unless you have refrigeration handy). Kp is the same as before (the proportional constant), but now we have a new thing, “Ti” which is called the “integral time” (more about this later). Notice that because of the parenthesis, the Kp actually multiplies the integral term, so that the term in front of the integral actually is “Kp / Ti”
Going back to a “word-form” of the equation, this reads like this:
Controller output = Kp * (current difference in temperature from the setpoint)
+ (Kp/Ti) * ( the sum of ALL previous differences in temperature from the setpoint)
(again as with the other form, deviations from setpoint to lower temperatures are taken to be positive values. This starts getting really important with the integral term)
So – what is the “sum of all previous differences in temperature from the setpoint” ??
The wording is a little misleading. This really means multiplying the difference from the setpoint by the amount of time that difference was present.
It is kind of like driving a car. You have somewhere to go, and the speed limit is 60mph (yes, in this example you are driving at 60 max ). You find yourself day dreaming about that next knife you are going to design, and your speed drops to 55 mpg (5 mph below “setpoint”). And you do not notice for 5 minutes. You are behind (distance wise) from where you “should” have been. But … you are not “5 mph” behind (you can not “catch up” to where you “should be” by just going back up to 60 mph). Neither are you “5 minutes” behind (you can not “catch up” by just driving 5 more minutes, because the amount of distance traveled at 55 is less than you “would” have traveled at 60 mph).
What you are is (sorry about this) 5 mph * 5 min = 25 mph-min (the product of the two) behind where you should be. You know this intuitively when you step on the gas and go 70 until you are “caught up” … but the PID algorithm does this math explicitly.
The algorithm is not really even doing an integral – it is just keeping an ongoing sum, based on the multiple of the Cycle Rate (remember that from the last post) and the “current error from setpoint” at the end of the control cycle.
Lets take an example of an oven running at a setpoint of 100 degrees (F) and with a cycle time of 2 seconds. All is fine, then at “time 0” something happens (element burns out, the wind cooling it picks up a lot, you spill your full cup of iced tea on it (that was for you southerners)) and the thing starts cooling. Two seconds later, when the cycle time has expired, a plot of what happened looks like this:
The controller is going to say “the temperature has been too low by 10 degrees for 2 seconds, so the accumulated error is 10 degree * 2 sec = 20 degree-sec. things (for some reason) continue cooling off, and in another 2 seconds the temperature is now down to 80 degrees:
The controller is going to now “say”: “I have been below setpoint by 20 degrees for two seconds (the two seconds since the last beginning of a control cycle), or 20 degrees * 2 sec = 40 degree-sec.
It takes this, and ADDS it to the previous recorded total error of 20 degree-sec, or:
20 degree-sec + 40 degree-sec = 60 degree-sec (accumulated error).
Things continue cooling off for another 2 seconds, bringing the oven now to 70 degrees:
NOW, the PID is going to say: “I have been below setpoint by 30 degrees for 2 seconds”, or 30 degrees * 2 sec = 60 degree-sec.
It takes this and adds it to the previously calculated accumulated error (60 degree-sec), or:
New accumulated error = old accumulated error + new incremental error
120 deg-sec = 60 deg-sec + 60 deg-sec
So the new accumulated error is now 120 degree-seconds. From here, the PID just goes merrily along, adding new error to the accumulated error sum as long as the temperature is below the setpoint.
So what happens when the temperature finally gets back up to the setpoint?????
Lets continue this (very hypothetical example) and assume that at the next control time (in this case the 8 second mark), the oven temperature has miraculously returned to setpoint, and the “current error” is now zero.
We need to go back to our “word equation”:
Controller output = Kp * (current difference in temperature from the setpoint)
+ (Kp/Ti) * ( the sum of ALL previous differences in temperature from the setpoint)
In this hypothetical example (with the instantaneous return to the setpoint), the “current difference” is zero when the setpoint is reached. HOWEVER, the “sum of all previous errors is “120 degree-sec”. Lets assume for now that this weird ratio of Kp/Ti equals 1.0 then in our word equation we have:
Controller output = 0
+ 1.0 * 120 degree-sec
= 120
Even though the temperature is at setpoint, the controller output is 120, which since it is greater than 100, is just effectively 100 – or “full on” for the electric element.
The oven just goes merrily on heating even though it is above setpoint.
While the oven is above setpoint, the contributions to the accumulated error are negative, but it will take some time for the accumulated error to return to zero, and until that happens, the value of the “controller output” will be greater than zero – and the heating element will continue to be “on” for some (or all ) of the control period (cycle period).
An important point to keep in mind is that this “running sum” of accumulated error starts the second the PID is turned on (or maybe, if you are lucky, when the setpoint is changed – but the manuals do not say…..). So – if you have an oven that is fully cold, and you turn it on, and it takes a long time to come up to setpoint that accumulated error term can be huge … and force the oven to just continue heating for a long time, even if the oven is well above setpoint (this I think is possibly what happened with Ken with his lead melting pot continuing to heat even when above setpoint).
Another thing that can happen is that if the oven is over setpoint for long enough, a big negative accumulated error can accumulate, which will force the controller output to be negative (i.e. “off”) even when considerably below the temperature setpoint. In this case, you can get into some really weird large up-and-down swings around the setpoint, while that accumulated error term while that accumulated error “lags behind” and forces a delay in when the heating element turns off or on.
Oh … and that weird ratio of Kp/Ti ? Well, it is just the way it is with that form (the term Ti is supposed to have some physical meaning (the time the exponential term will take to return the temperature to setpoint- hence its units are "seconds" - but it does not work that clearly in practice). But, if the manual for your controller says that the units of Ti are "seconds" - then you KNOW the controller is using this "standard form". You have a little bit of a difficult time with this form, because the values of BOTH Kp and Ti affect how much influence the integral sum has… and you can NOT turn off the integral term, because you HAVE to have Kp greater than zero (otherwise you do not have a proportional band defined), AND you can not set Ti equal to zero (because 1/zero = infinity). In the case of the Auber controller, all you can to is set the value of Ti to the largest value (1999 seconds), and hope that you have reduced the integral term to a minimum contribution.
I’m out of time again. The above was mostly words, but hopefully it made sense for the most part. Tomorrow I will try to pull out that PID emulator and give some examples of what this term is doing. I suspect that right now I am saying the term is just “bad”. Not true – under the right circumstances it can help create really, really tight control at the setpoint. But under the wrong circumstances it can create some real havoc that just looks unexplained (until the above helps you to understand what it might be doing in your circumstance…..)
That's an idea. When I do some more casting (hopefully this weekend) I'll try some of that.
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Ok … with the information covered so far – I think it is time to play some PID Games (i.e. use that PID simulator to review/illustrate some of the behaviors that proportional and integral control can give rise to (for now still ignoring derivative control
…. So first of all, with a relatively low value of Kp (which is a really wide proportional band), the heater starts cutting down its output a long way from the setpoint. With Kd=0 (no derivative term), and with the integral term minimized (either a zero value of Ki, if you have it, or as large a value of Ti as you can set), the result is that, from a start at low temperature, the oven temperature approaches the setpoint very slowly (and as Ken pointed out – this can be too slow for patience to allow):
If you get impatient, and increase the value of Kp (ie decrease the proportional band) the heater stays on full bore heating until closer to the setpoint. This allows for faster heating:
But, because of the balance of input energy and the loss of heat through the insulation, you have an offset to a lower temperature, along with a fairly small amount of bouncing around. The good news is that this is actually a pretty stable situation to be in … for example, if you open the door and have a heat loss, you should recover fairly quickly, and not have any instabilities in control. This situation is simulated below:
However, with this situation, you might experience too slow a heating for your needs, or the offset might be larger than you want. If the offset is relatively small, and you are ok with the heating time, then just increase your setpoint to compensate for the downward offset.
You can NOT increase the value of Kp (i.e. decrease the proportional band) to compensate for the offset. If you do, then you start getting overshot and larger oscillations around the setpoint due to the mis-match between the size of the proportional band, and the time it takes the heating element to heat up or cool down as the electric current to it is changed. For example, keeping everything above the same but decreasing the proportional band (larger Kp), we get overshoot with oscillations around the setpoint:
The higher the value of Kp (the smaller the proportional band), the worse the overshoot and oscillations:
This might be bearable for you (it will be a trade off between heating time and acceptability of the oscillations). YMMV (your mileage may vary – meaning that what actually happens depends on the specifics of your system – you will need to feel it out for yourself).
Next post – introducing integral control to the mix….
…. So first of all, with a relatively low value of Kp (which is a really wide proportional band), the heater starts cutting down its output a long way from the setpoint. With Kd=0 (no derivative term), and with the integral term minimized (either a zero value of Ki, if you have it, or as large a value of Ti as you can set), the result is that, from a start at low temperature, the oven temperature approaches the setpoint very slowly (and as Ken pointed out – this can be too slow for patience to allow):
If you get impatient, and increase the value of Kp (ie decrease the proportional band) the heater stays on full bore heating until closer to the setpoint. This allows for faster heating:
But, because of the balance of input energy and the loss of heat through the insulation, you have an offset to a lower temperature, along with a fairly small amount of bouncing around. The good news is that this is actually a pretty stable situation to be in … for example, if you open the door and have a heat loss, you should recover fairly quickly, and not have any instabilities in control. This situation is simulated below:
However, with this situation, you might experience too slow a heating for your needs, or the offset might be larger than you want. If the offset is relatively small, and you are ok with the heating time, then just increase your setpoint to compensate for the downward offset.
You can NOT increase the value of Kp (i.e. decrease the proportional band) to compensate for the offset. If you do, then you start getting overshot and larger oscillations around the setpoint due to the mis-match between the size of the proportional band, and the time it takes the heating element to heat up or cool down as the electric current to it is changed. For example, keeping everything above the same but decreasing the proportional band (larger Kp), we get overshoot with oscillations around the setpoint:
The higher the value of Kp (the smaller the proportional band), the worse the overshoot and oscillations:
This might be bearable for you (it will be a trade off between heating time and acceptability of the oscillations). YMMV (your mileage may vary – meaning that what actually happens depends on the specifics of your system – you will need to feel it out for yourself).
Next post – introducing integral control to the mix….
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Now to add the influence of the integral term to this….
For this, lets go back to a situation where we had only proportional control, and Ki was just large enough (proportional band small enough) to get us fairly close to the setpoint, but with a little offset of temperature below it:
Now, the purpose of the integral term is “recognize” that you have a little bit of that offset, and to slowly add to that “running sum” of “accumulated error” so that when added to the proportional term, it just slightly nudges the controller output up a little to eliminate the offset. The tradeoff is that as long as the actual temperature is below the setpoint, the accumulated error will continue to increase until the heating element output is increased enough to bring the oven up to the setpoint. But remember, no matter what, when that point is hit, the accumulated error is still positive, and the heating element will continue to heat the oven above the setpoint (until the accumulated error is driven back down to zero by virtue of that temperature being above setpoint).
You will always get oscillations around the setpoint after that as the accumulated error varies between positive and negative values. How much and how fast you overshoot the setpoint depends on that value of the “integral time” (Ti). Large values make the influence of the integral term small (and you should be able to just nudge the temperature, whereas small values of Ti make the influence of the integral term really big, and you will have a huge overshoot before the heating element turns off, and big oscillations after that.
So …. Lets go back to the simulation just above. I will real-time just increase the value of Ki to a value of 0.01 (this is pretty small, right?) (remember, if you are dealing with Ti, this would be the same as using a large value of Ti, because it is in the bottom of the ratio in front of the actual integral (sum):
This screenshot is taken a little while after I made that change. If you look closely, you should see that the offset has been eliminated, and there is a small oscillation around the setpoint. Looks pretty good – right????
Unfortunately, strange things are lurking in the shadows…..
Remember in the discussions above when Ken started up his lead melting pot, and found that the thing got to his setpoint temperature and just kept on heating? What I am going to do now is take the simulation running above, and set the temperature to ambient (this would be the same as Ken throwing a hunk of lead into his pot and cooling it a whole bunch, or if this is an oven the same as opening the door and letting a whole bunch of heat escape:
Weird, huh? This was running just fine until you started the thing cold from the beginning, or threw a hunk of lead into your pot (none of the parameters were changed). Hopefully now, you can understand what is going on. Because the temperature started so far below the setpoint (or was reduced to that temperature), the integral term started accumulating a big value quickly. It kept that large positive value right up to the point the setpoint was reached, and then started decreasing. But that accumulated error did not become zero (and allow the heating element to turn off) until the top of the peak where the temperature started back down again – at which point the accumulated error started becoming negative. Also note that when the temperature dropped below the setpoint, the heating element did not turn back on again. This is because the accumulated error (integral, sum – whatever you want to think of it as) was still negative, producing a negative “controller ouput”. As the temperature continue to drop, the positive contribution from the “proportional term” gets bigger, until it is enough to compensate for the negative accumulated error, and the heating element turns back on again.
Eventually the thing will settle out to a flat line – but that can take a while. But – if the integral term is large enough, you will get really big oscillations around the setpoint that just keep going on…. (here the value of Ti is increased only to 0.2 versus 0.1)
Three points to make, and I will stop this particular post.
First - Remember way back at the beginning when I said that the PID system was designed to control big (slowly moving) systems in the face of relatively small individual disruptions to that system? This is a case in point of that. In the example above, things were running pretty well when the system was basically at its setpoint, and slowing losing heat to the environment – but things went totally crazy when the oven door was opened, or a hunk of lead was put into the melting pot. This is not an “error” of the PID system – it is an inherent property of the mathematics behind how they operate.
Second – that just reinforces another thing I said early on: that you will need to choose between stable operation around a set temperature versus quick recovery after a big disruption (like opening an oven door, or starting the thing up from cold). The very parameters that allow for quick recovery when they are set big enough, also produce unstable behavior, when they are big. ON the other hand, if those parameters are small enough, the behavior can be quite stable, but the time to recover from a disruption becomes longer and longer.
Third – the behavior of the system is very, very, sensitive to small changes in the parameters (look at what happened above with Ki going from 0.1 to 0.2 ……), and what creates "good" behavior under certain circumstances can produce "bad" behavior under different types of levels of disruption to the system (remember what happened with the "stable" operation above when the door was "opened" . I will talk in a post or two about the “autotune” system. It really is not that smart, and in fact emulates in kind of a blind way the process I outline above for trying to find a value of Kp. But as with everything else, those algorithms were created to set the parameters for big huge pieces of industrial plants, with the assumption that they are operating with small disruptions. If autotune works for you – that is really great. If it does not, that does not mean the PID can not work – it just means that the parameters it is trying to set are assuming that you are running a big distillation tower, and not the small oven you are actually running……
For this, lets go back to a situation where we had only proportional control, and Ki was just large enough (proportional band small enough) to get us fairly close to the setpoint, but with a little offset of temperature below it:
Now, the purpose of the integral term is “recognize” that you have a little bit of that offset, and to slowly add to that “running sum” of “accumulated error” so that when added to the proportional term, it just slightly nudges the controller output up a little to eliminate the offset. The tradeoff is that as long as the actual temperature is below the setpoint, the accumulated error will continue to increase until the heating element output is increased enough to bring the oven up to the setpoint. But remember, no matter what, when that point is hit, the accumulated error is still positive, and the heating element will continue to heat the oven above the setpoint (until the accumulated error is driven back down to zero by virtue of that temperature being above setpoint).
You will always get oscillations around the setpoint after that as the accumulated error varies between positive and negative values. How much and how fast you overshoot the setpoint depends on that value of the “integral time” (Ti). Large values make the influence of the integral term small (and you should be able to just nudge the temperature, whereas small values of Ti make the influence of the integral term really big, and you will have a huge overshoot before the heating element turns off, and big oscillations after that.
So …. Lets go back to the simulation just above. I will real-time just increase the value of Ki to a value of 0.01 (this is pretty small, right?) (remember, if you are dealing with Ti, this would be the same as using a large value of Ti, because it is in the bottom of the ratio in front of the actual integral (sum):
This screenshot is taken a little while after I made that change. If you look closely, you should see that the offset has been eliminated, and there is a small oscillation around the setpoint. Looks pretty good – right????
Unfortunately, strange things are lurking in the shadows…..
Remember in the discussions above when Ken started up his lead melting pot, and found that the thing got to his setpoint temperature and just kept on heating? What I am going to do now is take the simulation running above, and set the temperature to ambient (this would be the same as Ken throwing a hunk of lead into his pot and cooling it a whole bunch, or if this is an oven the same as opening the door and letting a whole bunch of heat escape:
Weird, huh? This was running just fine until you started the thing cold from the beginning, or threw a hunk of lead into your pot (none of the parameters were changed). Hopefully now, you can understand what is going on. Because the temperature started so far below the setpoint (or was reduced to that temperature), the integral term started accumulating a big value quickly. It kept that large positive value right up to the point the setpoint was reached, and then started decreasing. But that accumulated error did not become zero (and allow the heating element to turn off) until the top of the peak where the temperature started back down again – at which point the accumulated error started becoming negative. Also note that when the temperature dropped below the setpoint, the heating element did not turn back on again. This is because the accumulated error (integral, sum – whatever you want to think of it as) was still negative, producing a negative “controller ouput”. As the temperature continue to drop, the positive contribution from the “proportional term” gets bigger, until it is enough to compensate for the negative accumulated error, and the heating element turns back on again.
Eventually the thing will settle out to a flat line – but that can take a while. But – if the integral term is large enough, you will get really big oscillations around the setpoint that just keep going on…. (here the value of Ti is increased only to 0.2 versus 0.1)
Three points to make, and I will stop this particular post.
First - Remember way back at the beginning when I said that the PID system was designed to control big (slowly moving) systems in the face of relatively small individual disruptions to that system? This is a case in point of that. In the example above, things were running pretty well when the system was basically at its setpoint, and slowing losing heat to the environment – but things went totally crazy when the oven door was opened, or a hunk of lead was put into the melting pot. This is not an “error” of the PID system – it is an inherent property of the mathematics behind how they operate.
Second – that just reinforces another thing I said early on: that you will need to choose between stable operation around a set temperature versus quick recovery after a big disruption (like opening an oven door, or starting the thing up from cold). The very parameters that allow for quick recovery when they are set big enough, also produce unstable behavior, when they are big. ON the other hand, if those parameters are small enough, the behavior can be quite stable, but the time to recover from a disruption becomes longer and longer.
Third – the behavior of the system is very, very, sensitive to small changes in the parameters (look at what happened above with Ki going from 0.1 to 0.2 ……), and what creates "good" behavior under certain circumstances can produce "bad" behavior under different types of levels of disruption to the system (remember what happened with the "stable" operation above when the door was "opened" . I will talk in a post or two about the “autotune” system. It really is not that smart, and in fact emulates in kind of a blind way the process I outline above for trying to find a value of Kp. But as with everything else, those algorithms were created to set the parameters for big huge pieces of industrial plants, with the assumption that they are operating with small disruptions. If autotune works for you – that is really great. If it does not, that does not mean the PID can not work – it just means that the parameters it is trying to set are assuming that you are running a big distillation tower, and not the small oven you are actually running……
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Ok folks ... I am at a point again where I could use feedback as to whether anyone is reading this .... is it helpful? ..... and should I add more??? (I could still add more on the derivative function (and why generally not to use it), and also on just what these "autotune" functions are doing...... Please let me know??
- Joined
- Jul 22, 2019
- Messages
- 29
I read it and would love to see more.
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Will do ... but right now i am concentrating on making masks. My wife is a doc, and right now her friends in the clinics ate working with nothing ... trying to help (something is better than nothing...)
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
This is not knife related at all ... but given the current circumstances, I trust the moderators will forgive.
The pattern I am using is based on one originally proposed by Deaconess system, which, in response to the CDC allowing home made masks in an emergency is "acceptable". instructiions are attacheched as a pdf.
emphasizing tthat the CDC says these are aceptable in an emergency, the following apply. several studies have supplied evidence that such masks are "better than nothing" ... one published in last sept. is this one:
https://jamanetwork.com/journals/jama/fullarticle/2749214
caveats apply: n95 masks are for "up close and personal" contacts with ill people - like they cough in your face. a mask like this is not intended for a contact like this, but **might** allow some reduction in viron exposure in morew "casual" contacts. again, no guarantees presented. Bottom line... not guarantees .. but **maybe* bettern than nothing. at the very least ... the present a reminder **not* touch your face. You also need to remember that you MUST consider the outside of mask to be contaminated at all times...... raw materials, look like this:
Once sewed, they look like this:
And I must add ... my grandmothers 70-or-more year old singer sewing machine, which undoubtedly make clothes during WWII, and which I have used to make everything from shirts, to warm bathrobes, to quilts for my son, to bicycle panniers, ..... still going strong!!!!!!!
Thanks, that is a neat old sewing machine. Now I understand how to make the mask, fairly simple. I was thinking more of a N95 level mask, but as you say that is certainly better than nothing. I personally suspect it's a LOT better than nothing because it would really help prevent hands from touching mouth 'n nose area which is very important.
Just finished reading the link you gave on effectiveness of regular medical masks vs N95. I must say I'm surprised, but as the authors of the study say it's so hard to really test. Of the Influenza cases that happened, who's to say they were infected when in clinical setting and not when out shopping and not wearing mask. BUT - it does give me better feeling about the use of regular medical masks, and those I can make. Thank you again for the post and links.
Ken H>
Just finished reading the link you gave on effectiveness of regular medical masks vs N95. I must say I'm surprised, but as the authors of the study say it's so hard to really test. Of the Influenza cases that happened, who's to say they were infected when in clinical setting and not when out shopping and not wearing mask. BUT - it does give me better feeling about the use of regular medical masks, and those I can make. Thank you again for the post and links.
Ken H>
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
You are welcome. Sorry for the typos on the previous post - was typing fast while making dinner. Part of me wonders about the differences between mask testing on the benchtop (which is very idealized ) versus outcomes in real use situations... and lord knows i have seen bench tests that did not really reflect actual use conditions in the hands if a real person. I have no doubt that the n95 masks are measured to filter out 95% of particles below a certain size( .5 micron i think) ... but that is likely with a real severe challenge of particles directly in front of the mask, with a really good seal between the mask and particle collector. That is VERY different from standing 6 feet from someone who sneezes or coughs (lower particle count in vicinity of mask).
i am intrigued that this study (which echoes another earlier one..
Which reference i can not find right now) did not do the benchtop particle counting ... but actually tried to measure who got sick... which is something i trust a lot more than the raw particle counts... (but i still would not rely on the cloth ones for an upclose and personal encounter.
Like you said .. they are at least a reminder not to touch your face. For now i will take the study as some level of reassurance they offer some actual protection. Elastic is impossible to get. The handmade straps out of fabric are a PITA to make by hand, but doable for small quantities. If you have trouble, email me at rchamlen@pobox.com and i can offer some other suggestions.
a couple other thoughts: remember to cover both mouth and nose (i saw a guy at the store the other day with a perfectly good n95 mask only over his mouth (leaving his nose totally uncovered). What a waste of a precious mask. ALSO (and i think this is part of what people caution as a false sense of security about masks), remember to treat the outside of the mask (and straps) as assumed contaminated. If you touch the mask, wash your hands. When you take it off, do it without touching the outside to your face. If you put it back on, same thing. Wash it at end of day after using.
this thing you see of people taking a mask and pulling it down around their throat (with the outside of the mask touching their chin or mouth) is just plain ... stupid)
be safe .. again email me if you need more input.
(Moderators ... again please forgive the shift in topic given the circumstances)
i am intrigued that this study (which echoes another earlier one..
Which reference i can not find right now) did not do the benchtop particle counting ... but actually tried to measure who got sick... which is something i trust a lot more than the raw particle counts... (but i still would not rely on the cloth ones for an upclose and personal encounter.
Like you said .. they are at least a reminder not to touch your face. For now i will take the study as some level of reassurance they offer some actual protection. Elastic is impossible to get. The handmade straps out of fabric are a PITA to make by hand, but doable for small quantities. If you have trouble, email me at rchamlen@pobox.com and i can offer some other suggestions.
a couple other thoughts: remember to cover both mouth and nose (i saw a guy at the store the other day with a perfectly good n95 mask only over his mouth (leaving his nose totally uncovered). What a waste of a precious mask. ALSO (and i think this is part of what people caution as a false sense of security about masks), remember to treat the outside of the mask (and straps) as assumed contaminated. If you touch the mask, wash your hands. When you take it off, do it without touching the outside to your face. If you put it back on, same thing. Wash it at end of day after using.
this thing you see of people taking a mask and pulling it down around their throat (with the outside of the mask touching their chin or mouth) is just plain ... stupid)
be safe .. again email me if you need more input.
(Moderators ... again please forgive the shift in topic given the circumstances)
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Oh.. one other thing: i also originally thought in terms of an n95 level mask ... but you need the right material (which is not available). Or a hepa filter (which is equivalent to n99 i think) ... but that material is not washable ... so essentially single use ... and to really get the top level of protection, the thing needs to be airtight on your skin.. which is HARD to do, and uncomfortable. If you believe that study, the cloth masks are reusable by washing, and at least offer some level of protection.
(One other thing on the “science” side: what your outcome is (if infected) can depend ALOT on the amount of the original exposure (technically called the innoculum). A really large original hit can allow the virus to replicate to large numbers before the immune system can mount an antibody defense - which is why Mardi Gras was a Really BAD IDEA. A small original hit gives the immune system a “taste” of the virus, and the ability to generate sufficient antibodies to more or less stay ahead of the virus as it tries to replicate. Anything that reduces the size of that original hit of virus tilts the odds in your favor.
hence the mask: in my eye they are not to absolutely stop the virus (though that would be nice) but to reduce the size of the original hit)
(frankly, i would much rather have the virus with a reasonable course of illness than live in fear/worry of getting it...). At least that way i could get out there and help rather than sitting at home...
(One other thing on the “science” side: what your outcome is (if infected) can depend ALOT on the amount of the original exposure (technically called the innoculum). A really large original hit can allow the virus to replicate to large numbers before the immune system can mount an antibody defense - which is why Mardi Gras was a Really BAD IDEA. A small original hit gives the immune system a “taste” of the virus, and the ability to generate sufficient antibodies to more or less stay ahead of the virus as it tries to replicate. Anything that reduces the size of that original hit of virus tilts the odds in your favor.
hence the mask: in my eye they are not to absolutely stop the virus (though that would be nice) but to reduce the size of the original hit)
(frankly, i would much rather have the virus with a reasonable course of illness than live in fear/worry of getting it...). At least that way i could get out there and help rather than sitting at home...
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Ken - another recent article citing studies, and making several points about misplaced "preconceptions" around masks..... worth a read at least (washington post - hopefully you will be able to read...)
https://www.washingtonpost.com/outlook/2020/03/28/masks-all-coronavirus/
https://www.washingtonpost.com/outlook/2020/03/28/masks-all-coronavirus/
That's a VERY good article and confirms what I've felt from the start. Any mask is better than nothing, anywhere, anytime. It only makes sense. I think perhaps I will start being a bit more conscientious on wearing a mask when out shopping. The last sentence in the article sums it up nicely: "Given the weight of evidence, it seems likely that universal mask wearing should be a part of the solution"
Thanks.
Thanks.
Last edited:
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Ok - I spent sunday tuning up/servicing that old sewing machine (I think it has not been lubricated/cleaned in 40 years :-( ), and it is humming along nicely. Also, am waiting for some mask-sewing supplies to arrive before I can chunk them out in quantity, so I thought I would....
TALK A LITTLE BIT ABOUT PID "TUNING" ALGORITHMS
I am only going to speak fairly generally about this - but spend time trying to point out why they are just not clearly applicable for the knifemakers needs. for those that want more specifics, the wikipedia article on PID controllers goes into the specifics and the math.
there are a number of tuning algorithms out there - and for all I know the individual controllers that we buy have their own "proprietary" algorithms - but we would not have visibility to them. However, my guess, knowing that organizations like those that make commercial PID controllers, prefer to just implement known, commonly accepted algorithms, rather than invest the extensive time and $$$ needed to create and test some new proprietary algorithm. So I think it is a good guess that controllers like the Inkbird and Auber just use one of the commonly known algorithms.
The original, and still widely used, tuning algorithm is known as the Jiegler-Nichols method. The main point I would like you to understand is that the Ziegler-Nichols method is based on exactly the same manual approach we discussed above. The integral and derivative terms are turned "off" (as much as possible), and the value of Kp (the proportional term) is increased until the oven sees overshoot followed by some oscillation. BUT, there are several ways the algorithm can fail:
first, the programmed-in process of "increasing the value of Kp" will follow some sort of pre-defined, mindless, sequence for sequentially increasing the value of Kp (this "mindless" approach is the very definition of an "algorithm"). It might double the value of Kd each time, it might increase it each time by 10%, or 20%, or 30%, etc. you do not know. It just goes ahead with those mindless increases until that overshoot is seen. A result of this is that if a big jump in Kd is taken, and an overshoot is seen, then the value of Kp taken to produce that overshoot might be much higher than the value of Kp actually needed. A good algorithm might do something like increase 30% until overshoot is seen, then back off to the previous value of Kp, then increase 20%, and if overshoot is still seen, then increase by 10% and see if overshoot is still seen, and so on until a close estimate of the value of Kp that gives that overshoot is determined.
The point is that you do not know what algorithm is being used, and you can not change or control it so you do not really know how well that critical value of Kp has been calculated. (though just on reading the care seen in the manuals, I would likely trust the Auber more than the Inkbird). There is no more "learning" or "intelligence" to the process than that - just a mindlessly followed recipe.
The second thing about the Ziegler-Nichols tuning method (and also the other ones), is that once that critical value of Kp is determined, ALL of the other parameters (Ki and Kd, as well as Kp) are automatically set using a very simple recipe, based only on ratios based on that critical value of Kp. But those "good" values of Kp, Ki, and Kd are based on experience with keeping tight control on big, huge, industrial equipment (like that distillation tower), and experience relatively minor and slow-occurring disturbances (i.e. they do not experience things like opening up the oven door, or putting in a big, cold, piece of metal).
the way the values of Kp, Ki, and Kd just is not applicable to the small, highly disrupted, things we are controlling (like small ovens and forges).
There is a special problem with the derivative term (which I will try to talk about next). In words for now (I will try to use diagrams to explain in the next post), the derivative term is commonly described as trying to "predict" the future impact of a small disturbance, and apply a correction now in order to eliminate that "future" impact. A couple impacts of this term you need to be aware of: remember, the autotuning algorithms just mindlessly set the value of this term based on experience with large, slowly changing, industrial equipment ... and so the impact of this term on small equipment like an oven with things like doors opening, wind blowing on it, of a forge being moved outside into the wind, can produce much, much too large a "correction" (causing wild instability). The other thing is that you all use "autotune" with the oven door tightly closed, and the parameters will be so set to maintain that condition. .... but that is VERY different from the the real case you want to control - stable recovery of temperature from an open door or a cold piece of metal put into the oven.
remember the example with the PID controller I gave above, where things were very stable until I "opened the door" and let the thing cool off? (bad oscillations in temperature were the result). that is a case in point of what can happen if you use autotune on a stable closed oven, and then start using it and doing things like heating it up from a dead cold state, or opening the door when it is stable and hot, or putting a cold piece of steel in it and cooling it off a lot from its stable temperature.
If autotune works for you - great. But it it does not, just remember that it it basically a mindless process ... and that you CAN make the system work using a manual approach based mostly on the proportional term, and maybe a little on the integral term (but keeping in mind that carries more risk of instability.....)
No pictures on this one .... hopefully the words alone make sense.....
TALK A LITTLE BIT ABOUT PID "TUNING" ALGORITHMS
I am only going to speak fairly generally about this - but spend time trying to point out why they are just not clearly applicable for the knifemakers needs. for those that want more specifics, the wikipedia article on PID controllers goes into the specifics and the math.
there are a number of tuning algorithms out there - and for all I know the individual controllers that we buy have their own "proprietary" algorithms - but we would not have visibility to them. However, my guess, knowing that organizations like those that make commercial PID controllers, prefer to just implement known, commonly accepted algorithms, rather than invest the extensive time and $$$ needed to create and test some new proprietary algorithm. So I think it is a good guess that controllers like the Inkbird and Auber just use one of the commonly known algorithms.
The original, and still widely used, tuning algorithm is known as the Jiegler-Nichols method. The main point I would like you to understand is that the Ziegler-Nichols method is based on exactly the same manual approach we discussed above. The integral and derivative terms are turned "off" (as much as possible), and the value of Kp (the proportional term) is increased until the oven sees overshoot followed by some oscillation. BUT, there are several ways the algorithm can fail:
first, the programmed-in process of "increasing the value of Kp" will follow some sort of pre-defined, mindless, sequence for sequentially increasing the value of Kp (this "mindless" approach is the very definition of an "algorithm"). It might double the value of Kd each time, it might increase it each time by 10%, or 20%, or 30%, etc. you do not know. It just goes ahead with those mindless increases until that overshoot is seen. A result of this is that if a big jump in Kd is taken, and an overshoot is seen, then the value of Kp taken to produce that overshoot might be much higher than the value of Kp actually needed. A good algorithm might do something like increase 30% until overshoot is seen, then back off to the previous value of Kp, then increase 20%, and if overshoot is still seen, then increase by 10% and see if overshoot is still seen, and so on until a close estimate of the value of Kp that gives that overshoot is determined.
The point is that you do not know what algorithm is being used, and you can not change or control it so you do not really know how well that critical value of Kp has been calculated. (though just on reading the care seen in the manuals, I would likely trust the Auber more than the Inkbird). There is no more "learning" or "intelligence" to the process than that - just a mindlessly followed recipe.
The second thing about the Ziegler-Nichols tuning method (and also the other ones), is that once that critical value of Kp is determined, ALL of the other parameters (Ki and Kd, as well as Kp) are automatically set using a very simple recipe, based only on ratios based on that critical value of Kp. But those "good" values of Kp, Ki, and Kd are based on experience with keeping tight control on big, huge, industrial equipment (like that distillation tower), and experience relatively minor and slow-occurring disturbances (i.e. they do not experience things like opening up the oven door, or putting in a big, cold, piece of metal).
the way the values of Kp, Ki, and Kd just is not applicable to the small, highly disrupted, things we are controlling (like small ovens and forges).
There is a special problem with the derivative term (which I will try to talk about next). In words for now (I will try to use diagrams to explain in the next post), the derivative term is commonly described as trying to "predict" the future impact of a small disturbance, and apply a correction now in order to eliminate that "future" impact. A couple impacts of this term you need to be aware of: remember, the autotuning algorithms just mindlessly set the value of this term based on experience with large, slowly changing, industrial equipment ... and so the impact of this term on small equipment like an oven with things like doors opening, wind blowing on it, of a forge being moved outside into the wind, can produce much, much too large a "correction" (causing wild instability). The other thing is that you all use "autotune" with the oven door tightly closed, and the parameters will be so set to maintain that condition. .... but that is VERY different from the the real case you want to control - stable recovery of temperature from an open door or a cold piece of metal put into the oven.
remember the example with the PID controller I gave above, where things were very stable until I "opened the door" and let the thing cool off? (bad oscillations in temperature were the result). that is a case in point of what can happen if you use autotune on a stable closed oven, and then start using it and doing things like heating it up from a dead cold state, or opening the door when it is stable and hot, or putting a cold piece of steel in it and cooling it off a lot from its stable temperature.
If autotune works for you - great. But it it does not, just remember that it it basically a mindless process ... and that you CAN make the system work using a manual approach based mostly on the proportional term, and maybe a little on the integral term (but keeping in mind that carries more risk of instability.....)
No pictures on this one .... hopefully the words alone make sense.....
Cushing H.
Gold Member
- Joined
- Jun 3, 2019
- Messages
- 2,714
Differential Control:
Ok, lets see if I can help make some sense of the differential aspect of PID controllers.
If we go back to the “word” form of the full PID equation, we have:
Controller output = Kp * (current difference in temperature from the setpoint)
+ Ki * ( the sum of ALL previous differences in temperature from the setpoint)
+ Kd * (the current instantaneous change in temperature from the setpoint)
This wording of “instantaneous change in temperature from the setpoint” I fear might be a little misleading …. Because it has NOTHING to do with what “side” of the setpoint you are on …. It is only meant to relate back to the issue that temperatures below the setpoint are considered positive deviations from the setpoint ….. so that the “slope” or “rate of change” of the temperature used in the equation is actually opposite of what you might otherwise consider (so that a temperature getting lower over time is actually treated as a positive value of instantaneous change.
This will make much more sense with a picture. Consider a situation we saw before when talking about integral control. The temperature of your oven for some reason drops by 30 degrees over 6 seconds:
The instantaneous change in temperature is thus 30 degrees/6 seconds = 5 degrees per second. So … going back to the “word” form of the equation, and putting this in, we then have:
Controller output = Kp * (current difference in temperature from the setpoint)
+ Ki * ( the sum of ALL previous differences in temperature from the setpoint)
+ Kd * 5 degrees/second
Hopefully, you can see that for a given value of Kp and Ki, this will have the effect of instantly increasing the controller output by Ki * 5 (degrees/second). This makes a lot of sense for a little short lived change from the setpoint …. As if there is a small decrease in temperature, a quick nudge upwards in the controller output will compensate for that and bring you back to the temperature you want.
Visually, lets go back to that PID emulation software, and this is what this looks like. The emulator was run with a relatively small value of Kp (which by itself would produce a rather big downward offset from the setpoint), combined with a value of Ki which is enough to decrease that offset to something really small (but this took a LONG time to settle down and stop large oscillations).
This thing sitting pretty close to the setpoint (green line), but IS bouncing up and down somewhat (the black line). The IDEA is that if the temperature is going DOWN, the output of the controller is nudged upwards to avoid the temperature dropping too much below below the setpoint …. And in a situation like this …. This does help a lot: the below image is of the exact same settings as shown above, but the derivative value, Kd has been set to a value of 10:
So …. This “looks” really good … small bounces only slightly above and below the setpoint.
BUT …. Here is t he problem. The derivative term does not care at all whether the temperature is above or below the setpoint. So …. If the temperature is above the setpoint, but the temperature is decreasing towards the setpoint …. The derivative term will cause the heater output to increase …. Thus drastically slowing down the approach of the temperature to the setpoint. Likewise …. If the temperature is below the setpoint, but increasing (like when the oven is just turned on, or when it is heating up after opening the door), then the derivative term is negative, and will decrease the output of the heater … slowing down how fast the oven returns to the setpoint. Basically, when the changes are big (like opening the door) what the derivative term does is “stretch out” in time how fast things change. Ultimately they may settle down, but when you are on one side of the setpoint for a long time …. Then (as we saw before) you can run into real problems with the integral term.
Again …. Looking at this visually will make more sense …. And it can be made much more obvious by using a large value of Kd. So …. Lets do what we did in the in the plots before, and simulate “opening the door” by dumping 20% of the temperature in the oven. With no derivative term (Kd=0), this is what that looks like:
(remember, the overshoot occurs because of the accumulated value of the integral term….)
With the derivative term now turned on (and set to 1000 to make the result more obvious), you now have this:
The recovery towards the setpoint gets “stretched out” …. And if you look closely, you can see that because of the added time spent below the setpoint, the integral term gets MUCH bigger …. So the overshoot is bigger, and you have big, long time frame, oscillations around the setpoint for a long time (much too big to show here….).
This problem is made much worse when you are starting the oven up from "cold": the derivative term slows down how fast the oven heats, which causes the integral term to get really big, which causes more overshoot (and oscillations) than would occur otherwise, etc.
I show that to try to -re-emphasize the point that the “autotune” process will just blindly go ahead and set the value of Kd using an algorithm that was defined for slowly moving, small change processes (like that distillation tower), and NOT for stuff like a forge or heat treat oven (where big changes can occur in small times).
While the autotune process might give you an acceptable result, you will likely get better behavior using manual tuning without the derivative term …. And if autotune fails you, you can still likely get a good resulting behavior by manually setting the parameters, and setting Kd (the derivative term) to zero.
Ok, lets see if I can help make some sense of the differential aspect of PID controllers.
If we go back to the “word” form of the full PID equation, we have:
Controller output = Kp * (current difference in temperature from the setpoint)
+ Ki * ( the sum of ALL previous differences in temperature from the setpoint)
+ Kd * (the current instantaneous change in temperature from the setpoint)
This wording of “instantaneous change in temperature from the setpoint” I fear might be a little misleading …. Because it has NOTHING to do with what “side” of the setpoint you are on …. It is only meant to relate back to the issue that temperatures below the setpoint are considered positive deviations from the setpoint ….. so that the “slope” or “rate of change” of the temperature used in the equation is actually opposite of what you might otherwise consider (so that a temperature getting lower over time is actually treated as a positive value of instantaneous change.
This will make much more sense with a picture. Consider a situation we saw before when talking about integral control. The temperature of your oven for some reason drops by 30 degrees over 6 seconds:
The instantaneous change in temperature is thus 30 degrees/6 seconds = 5 degrees per second. So … going back to the “word” form of the equation, and putting this in, we then have:
Controller output = Kp * (current difference in temperature from the setpoint)
+ Ki * ( the sum of ALL previous differences in temperature from the setpoint)
+ Kd * 5 degrees/second
Hopefully, you can see that for a given value of Kp and Ki, this will have the effect of instantly increasing the controller output by Ki * 5 (degrees/second). This makes a lot of sense for a little short lived change from the setpoint …. As if there is a small decrease in temperature, a quick nudge upwards in the controller output will compensate for that and bring you back to the temperature you want.
Visually, lets go back to that PID emulation software, and this is what this looks like. The emulator was run with a relatively small value of Kp (which by itself would produce a rather big downward offset from the setpoint), combined with a value of Ki which is enough to decrease that offset to something really small (but this took a LONG time to settle down and stop large oscillations).
This thing sitting pretty close to the setpoint (green line), but IS bouncing up and down somewhat (the black line). The IDEA is that if the temperature is going DOWN, the output of the controller is nudged upwards to avoid the temperature dropping too much below below the setpoint …. And in a situation like this …. This does help a lot: the below image is of the exact same settings as shown above, but the derivative value, Kd has been set to a value of 10:
So …. This “looks” really good … small bounces only slightly above and below the setpoint.
BUT …. Here is t he problem. The derivative term does not care at all whether the temperature is above or below the setpoint. So …. If the temperature is above the setpoint, but the temperature is decreasing towards the setpoint …. The derivative term will cause the heater output to increase …. Thus drastically slowing down the approach of the temperature to the setpoint. Likewise …. If the temperature is below the setpoint, but increasing (like when the oven is just turned on, or when it is heating up after opening the door), then the derivative term is negative, and will decrease the output of the heater … slowing down how fast the oven returns to the setpoint. Basically, when the changes are big (like opening the door) what the derivative term does is “stretch out” in time how fast things change. Ultimately they may settle down, but when you are on one side of the setpoint for a long time …. Then (as we saw before) you can run into real problems with the integral term.
Again …. Looking at this visually will make more sense …. And it can be made much more obvious by using a large value of Kd. So …. Lets do what we did in the in the plots before, and simulate “opening the door” by dumping 20% of the temperature in the oven. With no derivative term (Kd=0), this is what that looks like:
(remember, the overshoot occurs because of the accumulated value of the integral term….)
With the derivative term now turned on (and set to 1000 to make the result more obvious), you now have this:
The recovery towards the setpoint gets “stretched out” …. And if you look closely, you can see that because of the added time spent below the setpoint, the integral term gets MUCH bigger …. So the overshoot is bigger, and you have big, long time frame, oscillations around the setpoint for a long time (much too big to show here….).
This problem is made much worse when you are starting the oven up from "cold": the derivative term slows down how fast the oven heats, which causes the integral term to get really big, which causes more overshoot (and oscillations) than would occur otherwise, etc.
I show that to try to -re-emphasize the point that the “autotune” process will just blindly go ahead and set the value of Kd using an algorithm that was defined for slowly moving, small change processes (like that distillation tower), and NOT for stuff like a forge or heat treat oven (where big changes can occur in small times).
While the autotune process might give you an acceptable result, you will likely get better behavior using manual tuning without the derivative term …. And if autotune fails you, you can still likely get a good resulting behavior by manually setting the parameters, and setting Kd (the derivative term) to zero.
weo
Basic Member
- Joined
- Sep 21, 2014
- Messages
- 3,013
Hello all. I was waiting for the end of the instructional before asking any questions about my specific set-up so as not to confuse the basics and get off topic too much.
Hopefully we're there....
You mentioned:
Also, forging involves repeated large variations in the environment by taking out hot pieces of steel and putting in cold pieces. If we were to look at this theoretically, the most efficient use of fuel would be to remove the piece immediately on reaching the proper temp (not counting any soak time needed for HT here, just forging) and working the steel to it's lowest forging temp and returning the cold piece to the forge environment. So the way I look at it, the most efficient use of the fuel gives the least stable environment. How should we tweak our settings and/or expectations to best deal with this reality of forging?
Hopefully we're there....
Because the nature of forging violates almost every condition above, how would you suggest we tweak both ones expectations and operation of these units?
You mentioned:
and I think this is a problem when first lighting up the forge and waiting for it to get from ambient temperature to forging temps of ~ 2000F. I contacted Auberins and they said that turning off the controller for a second or two once the target temp is reached will re-set the time point to zero and 'erase' the Ki * from the initial heating. Is this something I/we should get in the habit of doing?
Also, forging involves repeated large variations in the environment by taking out hot pieces of steel and putting in cold pieces. If we were to look at this theoretically, the most efficient use of fuel would be to remove the piece immediately on reaching the proper temp (not counting any soak time needed for HT here, just forging) and working the steel to it's lowest forging temp and returning the cold piece to the forge environment. So the way I look at it, the most efficient use of the fuel gives the least stable environment. How should we tweak our settings and/or expectations to best deal with this reality of forging?