SLC 500 5/03 PID loops

[Ron Beaufort]

Greetings to all,



first things first ... thanks to JohnW for posting those handy tips for “manually” tuning a PID loop ... I agree that they work well for many different types of processes ... I’d just like to add a few words to the instructions that John has given to make it (possibly) a little bit easier for beginners to apply this useful information ...



disclaimer: my notes below are based on using an Allen-Bradley PID set up for the “Dependent/ISA” equation ... selecting the type of PID equation is an option in the PLC-5 and ControlLogix processors ... on the other hand, in the SLC/MicroLogix processors the “Dependent/ISA” equation is the only equation available ...



and so point by point ...

1.Turn off the I and D components

that’s done by putting a “0” in both the “Ti” and the “Td” settings ...

2.Set the P component until the process oscillates at its natural period

as you increase the “Kc” setting (for Proportional action) in small steps, it’s a good idea to “bump” the process each time you make a change ... if you don’t do this “bumping” action, then it’s possible (for some processes) that the “Kc” setting could be increased step-by-small-step up to a VERY high number without introducing any oscillations at all ... and then WHAM! ... all of a sudden the thing starts oscillating like crazy ... it’s sort of like winding the spring on a grandfather clock that has run all the way down and has stopped ticking ... you can wind the spring tight enough to break it - but until you reach out and start the pendulum swinging, the clock won’t ever start to tick ... the “bump” is usually done by making a sudden significant change to the setpoint - and then JUST-AS-SOON-AS the PID starts to react, put the setpoint right back to its original value ... then watch the resulting oscillations to see how long they take to settle down and die out ... when the oscillations keep going and going continuously (and never settle down), then you’ve reached the “Kc” setting that John is talking about ... the “natural period” that he mentions is the length of time from the crest of one oscillation wave to the crest of the next one ... important: the general idea is to “sneak up” on the “Kc” setting and try to find the MINIMUM value that will cause the sustained oscillations ... note: you don’t have to get down to “nickels-and-dimes” with it (changes of 0.10 are usually fine enough) but don’t use a sledgehammer approach either ...

3.Set the loop update time to 1/10 of the natural period

that’s a common rule of thumb ... and it works adequately in most applications ... but a lot of people set the loop update for about 1/20 of the natural period ... in other words, they have the PID controller “look at the process” and then “calculate a new output” about twice as often as the 1/10 rule of thumb ... they figure that “too often” is better than “not often enough” ... basic idea: as long as the processor’s scan time isn’t an issue, then it doesn’t hurt to go faster than necessary ...

4.Set the P component to about 1/2 that required for oscillation

in other words, whatever the minimum “Kc” setting that you dialed in to produce the sustained oscillations, divide it in half ... (example: “2.22” becomes “1.11”) ...

5.Adjust P until the process is steady but with a steady state error

I’m not sure exactly what John means by this ... in my experience, cutting the “Kc” setting in half (as done in the preceding step) is pretty well guaranteed to produce the “steady but with a steady state error” conditions he’s mentioning here ...

6.increase the I component until the steady state error is within limits

for raw beginners, this can be a little bit trickier than it sounds ... the tricky part is that to INcrease the Integral ACTION, you have to DEcrease the Integral setting ... the setting is labeled “Ti” ... but ... remember that we left the Integral action turned “OFF” in Step 1. by entering a value of “0” ... so how (you might wonder) do we now increase the Integral action - by decreasing the entry to a setting of something LESS THAN “0”? ... special rule: the value of “0” turns the Integral action “OFF” ... once you leave the value of “0” behind, then the regular rule of “smaller-setting-means-more-Integral-action” takes over ... this “backwards” rule of DEcreasing the Integral setting “Ti” to get an INcrease in Integral action, creates a lot of problems for people who are just getting started with this PID stuff ... even when they know that they need “more Integral action”, they often go the wrong way with the setting ... this can waste a LOT of extra time (and often waste a LOT of raw materials) and lead to a LOT of frustration ... tip to preserve your sanity: get in the habit of NEVER saying either “increase the Integral” or “decrease the Integral” ... instead, ALWAYS say it one of these ways: “increase the Integral ACTION” or “decrease the Integral SETTING” or “decrease the Integral ACTION” or “increase the Integral SETTING” ... basic idea: by always specifying the ACTION or the SETTING, you’ll remove the ambiguity that causes so much mischief ... of course, once you get used to the way it works, it will become second nature ... but in the meantime, it’s best to nail things down so that there’s as little confusion as possible ...

