how often should I trigger the PID?
1 Attachment(s)
One of the most commonly asked questions when setting up PID control is: “How often do I need to update the loop?” The purpose of this post is to offer some basic answers to that question. The controller being used in the following experiments is an AllenBradley PLC5/20  but the topic may be applied to most (if not all) controllers where the PID’s update time is selectable. The system being controlled is a lab simulator  modeled on a small simple air flow system. The simulator computes a new value every 0.50 seconds. The Xaxis of the graphs below is 66 seconds.
Graph #1 in the figure below illustrates a simple field test which technicians commonly perform in order to determine the “natural period” of the system. The Integral and Derivative actions are disabled  a reasonable setpoint is entered (in our case the setpoint is 40% of full flow)  and the system is then placed in automatic mode. Next the Proportional Gain setting (Kc) is increased in steps a little at a time until the system begins to oscillate in a continuous and relatively uniform manner. (I wanted to discuss “bumping” the system here but ran out of posting room. Please post questions if you’re interested.) Caution: Some systems will NOT tolerate this type of field test. Depending upon the characteristics and the design of the system, any oscillations may damage the system itself  or cause unsafe conditions for people nearby. As shown in graph #1 below, our test system went into a condition of uniform oscillation at the indicated setting of Kc = 6.25. Careful measurements indicate that this particular system oscillates at a natural period of 15.18 seconds. [attachment] For the purposes of this post, I next set the PID for a loop update time of 0.50 seconds and then manually tuned the system for “acceptable” PID control. The values which I arrived at are: Kc = 3.75; Ti = 0.13; and Td = 0.03. You may see the results of this tuning procedure by skipping ahead to graph #5  which we will regard as a properly tuned “benchmark” for the purposes of this discussion. Once I had determined the “acceptable” tuning values for Kc, Ti, and Td which I have just quoted  I entered these into the controller AND DID NOT ALTER THEM in any way as the rest of the tests proceeded. Specifically, after the “find the period experiment” had been accomplished in graph #1  the values for Kc, Ti, and Td were set and then subsequently left unchanged. Thus the only parameters which were changed throughout the rest of this series of tests were: (1) the value of the controller’s “Loop Update Time”  and (2) the value of the “trigger” timer’s Preset. In each test, these two values were kept equal to each other  a highly recommended practice. Question: Will we be able to obtain adequate control of the system if we update the PID only 5 times within each period of oscillation? Calculating: 15.18 seconds per period divided by 5 updates per period equals 3.04 seconds per update. I set both the PID’s Loop Update Time  and the preset of the trigger timer  to obtain an update period of 3.04 seconds. I started with a setpoint of 20%  and then made a step change to 40%  and graphed the results as shown in graph #2. Answer: Stated as politely as possible, the control for this particular system was judged to be “inadequate” when the PID was updated only 5 times within each period of oscillation. Question: Will we be able to obtain adequate control if we update the PID 10 times within each period of oscillation? Calculating: 15.18 seconds per period divided by 10 updates per period equals 1.52 seconds per update. I set both the PID’s Loop Update Time  and the preset of the trigger timer  to obtain an update period of 1.52 seconds. I started with a setpoint of 20%  and then made a step change to 40%  and graphed the results as shown in graph #3. Answer: The control for this particular system was judged to be “inadequate” when the PID was updated 10 times within each period of oscillation. But it’s getting noticeably better. Question: Will we be able to obtain adequate control if we update the PID 20 times within each period of oscillation? Calculating: 15.18 seconds per period divided by 20 updates per period equals 0.76 seconds per update. I set both the PID’s Loop Update Time  and the preset of the trigger timer  to obtain an update period of 0.76 seconds. I started with a setpoint of 20%  and then made a step change to 40%  and graphed the results as shown in graph #4. Answer: The control for this particular system was judged to be “adequate” when the PID was updated 20 times within each period of oscillation. Question: Consider the “adequate” control resulting from 20 updates per period. Will we obtain “improved” control if we update the PID 30 times within each period of oscillation? Calculating: 15.18 seconds per period divided by 30 updates per period equals 0.51 seconds per update. (This is very close to being a “nice round number” so I went ahead with 0.50 seconds for the next test.) I set both the PID’s Loop Update Time  and the preset of the trigger timer  to obtain an update period of 0.50 seconds. I started with a setpoint of 20%  and then made a step change to 40%  and graphed the results as shown in graph #5. Answer: The control for this particular system was judged to remain “adequate” when the PID was updated 30 times within each period of oscillation. Further, the control was judged to be “not substantially improved” over the quality of control which was available with 20 updates per period. Question: What if we radically increased the number of updates to be performed during each period? Will we obtain “improved” control if we update the PID at a significantly increased rate? (In other words, if “fast” is good  is “faster” better?) Calculating: 15.18 seconds per period divided by 0.10 seconds per update equals 152 updates per period. I set both the PID’s Loop Update Time  and the preset of the trigger timer  to obtain an update period of 0.10 seconds. I started with a setpoint of 20%  and then made a step change to 40%  and graphed the results as shown in graph #6. Answer: The control for this particular system was judged to be “unimproved” when the PID was updated 152 times within each period of oscillation. Summing up: This series of tests proves (at least to my personal satisfaction  and for this particular system) that adequate PID control may be obtained when the control loop is updated a minimum of twenty times within each period of oscillation. Further, the quality of control will not be substantially increased even if the number of updates is increased dramatically over the value required for “adequate” control. Now  in plain simple terms. Once you know how fast the system oscillates, you should crank in a number for your loop update time which will give you at least 20 to 30 PID updates during each one of those oscillation cycles. The objective is to have the PID “look at the incoming signal” OFTEN ENOUGH  and then have the PID “calculate a new output signal” OFTEN ENOUGH  so as to nudge the process back toward the target  OFTEN ENOUGH to give good control. Common sense would tell us that if the PID allows the signal to “drift around” too long without even looking at it  that it’s going to be extremely difficult (if not impossible) to get good control. Going further. The system in these tests was an air flow process which oscillated at a natural period of about 15 seconds per cycle. Suppose that we had a much slower system instead  for example: a heating process with a natural period of 132 seconds per period. Calculating: 132 seconds per period divided by 20 updates per period equals 6.60 seconds per update. So could we get adequate PID control using a Loop Update Time setting of approximately 6.60 seconds? Answer: Yes, we certainly can. But still  personally  unless there were some compelling reason for running the loop that slowly, I’d still go ahead and set my PID to update at something like every half second. The reason? The human factor. Regardless of how well the system controls the process, operators tend to think that it’s “hung up” or “sluggish” if it doesn’t move often enough. On another tack. Why not just execute the PID very often? After all, who cares if it executes a lot more often than it “really needs to” anyway? Take a quick look at the “Instruction Timing and Memory Requirements” charts in the back of: the Instruction Set Reference Manual. http://www.ab.com/manuals/cp/17856_1.pdf Adobe Reader page 312 of 372 is a good one to start with. Notice that the PID is a real “HOG” when it comes to scan time  and depending upon your specific type of PLC5 processor, 895 microseconds is a typical value for required execution time. Compare that to something like a simple MUL (Multiply) instruction at 9.9 microseconds. So the issue is  do we really want to fire this hog off a lot more often than we need to? And remember what we saw in the last graph above. When we executed the PID many times more often than was “required”  we didn’t really gain any noticeable improvement in the quality of control. Stone left unturned department: How often are the input and output signals being transferred between the field devices and the PID? In some systems the bottleneck in the control strategy is this issue  which unfortunately we don’t have room to discuss here. 
This is what I have been saying.
I thought I previously posted that any thing less than ten samples per period will not be enough and anything more than a 100 times per period is over kill unless there is a real need. Ron has definately shown that 10X is marginal and less is not fast enough.
The simulator should update more often than .5 seconds. Try again with a .05 second update. After 20 scans per second your simulation is the limiting factor. To make it short. Your 20 and 30 PID updates/period examples are limited by the simulation and do not show the real improvement. I have my simulations update 10 to 100 times faster than the PID update rate. PIDs do not have to take up a lot of time. 3 multiplies and adds with some limiting and you are done. The PLC is probably filtering data but this too can be merged with the PID's three multiply and adds. In your examples you found the natural frequency is .0659 HZ or .414 rad/sec. Now if you can compute the damping factor, you can model a second order system in the form: Gain  ? WHAT DOES ONE WITH THAT? s^2+2*d*s+w^2 Where d is the damping factor, s is the Laplace operator and w is the natural frequency in radians/second. Hint, look at the overshoot! Now what happens if the SP moves at with frequency components faster than the natural frequency of the system? Or slow must the ramp be to not have the system oscillate? 
Re: how often should I trigger the PID?
1 Attachment(s)
Quote:
[attachment] The PLC doesn't reaaly "know" the value of dt in the above equations. It doesn't measure the elapsed time, it just takes the value that you enter in the Loop Update Time setting for the dt , and calcuates everything from there. So by making a threefold increase in dt without changing T_{i} and T_{d}, you've effectively detuned the loop. Try the experiment again, but this time, when you go from dt = 0.5 to = 1.5 sec (a threefold increase), change T_{i} from 0.31 to 0.93 (a threefold increase), and T_{d} from 0.03 to 0.09. This should keep the relative contribution from each of the components the same. I'm interested in seeing the results. 
Peter and Allen,
Thanks for the feedback. I’ve been tinkering around with this PID stuff on my own for years. It’s nice to finally have someone to offer some constructive criticism on what I’ve been able to come up with. Allen, you said: Quote:
Basic idea: Consider the “time related settings” of: (1) the PID’s internal Loop Update Time setting  and (2) the external event which “triggers” the PID’s execution. As long as these two parameters are rigorously kept in sync  then we can slide our “howoftenwillwedothePID?” schedule up and down the scale  all the way from “way too often” to “not nearly often enough”  WITHOUT detuning the PID. Just DON’T forget to change BOTH settings  they have to stay MATCHED. Now that’s my take on it  and ALL of my experiments (and you have NO idea how many, my friends) seem to confirm my opinion. Suggestion: Plug some reasonable values into the printed PID equation  and then solve it for a few iterations. Then decrease the Loop Update Time to half its original setting. Now go back and solve the equation again. Sure  you’ll get smaller (baby step) contributions from the Integral component  BUT (and here’s the trick) realize that the PLC will be doing HIS iterations TWICE AS OFTEN as before  so the net effect will be ZERO change in the Integral’s contribution  OVER THE SAME PERIOD OF ELAPSED TIME. That requirement for TWICE AS MANY “baby step” iterations within the same period of time is critical. So how does the PLC know HOW MANY iterations to perform within a given amount of time? The PLC relies on the external “trigger” event (usually a timer done bit) to keep track of that “gonow; gonow; gonow” signal for the PID. And THAT  dear readers  is why I keep harpingharpingharping on maintaining that all important relationship between the PID’s internal “Loop Update Time” setting and the scheduling of the external “trigger” event. If those two settings are not kept in sync, then heaven help you  I can’t. I am constantly (choose one: amazed, entertained, amused) by individuals who will take one quick look at a PID and say: “Oh, you’ve got your (choose one: Integral, Derivative) setting (choose one: too high, too low).” The truth is, until you’ve confirmed that the timing issues (Loop Update Time setting and external trigger event) are correct, then the Integral and Derivative settings that you see have little or no actual meaning. It’s basically like checking a voltage reading  using a meter which is completely out of calibration. Now on to Peter’s observations. Quote:
Quote:
Finally, you’re WAY over my head with that fancy math stuff, Peter. Useless trivia department: Try this, folks. The next time you’re getting your teeth cleaned, ask the hygienist for the technical name for that crud she’s scraping off your teeth. It’s CALCULUS. Now  I ask you  how deeply involved do I want to get with a branch of mathematics which is named after tooth scum? Now I honestly admire people like Peter who can “integrate” and “derivate” and who really understand all of those squiggly mathematical lines. As far as I’m concerned, calculus is a lot like voodoo  it only works if the victim believes in it  and personally I don’t really BELIEVE. If the truth be known  adding, subtracting, multiplying, and dividing is about all of the “ciphering” that I can handle. And lucky for me  that’s really all that the PLC can do too  and so we usually get along just fine together. So once again  thanks, Peter and Allen, for your observations  I truly appreciate them. Please  keep them coming. 
Quote:
Quote:
The .5 second simulator update was not good for the previous example where the period was 15.18 seconds. Divide this by 20 at you get .76 seconds for the PID update. Divide that time by 10 and you get .076 seconds for the simulator update. This means the simulator must run about 200 times faster than the system period. I too have learned a lot by making system simulators and tuning them. This is good stuff. I didn't know that that keeping the real and specified sample times the same on a PLC5 is a big problem. I agree that getting the update time right is a first or second priority along with calibration. This should have been made more user proof. 
Thrown for a loop
Ron. Thanks for this. It's cleared up some more concepts/misconceptions. I think I almost get it now. (qualified statement.
The PLC cannot, of course, perform calculus. What it does is approximate, just like the rest of us. When we are totalizing a flow through a flow meter, we are integrating the flow rate over time. Do we use calculus (Integral of Fdt from zero to End)? No  we just do a time sampling of the current flow (F), multiply that to the length of time (dt), and add that to the previous result. When we scale a linear temperature reading based on the scale of the raw input, do we use calculus (^{dT}/_{dr})? NO, we just use the calculate the differnce between the values relative to full scale (or an SCP, which does the math for you). In short, in those equations that I posted above, the integral sign gets changed to a sigma, representing summation of all the previous terms. The derivate 'd' gets changed to a delta, the differnce between the current value and the last recorded value. So the fancy equation becomes (for independent, derivative on PV): CV = K_{p}*E + K_{i}*(Totalized{E*LoopUpdateTime}) + K_{d}*^{(Current PV  Last PV)}/_{LoopUpdateTime} + Bias It's easy enough to roll your own (although a bit more than 3 multiplies, unless you are willing to combine constants, (LoopUpdateTime is a constant, and SUM(E*k) = k*SUM(E), from the distubive principle that you should have learned in 4th grade) So the equation becomes: CV = P*E + I*(Totalized{E}) + D*(Current PV  Last PV) + Bias Where P = K_{p} ; I = K_{i} * LoopUpdateTime; D = K_{d} / LoopUpdateTime When I saw that you were changing the LoopUpdateTime threefold, I thought that you'd have to do the inverse to K_{i} in order to keep the 'I' term the same. But since you changed the trigger time as well, there was only 1/3 as many values of 'E' in the totalized(E), which is why you say you didn't detune the loop. But that doesn't take the derivative portion into account. There, there is no historical sampling of E, and so (I think) that you effectively divided the derivative portion by 3. I doubt that derivative by itself would produce the drastic changes in your graphs (that's due, as you point out, to the CV not being adjusted frequently enough to control the PV adequately) but it might explain the detuning that happened when you updated even more frequently (Fig 6). Again, thanks for pointing out yet another mistake in the Rockwell manuals, about the 1/5 to 1/10 update time. Here's a question. "How long is too long?". I had a PID a few years ago where the natural period was about 40 minutes (really big cooling tower basin (think olymipcsize swimming pool, 3 feet deep) the theory was to refill it at the rate of evaporation). The problem was that the when a tower was turned off, all of the water that was in transit would stay in the basin, raising the level dramatically, so that the loop had to respond quickly to that change, but slowly to evaporative changes. I finally got fed up with trying to put in PID control and did a simple OFFLOWMEDHIFULL control based on level (is this "fuzzy logic"?  I don't know). Was this loop tunable? We had some numbers that worked (although still tended to oscillate quite a bit). I think I had the update time around 3 seconds (400 updates per period, if I had the period right) 
Your got
Quote:
Quote:
Kd*(Current PV  Last PV)/LoopUpdateTime If the loop time is 1/3 as long and the PV changes 1/3 as much in the same time, then the result stays the same. 
another day  another loop
1 Attachment(s)
Quick recap: We had decided to run the “how fast to update?” experiment on a much slower loop  in order to remove the possibility that the simulator’s update time might be the factor which was limiting the loop’s performance  rather than the execution time of the PID. I ran the experiment on my “long period” heater simulator  and didn’t really believe what I saw. My obvious conclusion: The simulator was not performing in a realistic manner. So I connected up a “real world” heater process in the lab. It’s a SMALL heater  but it is NOT just a mathematical simulator. The graphs below illustrate the results.
Each graph has a 22 minute span for the Xaxis. The temperature scales on graphs #1 through #3 range from 50 to 300 degrees F. Graph #4 is the exact same data as graph #3  but I shifted the Xaxis scale on graph #4 in order to show the actual CV trace. [attachment] Graph #1  This illustrates a test to find the natural period of the system. The setpoint was 200 degrees F. The Loop Update Time was set for 0.50 seconds. The PID’s trigger timer was also set to 0.50 seconds. The Integral action and the Derivative action were both turned off. The Proportional gain was set to its maximum value of 327.67  to insure that the system would go into oscillations. Careful measurements indicated a natural period of 183.6 seconds. Graph #2  Previous experiments with this system had suggested that “adequate” response would result when using the following tuning parameters: Kc = 2.20; Ti = 3.06; Td = 0.61. I dialed in these settings  and then I left them unchanged throughout the rest of the tests. The Loop Update Time in graph #2 was 0.50 seconds  selected as just a nice round arbitrary number. Calculating: 183.6 seconds per period divided by 0.50 seconds per update equals 367.2 updates per period. This is quite fast  but I wanted a “benchmark” test. The system was allowed to settle at a setpoint of 100 degrees  then I made a step change to the setpoint to bring it up to 200 degrees. The results of graph #2 show an “adequately” tuned loop with an “acceptable” response to the change in the setpoint. Graph #3  The Loop Update Time used in graph #3 was 91.80 seconds  specifically, just 2 updates per period. My earlier experiments with the simulator indicated that this Loop Update Time setting SHOULD work with this particular system  but quite frankly I didn’t believe it. Calculating: 183.6 seconds per period divided by 2 updates per period equals 91.80 seconds per update. This is extremely slow  and I just knew in my heart of hearts that this slow update schedule was going to give “lousy” control. The system was allowed to settle at a setpoint of 100 degrees  then I made a step change to the setpoint to bring it up to 200 degrees. To my surprise  the results of graph #3 show a loop with a response which would be considered “quite acceptable” in many heating applications. So what the heck did I just learn here? It seems that for some (slow?) systems even just 2 PID updates per period are quite adequate for acceptable control. Looks like the guy who suggested an update setting of “1/5 to 1/10 times the natural period” in the AllenBradley book just might have a leg to stand on after all. Going further  I’m thinking that the “large capacitance” and overall “slow response” of this particular system are the principle characteristics which make this “justonceinawhile” PID update schedule work. I’m hoping that Peter can shed some light on this with some of his “black magic” mathematics. In the meantime, I’m just going to say that when it comes down to PID update times  “one size does NOT fit all” systems. Well, I already knew that  but honestly this one surprised me. Allen  do you think that the characteristics of this “big old sluggish” heating system make its operation similar to that of the “really big cooling tower basin” which you mentioned in your post #6? Sorry, but I haven’t had time to go over (in much detail) the last posts that you guys made. Work is keeping me pretty busy the last few days  but maybe this weekend ... Graph #4  This was included in order to show the CV and how “jerky” it turned out with the “2 updates per period” schedule. This is exactly the same data as shown in graph #3  but with a different temperature scale. I think it’s kind of interesting that the PID can “nudge” its output  then wait for over one and a half minutes  before rechecking the input signal and “nudging” the output again  and it STILL drives the darned thing onto the target. And incidentally, that little “fuzzy” section at the left end of the CV is where I still had the Loop Update Time set for 0.50 seconds. Finally, in case anyone wants to know  I measured the system’s deadtime at 36.6 seconds. 
Your results are very intersting, Ron, but not surprising. The systems I control are large capcitance, slow response, and I consistently get better results with long times for loop updates.

I depends on what one is controlling or it depends on what the meaning of tuned is..
Heating systems are simple examples because they can be modeled as 1 real pole or time constant. This means that a step jump in the control output (CV) will cause the temperature(PV) to exponentially approach a steady state value with out oscillating or even overshooting like a resistor capacitor filter. Ron and Tom are both right in that slow updates will work ( it depends on your definition of what is OK ). One can see that faster is better. Notice the slow update PID does overshoot where and openloop control would not. If minimizing overshoot is a requirement then one can see that one must update the PID faster. I do not considered example 3 as being 'tuned'.
Two or more pole systems, that have imaginary poles, are much more difficult to control. The imaginary poles mean the system will oscillate in response to step jump in the control output. These systems have elements that can store energy and it is the transfer of energy from one element to another that causes the oscillation. A mass and a spring or capacitor and inductor are examples of two poles systems with imaginary poles. Motion systems also fit in this category. One does need faster PID updates to control these systems. Think about this. Would you use a motion controller that overshoots like example 3? Even example 2 is not good. About step jumps in the Set Point. Making step jumps in the SP is not a good idea because the system can't possibly instantly respond to a step jump in the SP. The error cause the integrator to windup which must eventually be unwound by overshoot. One should ramp the SP from one setting to another at a rate that the system can follow so that errors and overshoot are minimized. A motion controller do not move from 4 to 10 inches by making a step jump in the SP. A motion controller ramps to SP from one position to another using velocity and acceleration parameters to limit the rate so that the motor can keep up will little following error. I don't understand why process people are so lazy as to not do the same thing with their temperature, pressure or coloer process? I think it would be interesting if Ron would slowly ramp the SP using the 2 PID updates per period. Since we are talking about heater controls I think Tom should get in a few words about sliding mode control on a different thread. Sliding mode control works well with single pole system such as heater controls. What I am interested in specifically in the algorithm Tom uses to turn the heater(s) off and on. I know that proper sliding mode control involves more than just turning on and off heaters at a fixed set point. This set point must also ramp ( slide ) to the final setpoint. I have been looking into sliding mode control to turn on and off poppet valves on an pneumatic cylinder to control position, velocity and applied differential force. This is trickier than just turning four valves on and off. Just as in the heater control, one must know when to turn the heater on and off and calculating that point may not be trivial. 
PID simulated
Gentleman,
After I read your post in here, I would like to learn about PID control.I have some "tools" as I was describe in below: 1) RSLogix 500 software 2) Processor SLC 5/04 3) 1746NIO4V (2 chanel input, 2 channel output voltage) 4) 1746 IB16 5) 1746 OB16 6) Voltage regulator (0  10 VDC) 7) Voltmeter 0  10 VDC 8) Switches ON/OFF 9) Pilot lamp, etc. Since I don't have the " real world" (like a valve, temperature source,etc)to practical the PID control, so that I would like to try with what I have. Where I should start to learn about PID, anyone can help? My apologize if my question is very basic for you. Thanks in advance Deer 
Virtual System using magic math.
Quote:
SP = SP*(T/(t+T)) + K*(t/(t+T))*CV Where: t is the update or scan time of the simulator. T is the time constant of the system you want to simulated. K is the system gain which should be set to 1 when getting started. It takes 5 time constants for a system to reach within 1 percent of a step jump change. Therefore, if you want to simulate a system that takes 5 minutes to reach steady state, you would have a system that has a time constant of 1 minute or 60 seconds. If the simulator gets updated every .1 seconds then the equation above would be: SP = SP*(60/(.1+60)) + K*(.1/(.1+60))*CV Simplifying SP = SP * .9983361 + K * .0016639 * CV Use a CPT block activated by a timer. Remeber, K should be left at one for starters, one can adjust this to convert CV units to temperature so that a CV of 016383 equates to 0 to 900 degrees. In this case K = 900/16384 = .05493 This will make the system more realistic. The equation for our virtual system is SP = SP * .9983361 + .0000916 * CV The PID should not update faster than the virtual system and ideally the PID should update much slower. To simulate dead time one would need to put the CV in a FIFO. The current CV from the PID would be put into the FIFO. The above formula would use the delayed CV. In our example the virual update rate is .1 seconds so we would require 10 delay elements to simulate a dead time of 1 second. This could a problem on the SLC as its register files are only 256 elements long so it simulate a dead time longer than ~25 seconds unless the virtual systems updates is reduced to 1 every .2 or .5 seconds. Now you will be doing the same thing I do with my spread sheets. 
All times are GMT 5. The time now is 04:19 PM. 
.