Diagnosing and Solving Control Problems
April 30, 2011
While many control loops are easy to tune and present almost no control problems, a few control loops can be very problematic and never seem to control right. Control practitioners can spend many hours or even days trying to improve the performance of these challenging control loops, but the results often remain unsatisfactory. This article presents strategies for diagnosing control problems and improving the performance of challenging control loops.
Symptoms of Poor Loop Performance
Although poor control performance come in many forms, it can be grouped into three categories:
- Oscillations and instability – the loop tends to cycle around its set point.
- Large deviations from set point – the loop struggles to remain at set point and the process variable is frequently pushed away from set point.
- Sluggish performance – the loop takes too long to get to its set point after a disturbance or set point change.
A Control Loop with Several Problems
I’ve seen many cases where attempts to address poor performance were limited to controller tuning, because the person attending to the problem did not know of all the other causes of poor performance. To properly address and improve control loop performance, it is necessary to establish what the real cause of the poor performance is, and then to take the appropriate corrective action.
Fault Diagnosis
To guide your diagnosis efforts, a fault diagnosis tree is provided below. The first level of diagnosis is the three symptoms of poor control listed above. Depending on which of these symptoms your control loop displays, you can find the possible causes below each symptom. These are described in more depth throughout this article.
Diagnosing Control Problems
1. Oscillations
Oscillations can originate from within the control loop or be caused by external factors. To find out which is the case, place the controller in manual and see if the oscillation stops. If it does, the oscillation is generated from within the loop.
Oscillations Stopping when Controller is Placed in Manual
Internal Oscillations
Oscillations generated internally can be caused by faulty equipment or by tuning. Check first for faulty equipment, because you can spend a long time trying to tune a loop if the real cause of poor performance is the control valve.
The most common control valve problems causing oscillations are:
- Control valve stiction. Do a stiction test with the controller in manual to determine if this is the case.
- Positioner overshoot. Do step tests of various sizes and be on the lookout for signs of overshoot in the process variable.
Both of these control valve problems and cannot be fixed by tuning the process controller. The valve needs maintenance or the positioner needs tuning.
Tuning
A loop that is tuned too aggressively (overly fast response) can quickly develop oscillations. Do step tests on the process and determine the dominant process characteristics (gain, dead time, lag). Do more than one step test (try to do four at least) in different directions. Then use tuning rules to calculate new controller settings. If you are using rules designed to produce quarter-amplitude damping, use only half of the recommended controller gain. If you have tuning software, then use it to analyze the step-test data and calculate new controller settings.
Nonlinear valve Characteristic
Many control valves control flow differently, depending on how far they are open. The valve is said to have a nonlinear installed characteristic. If tuning is done at the one end, the settings might not work at the other end, and could cause oscillations or sluggish behavior. If this is the case, a function generator (X-Y curve) can be placed in the path of the controller output to cancel out the control valve nonlinearity.
Nonlinear Process
Some processes react differently based on operating point, production rate, or the product being made. If these differences are large the loop can begin oscillating or become sluggish. Then different tuning settings are required for the various operating conditions. This is called gain scheduling.
External Oscillations
Externally sourced oscillations can be caused by interactions between loops with the same dynamics or simply by another loop in the process oscillating and causing several other loops to oscillate with it.
Coupled Interaction
Interactions between loops with the same dynamics can cause the two loops to “fight” each other. A simple example of this is if two valves control the flow and pressure in the same pipe. Because the dynamics of liquid pressure control loops and flow control loops are similar, the two controllers might be tuned very similarly, causing the hunting between the two loops. To solve this, the most important loop needs to be tuned for fast response, and the loop of secondary importance needs to be tuned significantly slower (three times or longer settling time).
Dynamically Coupled Control Loops
Process Interaction
One loop in the process could be oscillating, causing several other loops in the same process to oscillate with it. Use a process and instrumentation diagram (P&ID) to locate possible offenders. Then use historical process trends of these other loops to find the oscillating loop. Several software vendors like ExperTune, PAS, and Matrikon/Honeywell have products to help with locating the offending loop in a plant-wide oscillation scenario.
2. Sluggishness
The next category of poor control loop performance is sluggishness. Sluggish control loop response can be caused by equipment problems or by poor tuning.
Control Valve Dead Band
Dead band (also called hysteresis), can cause a loop to exhibit sluggish behavior. Every time the process variable undergoes a disturbance in a different direction from the previous disturbance, the controller output has to traverse the dead band before the valve begins moving. Dead band can be detected very reliably through simple process tests. It is a mechanical problem and cannot be addressed with tuning.
Other Equipment Problems
A control loop may also appear to have sluggish response if the controller output becomes saturated at its upper or lower limit. Similarly, if the process variable runs into limits, the control action effectively ends. Also, if the controller output has a rate-of-change limit, it may cause sluggish response, regardless of how well the controller is tuned.
Tuning
Comments made earlier about tuning apply here too. Furthermore, realize that loops have internal “speed limits” depending mostly on the length of the dead time in the process. It will take a well-tuned loop three to four times the dead time to get back to its set point after a disturbance or set point change. If disturbances cause large deviations from set point, and tuning is unable to correct it fast enough, see the next section.
Upper Limit to Loop Speed – any faster tuning will cause larger oscillations
3. Disturbances
The third category of poor loop performance is that of disturbances pushing the process variable away from its set point. Disturbances are frequently the nemesis of good loop performance. As described above, feedback control is limited in how fast it can eliminate the effects of a disturbance and bring the process back to set point. Two classes of disturbances exist, depending on how they enter the loop.
Control-Flow Disturbances
Control-flow disturbances affect the loop by changing the flow rate through the final control element. For example, if steam is used to heat the process flowing through a heat exchanger, and the pressure of the steam decreases, the steam flow rate will be affected and this will disturb the outlet temperature.
Cascade control can be used very effectively to virtually eliminate the effects of a control-flow disturbance. The outer loop controls the main process variable (temperature in this case) by changing the set point for flow to an inner loop. The inner loop measures and controls the actual flow rate and immediately corrects any deviations from set point.
Cascade Control for Handling Control-Flow Disturbances
Process Disturbances
In contrast to control-flow disturbances, all other disturbances to the process that affect the process variable are simply called process disturbances. If a process disturbance is measurable, and its effect on the process variable is known, feedforward control can be used to vastly reduce its impact.
Feedforward Control for Handling Process Disturbances
Stay tuned!
Jacques Smuts – Author of the book Process Control for Practitioners
Posted in 
Hello,
I have a flow control valve that operates OK in automatic. This valve only really operates between 25-40%. However when the valve tries to maintain 25%, it keeps osciallating with the around the setpoint. What could be causing this? Here are my theories:
1. Valve may have a non-linear characteristic and that may need to be placed on the output of the PID – I have yet to confirm this
2. Could the valve be oversized?
Are these correct and are there other factors that could be attributing to this?
Thanks
Jam,
1. It could be that the valve has a quick-opening (nonlinear) type of flow characteristic. Is it a butterfly valve? If so, see this article:
It could also be that the valve is sticky around 25% – see this article:
2. It seems that your valve is a bit oversized – control valves should ideally operate around 75% – 85% open at design flow rates.
– Jacques
In an article or post that I can’t find right now I recalled the author said you can prevent excessive valve wear by not letting the valve move unless the PID output changed by more than some amount.This idea was greeted with derision in a group discussion, so I’m trying to figure out whether the idea has any merit.
As with many things in process control – it depends. If you have a noisy measurement signal, and a high-gain controller, your controller output will likely move around much more than you like and wear out the valve prematurely. You have a few options, depending on your controller’s features.
1. You can filter the process variable (my preferred option), but realize that this adds additional dynamics to the loop that requires slower tuning which slows down the loop response. If your process is already a slow-responding process, the additional dynamics may go virtually unnoticed, making it a very good solution. However, if you have very low-frequency noise, you need a very long filter time-constant, which can make this an infeasible solution. (Your filter time constant should be substantially shorter than your process dead time and lag to achieve fast loop response).
2. You can also set a deadband around the process variable or controller output, which brings me to your question. If apply a deadband, the controller will move the control valve only when the limit of the deadband has been reached. The wider the dead band, the less often your controller will move the valve (and make smaller movements). If you set dead band larger than the noise, the controller does not respond until there has been a significant change in the process. This effectively adds pseudo-deadtime to the loop, making the control loop behave very sluggishly. So,, for fast loop performance, just as the lag in a measurement filter should be set much shorter than your process dynamics, you should ensure that the additional deadtime added by a deadband is also much shorter than your process dynamics.
3. You can also look at using a different measurement technology, if the problem is measurement noise.
Also, make sure you are not using derivative control on a noisy measurement signal, and if you have to use it, consider lengthening the controller scan time to reduce the gradients the derivative term sees.
Just to clarify, the method I’m describing involves ignoring a change in the PID output (CV)unless it is more than some amount. If the CV = 45.0 %, I would hold that number in a register and keep sending that to the valve. I’d not change that signal going to the valve until say CV 45.5% (my deadband is 0.5%). So if I saw the PID output reach 45.6%, I’d update the hold register and start sending that to the valve. Then, until CV 46.1% I would keep sending the hold register value 45.6% to the valve. Is this what you thought I was saying?
One person opined this is equivalent to putting a deadband on the error between PV and SP (which in Rockwell is implemented with a parameter called “CV Zero Crossing Deadband”.) But I’m not so sure.
Is my proposal to keep the valve at the hold value until the CV changes by more than a deadband have a history in the field. I think I got the idea from a post by Greg McMillan and thought it sounded good. To your knowledge has this been done?
William, thanks for clarifying what you mean.
First, the 0.5% “deadband” seems far too small for reducing excessive valve wear.
Second, the method you propose artificially introduces the equivalent of stiction, which is very bad for stability.
I don’t know if it has been done, but I will advise against it.
Congratulations for your great didatic posts.
About the controller “deadband” idea over problematic valves, as mentioned by William, recommendation is actually to add a “deadband” only over the Integral action of the PID. You keep the proportional action active, so to avoid the stability issue.
Most regular commercial PID-blocks won’t allow this. It is a functionality in the PID-plus from DeltaV and you find McMillan article on it over the web. You can also arrange this functionality in systems with PID-blocks that allow external-reset feedback or external integration freezing command.
Jacques
I have worked extensively on Process Controls for many years and with all the control strategies I have implemented I sometimes run into the problem of Process Saturation that tends to throw a wrench into the best laid plans.
With typical multi-level control strategies Output Tracking and Integral tracking are implemented (inherently in most cases or designed in others) to provide bumbles transfer and to prevent windup of higher level loops when either the controls are not being used (operations) or if limiting control strategies are active (overrides).
When Process Saturation events happen the lower level controllers tend to windup until limited at which point upper level loops will be flagged to limit their windup. While this is generally a good result the problem lies in the fact that if the higher level loops call for a reversal of the Setpoint of the lower level loops then the required unwinding of the Saturated Process results in a dead zone where the higher level loop winds down due to the lack of control of the lower level loop (until the Saturated Process situation is no longer active). This situation presents itself in a similar manner as Valve Stiction but of course this is where the process is unable to deliver the required controls.
By implementing strange workarounds to this issue (using output limiting tests on the lower loops to detect the saturation and bring the output back to a closer point of control) we can sometimes correct the problem but I always find this a bit of a McGivered solution that is not apparent to operations or even other control technicians.
I am curious if you have come across a way to have the controller detect a process saturation occurrence and present this information so that the control actions required can be cleaner?
Paul: Other than looking at the error or control-element saturation, I have not come across smart ways of detecting process saturation. However, the use of external reset feedback is a smart way of preventing controller windup altogether.
I recently noticed that we had an issue with a condenser level controller on a steam driven compressor. The condenser level is to be controlled to 50%, and under stable conditions, this was the case. However I noticed that during temporary increases in compressor inlet steam flow (to suit downstream process) the level would begin to oscillate between 55% to 45% and take over 30 mins to stabilise. Our kP was set at 0.8 and Tn at 15 (as per our DCs terminology for gain and integral respectively). During a pause in downstream process, I conducted a few step tests and retuned kP to 1.9 and Tn to 150, which resulted in deviations of no more than 1%. The old tuning had been in place for over 10 years and only came to light because of a change in our historian software. So less stress on our final elements which should increase life expectancy
Well done Dave! The original tuning was probably done by an inexperienced tuner who deemed the resulting response “good enough”. Good job applying a proven tuning method.