7. If external influences cause instability then introduce some D term until the process is stable.

the Differential action is sort of like Tabasco ... a little bit can go a long way ... simple rule of thumb: whatever amount you’re getting ready to try, use only half as much to get started ... once again, an entry of “0” to the “Td” setting will turn the action “OFF” ... but unlike the “Ti” setting for the Integral action, this time the adjustment direction will make more sense to a beginner ... specifically, an INcrease to the “Td” setting (a bigger number) will cause an INcrease in the Differential action ...

continued in next post ...

 

[Ron Beaufort]

continued from previous post ...

as for the other useful tips that John mentioned:

Process overshoots - Increase D or reduce I

Process oscillates - reduce P

Process under shoots but reaches SP then reduce D

Steady state error - increase I

Response too slow - increase P or I

I’d like to add this ... when John says “reduce I”, he means “reduce the Integral action” ... just remember that to make this adjustment, you need to INcrease the value of “Ti” ... conversely ... when John says “increase I”, he means “increase the Integral action” ... and, of course, to make this adjustment you need to DEcrease the value of “Ti” ...



as to the tip “Process oscillates - reduce P” here’s something that might prove useful ... too much Integral action can also cause the process to oscillate ... but ... the period of oscillation will be longer than the period produced by too much Proportional action ... you’ll see this effect by comparing Figures 1 and 3 in this post that I made some time ago ...



while you’re there, take a look at post #6 in that same thread ... this points out that in some (most?) cases, the “no overshoot” response that most people earnestly strive for while doing their loop tuning, is not really the optimum response for the process ... specifically, even though the “no overshoot” response shown in Figure 1 looks a lot more impressive than the “sloppy” response of Figure 3, look at how long it takes for the “no overshoot” tuning to recover from a LOAD change as shown in Figure 2 ... this is much more “sluggish” than the response produced by the “sloppy” tuning values as shown in Figure 4 ... secret handshake: if the boss NEVER changes the setpoint, then the “no overshoot” response (Figure 1) might not be the most desirable tuning goal ... as with most human endeavors, PID tuning is a series of tradeoffs ... by accepting a few ripples to our setpoint change (Figure 3) we might gain a much more aggressive and rapid response to a load change (Figure 4) ... when you get right down to it, who cares about the overshoot to the setpoint change anyway - IF (that’s a big IF) we’re NEVER going to change the setpoint? ...



anticipating your next question: so if we’re never going to change the setpoint anyway, then why the heck do we make all of those step changes to the setpoint while we’re trying to tune the system? ... answer: watching the system’s response to the setpoint changes is a fairly reliable way to gauge how the process is currently reacting to our latest tuning adjustments ... this is good because step changes to the setpoint usually cost little or nothing in the way of the plant’s expensive raw materials ... on the other hand, testing the response by making a series of LOAD changes can be VERY expensive ... just try telling the boss to go drop another couple of tons of steel in the furnace just so that you can see how well your latest PID tuning is working out ... the fact is that changing the LOAD on many types of systems often requires a lot of wasted raw materials AND the expense of disposing of the wasted junk that results from all of our tuning experiments ... think: $$$$ ... that’s why most people use changes to the setpoint while they’re experimenting with the tuning - even though the setpoint will never be changed once the system is tuned ... but ... unfortunately, they’re often (usually?) watching the setpoint changes and looking for the wrong response! ... they often spend a LOT of effort trying to get that neat smooth “right-up-to-the-setpoint-with-no-overshoot” response ... when the “let’s-tolerate-a-couple-of-ripples” response might give the boss a much more efficient reaction to the load changes that his system will inevitably face ... these are all things that need to be considered before we even begin to tune the system ...



