
Question: How do I properly tune my controller? Answer: This question has no direct answer, for a controller could be properly tuned in a variety of ways. The following is a basic "Rule of Thumb" to visual PID tuning.
VISUAL LOOP TUNING: This tuning method was developed over a period of several years as a way to understand the performance limitations of a loop and make fewer assumptions about linearity and process response than is required for ZieglerNichols and other computational methods. This tutorial was written with industrial process control in mind and with operators and instrument technicians as the target audience. You’ll find it helpful to visualize the three control effects of the modern PID controller:
Proportional Gain Proportional gain affects all frequencies (unlike integral and derivative action), and is therefore usually optimized first, since frequencies between the low range where integral action dominates and high frequencie where derivative action dominates can only be affected by gain. This middle frequency range is critical in rejecting disturbances. The action of proportional gain in this frequency range is the reflex action that reduces the magnitude of the disturbance, and is satisfied with bringing a disturbance to a halt. The more gain, therefore, that the loop will tolerate without over reacting, the more work it will do, and the less important the other settings become. If the loop would tolerate infinite gain, the other terms would be unnecessary. Integral Time (or on some controllers, integral frequency or gain) As the effect of proportional gain brings a step disturbance to a halt (I refer to this as the "over the hump time"), the integral action becomes significant, and is responsible for getting the process to slide back precisely to the set point. Integral action takes some time to recognize that an error is not just a passing fad, but is here to stay. It is a perfectionist, remembering where the process was operating just before the disturbance, and is slow to decide that a different operating point is necessary. Once called "reset," the integral was then a manual setting added to the controller output. If it were clear to the operator that the process had shifted and the controller was not going to restore operation all the way to the set point, then the operator would tweak this knob to "reset" the average process back to where it belonged. Integral action is just an automatic and continuous way to accomplish what operators once did manually and via discrete actions. Derivative Time (or on some controllers, derivative frequency or gain) Usually proportional and integral action, properly set, will give adequate response. In cases where the process consists of several lags in series, has a resonant step response, or is integrating, derivative action may improve the response. Derivative action is used to cancel out one lag (or, time constant) in the process, and thus remove some phase delay and high frequency attenuation. Derivative action can be visualized as the wildeyed stock market forecaster who predicts the next day’s prices today. If the process is clean and predictable, the results can be very good, but if the process is noisy or delayed, the results really are like most market forecasters  all over the place. The derivative action tries to pull a developing trend out of the process variable before that trend is fully developed, to give the controller a warning of a trend that will be as hard to stop as it is hard to see coming. A derivative time of 1 minute means generally a prediction of where the process will be one minute into the future. Gain Increments I normally make about 40% changes in gain, derivative time and integral time, unless I am getting very close to the "optimal" values for the particular loop. I like this step size for several reasons:
This is nearly always a fine enough selection of tuning constant values. In rare cases, you may want to finish by splitting a pair of these, but if you are tuning that precisely, you are inviting disaster if the process shifts slightly and becomes less stable. The key to successful tuning is to understand clearly when you are getting close to (or you actually are) driving the process into instability. More on those signs later. Procedure Before attempting any tuning changes, you need to familiarize yourself with the operational risks involved with variations in the operation caused by tuning experiments. Get help from a good operator, and explain to that operator that no permission is required if their intervention is necessary to save your butt if things go wrong. I generally tune loops by stepping the output in manual mode, and immediately putting the controller back in auto mode, while observing the trends of controller output and process variable. Modern DCS equipment makes this easy, though some older single loop controllers require you to watch dials or (worse) digital readouts, and force you to visualize the trends in your head. This method works best if you can disable set point tracking during the tuning process, so that the set point stays put during the whole process. Assume you want to improve the performance of a loop already in service. Usually this is because the loop is either unstable (or apparently so), or is sluggish in response to upsets or setpoint changes. Apparent Instability: You need to determine whether the loop oscillates because of excessive feedback through this particular controller, or is being perturbed periodically by another process (which itself may be unstable). The easiest way to distinguish between these two possibilities is to put the loop in manual, assuming it is safe to do so. If the process appears to settle down when the controller is placed in manual, then it is likely that the controller is poorly tuned. If you must try to alter the tuning while operating in auto, you need to determine if the instability is caused mostly by too much, or too little gain, too much integral action, or too much or too little derivative action. Is the period of oscillation in that middle band of period controlled only by proportional gain, or in the range of longer periods (low frequencies) controlled mostly by integral action, or (if used) in that short period band (high frequencies) affected most by derivative action? Instability cannot normally be caused by too little integral action (i.e., too long an integral time setting). In some special cases, lowering the gain or derivative can make things worse. (These cases are called conditionally stable, where there is an optimum window of gain or derivative in which stable operation is possible.) The safest way to attempt to stop oscillations is to increase the integral time (reduce the integral gain), especially if the integral time is less than half of the oscillation period. This is a strong hint that too fast an integral correction is being made. This would be a case of the controller trying for perfection before the last attempt had settled. If the integral setting was responsible for the oscillation, the telltale signs are a smooth sinusoidal oscillation, and that increasing the integral time will increase the oscillation period, usually without increasing the amplitude. If this occurs, you are on the right track, and should keep lengthening the integral time till the oscillation damps out, or stops lengthening in period. The sticky valve is an example of the sort of nonlinearity that makes ZieglerNichols tuning (as an instance of a method that assumes a linear system) problematic. Such a valve may produce an oscillation that has a period proportional to integral time, except that you can increase the integral time as much as you like, and the oscillation period just gets longer, and longer. It is not a sinusoidal oscillation that is the characteristic of overactive controllers and linear processes. The output will show a triangular wave as the integral action keeps ramping the output up and down, while the process variable will show a fairly constantamplitude (the size of the jump when the valve loosens), nearly square wave. No amount of fiddling with tuning will stop this kind of limit cycle oscillation and still give good response to other disturbances. You either put up with the oscillation, do maintenance on the valve, add a valve positioner if there is none, or switch the controller algorithm to a dual gain controller that stops moving the valve when the error falls within some window. Such is the real world. If the integral time is longer than the oscillation time, then the integral action is not doing much at the oscillation period, so is not likely to be much involved in the oscillation. The linear exception is integrating processes, like level controls, that produce a 90 degree (or more) phase shift over a wide range of period. For these, the additional phase shift of integral action can push the total phase shift toward the magic 180 degrees that sustains the oscillation. With integrating processes, the process performs the integral effect that brings the process back to setpoint, and you have to get the controller integrator out of the way by setting it well above the closed loop response period of the process, and thus contributing little phase shift. Once you have the integral time long enough that it is unlikely to be involved in the oscillation, it is safe to try lowering the gain. After you have lowered the gain enough to get the oscillation damped out, it is safe to try the output step mentioned above without expectation that a sustained oscillation will result. From here on out, the method is the same as that I use to commission a new loop. Sluggish response: such a loop usually has no derivative action, and the integral time is long relative to the process response time. If these two things are not true, I make them true. (You should develop your understanding of the processes you tune, especially as to their expected dead time, and their expected response time, as this is the basis of the settings of the time based choices  especially the integral time.) Adjusting Gain
Adjusting Integral Action With the proportional gain about right, you are now ready to shorten the integral time to ramp the process bump, that follows your output step, back to setpoint. Effectively, you did a manual reset when you moved the output, and after the gain has had its chance, the automatic reset action of the integral effect will try to find the original output value that puts the process exactly back on setpoint. You can expect the integral time setting to be on the order of the closed loop time constant of the process with the gain optimized by the above process. But start about double that time, or even larger, if you want to see the integral effect clearly. As you reduce the integral time in 40% steps, the ramp time back to setpoint will reduce in 40% steps, but the peak disturbance will reduce only slightly to modestly depending on the dead time relative to the dominant closed loop time constant.
The optimal range of integral time will have been reached when the process ramps back to setpoint about half as fast as it moved away from setpoint from the output step. The sign of too short an integral time is an oscillation that is well centered across the setpoint, and whose period lengthens as you lengthen the integral time. Adjusting Derivative Action Now we come to the touchy subject of derivative. Some people never use it. Some controllers perform it so badly, that you would be wise to avoid it, if those controllers are what are being used. But if you are using equipment that does a reasonable job of derivative action, and the process calls for it, the benefits are greater stability, or faster response, or both. I will assume the first, here, so the challenge is to define a clear sign that the process will benefit from derivative action. ZieglerNichols (ZN) tuning methods are based on approximating the process step response as a pure dead time followed by either a pure time constant, or integration. If either of these models appears to be an accurate description of your process, you can achieve only an incremental gain in performance, but have to put up with the noise amplification effects. In these cases, I usually forego derivative action altogether. There are cases that really need the phase boost of derivative, and these are those that are not accurately modeled as above. The clearest sign that a process will benefit from derivative action is all in the initial corner of the step response. For the ZN process model, the step response reaches its steepest rate of change immediately after the dead time. If your actual process takes more than half of the dead time and between 10% and 50% of the closed loop "overthehump time" to reach maximum rate of change after a step, then you are looking at a candidate for derivative action. (By the way, it is almost impossible for a process to take longer to accelerate to full rate of change than it then does to reach maximum excursion, so 50% of "overthehump time" is a sort of worst case.) It is during this accelerating phase of the step response that derivative action extrapolates the eventual rate of change that is to follow, so that the controller can begin to react to this change earlier. Once you have arrived at reasonable settings for gain and integral time by the above method, the processes should display a dead time, acceleration time to full rate of change time, an inflection, "overthehump" time, and settling time back to setpoint. Look at the inflection point between the accelerating phase and the reverse curvature as the process goes "overthehump". The larger the acceleration time is relative to the "overthehump time", the more benefit you will get from derivative. The only gremlin preventing you from getting the full benefit of derivative action is the dead time. If it is much longer than the accelerating phase, it will cause all the output effects from the derivative action to occur time delayed from when they would have done some good, and you just end up storing echoes of the (derivative exaggerated) step response in the process dead time delay. So to summarize, derivative action is called for whenever the accelerating phase of the process step response is a significant fraction of both the dead time and the closed loop overthehump time. The signs that you have overused derivative are jerky output or sinusoidal oscillations the ride up the initial step response that make the process measurement look like a flight of stairs as it goes over the hump. Remember that derivative action deals only with periods shorter than the process closed loop response time. A process that is purely a single time constant (that is, the process response to a step is a pure exponential time constant curve) has no use for derivative. You can apply as much gain as you like to such a process, and it will not go unstable. Add dead time to this process, and the allowable gain will drop. That's because the dead time represents phase shift that increases as the period gets shorter. And phase shift is what stores the previous half of an oscillatory cycle. Remember, for a cycle to reproduce itself (sustain an oscillation), the process must store exactly one half a cycle that the controller inverts and sends back through this memory before that inverted half cycle appears to reproduce the original half cycle. And if the cycle is to hold its amplitude, the net gain during this echo recycling must be exactly one. The longest cycle period that achieves this 180 degree phase shift at unity gain is called the ultimate period of the closed loop process, and is the limit on how fast the controller can react without exaggerating the problem. Derivative raises the high frequency loop gain but reduces the phase shift allowing the period where 180 degrees phase shift accumulates to occur at a shorter period, and hence faster control capability. Or alternatively, the response time can be held, but just the phase shift reduced, increasing the stability (or increasing the damping). Process Variable Filtering (Damping filter) Most modern transmitters and many controllers include a damping filter for the process variable. It is useful for attenuating signals whose period is shorter than the period experiencing 180 degrees phase shift going through the process. All information in this frequency range cannot be dealt with usefully by the controller, and is best ignored, particularly if you are using derivative action which boosts high frequency gain. If you are correctly using derivative action, it is implied that the 180degree period is just a little shorter than the derivative time. So you can safely damp periods significantly shorter than the derivative time, without sacrificing the benefits. If your controller performs an ideal derivative (gain keeps rising with frequency) then you should set the damping filter at about one tenth the derivative time, to allow about a decade of derivative action. If your controller performs a frequency limited derivative (that means a damping filter is automatically set at typically one decade shorter than the derivative time), then you should set the damping filter about one twentieth of the derivative time, to avoid adding significant phase shift inside the derivative decade. Setting the damping any slower than this will begin to erode the effect of the derivative action. If you decide you need only a hint of derivative action, this is one way to achieve it. As an example, a large tank temperature control loop may require a gain of 30, an integral time of hundreds of minutes, a derivative time of tens of minutes, and a damping time of a minute or so. In this case, the damping filter also interpolates the quantized temperature steps of many transmitters. It smoothes the output, without affecting in any practical way, the controller's response. Variations Many modern controllers give you choices of different actions, especially with respect to derivative. Specifically, does the output react with derivative high frequency gain to changes in process variable, or to error? In general, since derivative is correcting for phase shift around the loop, and rate of change of setpoint has little to do with derivative action. I have never found much use for derivative based on error. Gain is another matter. If the process is easily upset, or upsets other loops, and has its setpoint set by an operator, you will probably be wise to choose gain based only on process, not error. This allows the integral time to act as a damping filter on setpoint changes, and may give an operator time to replace an incorrectly entered setpoint before damage is done. However, if the loop has long time lags, and isn't tangled with other loops, choosing gain based on error will speed the sluggish response to setpoint changes. If the setpoint is provided by another controller (cascade control) in response to a process change, you may not want the added damping of gain based on process only, which becomes part of the outer control loop's process. Unfortunately, so far, I have not seen a controller that lets me apportion the gain response fractionally between process and error, though I have heard that such beasts exist. Some other comments on cascade control: The above tuning method tests the response of a process to output steps (effectively, load disturbances) with a constant setpoint. When a controller has its setpoint commanded by another controller, there is an effective increase in loop gain, because as the inner (closest to the process modifier) controller is driving the process toward its setpoint, the outer (supervisory) controller may be driving the setpoint toward the process value. This is like shooting at a target that is approaching you. You tend to overshoot it. Also it is less important that an inner loop reach perfection in shortest possible time, because the setpoint will not be there by the time it gets the process there. So inner cascade loops tend to work best with somewhat less gain and somewhat longer integral time than if the loop were shooting for a fixed setpoint. Summary You may note that this tuning method is almost purely visual, and uses no algebra. The key techniques are in the sequence of choices, and knowing the signs of over or under use of each action. In this way, it is sort of like solving a Rubik's Cube. If you do things in the wrong order, you undo what you have already done, and you chase your tail in circles. Happy tuning.


