After search, use << and >> links at top of page to view other pages.
Get Updates on Facebook

Diagnosing and Solving Control Problems

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.
Loop with Several Problems

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

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 in Manual

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

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.

Loop Speed Limit

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

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

Feedforward Control for Handling Process Disturbances

 

Stay tuned!
Jacques Smuts – Author of the book Process Control for Practitioners

 

7 Responses to “Diagnosing and Solving Control Problems”

  • Jam:

    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

  • William Love:

    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.

  • William Love:

    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.

  • Luis Prox:

    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.

Leave a Reply

The Book for Practitioners