basic idea: if you’re not sure exactly what you’re trying to achieve, then you might be working very hard to achieve the wrong thing ...



well ... that sounds rather profound ... and since it applies to life in general, as well as to PID loop tuning, I think I’ll close with that thought ...


PS edit: in my personal opinion, everything that I wrote above is correct ... but it was written for the benefit of our beginners - and so it represents some amount of simplification in certain areas ... I’m sure that others will have other opinions ... I’m looking forward to reading those too ...

 

[TConnolly]

The reason why the integral gains seems backward with respect to integral action in the dependent gains form of the PID equation can be seen if you take a look at the equation.

Notice that the integral gain (T_I) is inverted before the integration is performed.

 

[kamenges]

The other part of the reason the integral gain looks backward is that it's not a gain but a time. As I remember, this setting defines the time needed for the integral sum to increase by an amount equal to the error value. Given that definition larger values of T_i will yield slower changes in the integral sum.


Now, I'm still lost with the whole T_d thing. I'm not real sure what time they are defining there.
Keith

 

[Ron Beaufort]

be careful what you ask for ...

Now, I'm still lost with the whole Td thing. I'm not real sure what time they are defining there.

the VERY basic answer is in this line (from page 9):

notice that ... the Derivative setting (Kd) has been set for “0.10” minutes ... what this means is that the Derivative action will start out by calculating a value equal to 0.10 times the PV’s “one minute” rate of change ...

but there’s much more information here ...

 

[kamenges]

Thanks, Ron. At least now I know. I don't have to like it but at least I know.

Keith

 

[JohnW]

Thanks Ron for expanding on my very "bare bones" explanation, in my defence I was tring to keep things as general as possible as at the time I was dealing with PLC5, SLC and ML1500 and using both dependant and independant PID blocks. In practice I have found that one of the most valuable skills in tuning temperature loops is patience. Another area that causes problems is the loop update time, it is important to be sure that you know exactly how often the PID loop is processed, in the SLC and ML this is not too much of an issue but don't overlook it and set it to STI if it is not in an STI file! If you are using block transfers such as in the PLC5 or remote I/O then it is important that the loop update time period is longer than the block transfer update time and that you in fact have valid data to use. Changing the loop update time will also affect the Ti and Td settings.

I came to PID loops pretty late in life, most of my experience in tuning control loops is with analog and digital naval gunnery servo systems, a completly different ball game.

P.S. With regard to the program I posted, the correct addresses for PV and CV are Nx:24 and Nx:26.

 

[Ron Beaufort]

from JohnW:

in my defence I was tring to keep things as general as possible ...

no defense is necessary John ... I’m sure that many people will find the material that you posted helpful ... all I wanted to do was make sure that they know which way to “turn the screw” to accomplish the excellent suggestions that you made ...



and a note to Keith ... if you’re still following this thread, I covered a more (maybe?) “intuitive” way to look at the “minutes” measurement of the Derivative setting in this post ... I had forgotten about this one the other day ... hopefully I’ll have time to update the PDF on the website with this addition in the next week or so ...

 

[kamenges]

Originally posted by Ron Beaufort:

...I covered a more (maybe?) “intuitive” way to look at the “minutes” measurement of the Derivative setting...

That's an interesting way to look at it, I must say that. At least in the alternate method the unit name makes some sense. I personally find the initial explanation easier to conceptualize even though it doesn't seem to make correct use of the unit name.

I'm just playing semantics here, anyway. I never knew why they refered to T_d in terms of time. Now I know.

Keith