PID spotlight, part 19: PID controller tuning best practices

You’ve been trained to tune PID controllers on self-limiting and integrating processes, but are you ready to tune? Can we trust you to do it safely? Do you know how to work with the operators responsible for the process? Do you know that there are problems that tuning cannot fix? Finally, do you know that after you are done tuning you are not done?

Courtesy: Ed Bullerdiek, retired control engineer

The formal training of new process control professionals rarely includes guidance on how to work with operators and others to safely and effectively tune a PID controller. This is normally left to mentors to impart the skills necessary to be a truly effective control tuner.

The first lesson that a mentor should impart is in a well-tuned facility most loop tuning requests are indicators of a bigger problem. (Yes, I know this is rare, but they do exist). This means that at best your loop tuning efforts will cover up that problem – temporarily. A corollary to this is that your tuning efforts are part of a bigger problem-solving session. There are three possible outcomes:

It really was a tuning problem, and you fixed it.
Tuning worked around the problem, and you have passed the problem along with your thoughts on what the problem might be to someone who can fix the core problem.
You didn’t do any tuning because this is not a problem tuning can help. You have passed the problem on to someone who can fix the problem.

The second lesson a mentor should impart is that process control is a team sport. One problem that often occurs is we can get so focused on controller tuning is we lose sight of the fact that the problem may be something other than tuning. This is a real-life example of “if all you have is a hammer everything looks like a nail.” It is expected that you will look beyond tuning the controller and enlist help to solve the underlying problem which may very well be beyond your expertise.

Getting ready to tune

You have been asked to tune an existing controller. Where do you begin? Start with these four areas: Tuning logs, talk to people, don’t create surprises and avoid even bigger problems. More on each follows.

Look at the loop tuning logs

If your facility doesn’t keep loop tuning logs, I highly recommend that you should. If nothing else keep a personal set of logs for your area of responsibility. The logs can be handwritten (I started old school) or any acceptable electronic log. If your system tracks parameter changes and permits adding comments, make it a habit to add a comment whenever any tuning parameter is changed.

The purpose of a tuning log is to help you:

Track slowly developing process or instrument problems.
Identify cases where adaptive tuning might be necessary.
Explain why a controller is tuned a specific way.
Allow restoring old settings or in the case of heuristics allow you to split the difference if you went too far the last time.

Figure 1: An example loop-tuning log. Courtesy: Ed Bullerdiek, retired control engineer

Figure 1 is an example of a loop tuning log for the Unobtainium Unit feed flow controller. This is done in Microsoft Excel and kept in a location accessible by the entire control group. Entries are chronological with the newest on top. The log should include all commonly used control algorithm parameters for your system. To speed review, omit entries that haven’t changed.

A review of the entries tell us:

1/17/2005: This is a new process unit and the flow controller was started up with default flow controller tuning. There are default tuning constants that work reasonably well for most flow and level controllers. It is not unusual to have a flow controller require no adjustment from the default constants.

4/12/2010: The unit is expanded. The original tuning became too aggressive; the controller gain was adjusted. The setpoint clamp was raised for the new charge rate.

5/23/2012: The control valve started sticking. Several tuning changes were made to work around the limit cycle that developed starting with reducing the controller gain. A gap was added with an even lower gain. On this system the gain inside the gap is the controller gain multiplied by the gap gain, or in this case 0.25 * 0.25 = 0.0625. The gap limit will be set outside the limit cycle’s effect on the process variable. A little derivative was added to accelerate the controller output through the control valve backlash limit. Finally, an output rate limit was added to help controller stability. Nearly every trick was deployed to keep this controller working (poorly) until the valve could be fixed. The note is short but covers the most important point – a work order to fix the valve was written.

6/12/2012: The control valve has been fixed, and the original tuning restored.

Note that three different people worked on this controller. CKR did restore the loop tuning after the control valve was fixed, but if he weren’t available, anyone could have done this without having to spend the time to retune the controller.

While it hasn’t been done in this case, you could explain in the notes that a controller (call it 00TC0012) was tuned (for example) very slowly because it is a slow optimization controller. It is tuned this way to avoid interaction with controller 00TC0011, which presumably is tuned quickly because it is the economically more important controller. The note should prevent someone from speeding up the controller in the future, which could happen if someone doesn’t understand why the controller is tuned to be slow. Or restore the original tuning constants after they realize the new faster tuning constants don’t work.

It can take a few years before the true value of loop tuning logs become obvious. As the problem controllers and processes become apparent, you can use this information to drive improvement efforts such as advanced controls or even process improvements.

Talk to people about process control problems

One of the problems with loop tuning requests is that someone has already decided what the problem is, and that the fix must be tuning the controller. They might be right, but you should check out their thinking. Why do they believe loop tuning will solve the problem?

The answers might be:

“We changed the process.” In this case loop tuning is probably required. If you are a member of an operating team, you should have known that this was coming. But it’s not unusual that you were the unlucky soul with the duty phone when the change got completed. A call to the responsible person in your group may be in order. They can brief you on what needs to be tuned.
“We noticed something strange started happening.” Loop tuning requests are a call for help, and, for better or worse, they trust you. This will very likely be bigger than simple loop tuning. Loop tuning may provide a stopgap until the larger problem can be solved.
“This one controller started misbehaving; everything else is fine.” The issue is most likely a valve problem, followed by an instrument problem.

While you are talking, walk through the trends. They should be able to point out when the problem started and what they think the problem is. This is your opportunity to clarify what the expectations are and to use your new controller performance problem identification skills to try to narrow down the problem. This is also a chance to save yourself some work. It may quickly become apparent that this is a problem that controller tuning cannot fix or even work around. Regardless, at this point you should be able to form an opinion on what the likely problem is and, if you have questions, get others involved.

Loop-tuning etiquette: No surprises

In most facilities you can touch the control system from your desk, including tuning controllers. There is an awful temptation to just jump in and start changing numbers.

Please don’t.

Operators do not like surprises. An operator does not want his job to be any harder than it has to be. An operator needs to know what you are doing and why. The operator also needs to know that he can stop you if anything comes up. Remember that the operator is responsible for the process, not you. If anything happens, he will be held accountable.

This is a form of professional self-defense. If you ever want to be able to tune a loop again when this operator is working, you need to make him feel comfortable that he has all the information he needs, and that he is a partner in the process, even if only a passive participant.

Working with operators is easier if they believe you will make their life better. As a new control professional, you will be under a spotlight. You do not have a track record yet, and they have likely already experienced a new engineer coming in and making their life difficult. These steps should always be part of how you do business, but will be especially important when you are new.

Visit – don’t call. Making the extra effort to show up will impress them that you are serious. If you have many successful interactions with an operator, and you have developed a relationship you may be able to get away with a phone call (although you should never make this a common practice). Of course, if he calls you for help, there is no need to visit.
“Is now a good time?” Be aware that an operator may have a problem on his hands or be in the middle of a procedure that requires all his attention. Furthermore, you do not want to try to tune a controller if the process is upset. If the process is upset, and you are already in the control room you should sit back and watch the operator work. Focus on things that may be impeding his work with an eye towards fixing these later. Watching will not be time wasted.
“I want to do this because …” Unless the operator requested that you look at a controller, he will be properly skeptical about your visit. Give him the background; perhaps he will have some insight that will help you out.
“This will help you because…” Operators want their job to be easier. If tuning this control loop will help, by all means say how you expect this will help.
“I expect this to take X minutes/hours.” He may not be busy now, but he knows that in 2 hours he will be. If you expect this will take more than 2 hours, you might not want to get started. And he will want to know when you expect to be out of his hair.
“May I change the controller mode?” If you have a lot of credibility the operator will probably let you do what you like. But if you are new, he may want to make the actual moves. This is about building trust. Or you may be in a facility where work rules limit what you are permitted to do.
“May I change the controller output or setpoint?” This is the same as asking about changing controller mode.
“How big of a change may I make?” When tuning, bigger steps give us clearer results. But bigger steps run a bigger risk of upsetting the process. Give the operator the chance to tell you how big a step you can take and what hazards you need to watch out for. Most controllers will not have a huge effect on the process, but making a mistake with some can cause real problems.
Promise to let them know when you are done. If you are working from your office, it is all too easy to forget to call the operator. Please don’t leave them hanging.

Here’s a final piece of advice. Make a point of visiting the operators once in a while with nothing on your agenda. Talk about sports, hunting, cars or whatever they are interested in. You should ask if they have any questions about the controls. This doesn’t need to take long, but having some sort of personal connection, a sense of trust, will help you and him when something needs to get done.

Tips to avoid creating a bigger problem

Controller tuning requires us to disturb the process during the testing and validation process. Most control loops do not have a huge impact on the overall process. We can afford to make brief mistakes. However, mistakes on some controllers can have wide ranging impacts. The worst one I heard of involved shutting down a utility boiler on low drum level. They were not able to get an immediate restart, and the upset resulted in reduced charge rates through much of the refinery. The report reached the executive vice president’s notice. This is not the kind of attention you want. My involvement was after the fact and, yes, I am trying to focus your attention.

One of our questions for the operator was “How big a step may I take?” This is part of a bigger conversation about the risks involved in pushing the process around while we are testing. Before testing we should know, whether through our own research or by talking to the operators, where we shouldn’t go. Then, depending on the tuning method we should take appropriate steps to avoid going there.

This is another aspect of professional self-defense. We will make mistakes during loop tuning. This is inevitable as we are venturing into the great unknown. But there are things we can do to prevent big mistakes depending on the loop tuning method we use.

The open-loop tuning method is generally safe. You control the controller output step size and direction, which means as long as you know where the no go zone is you can step away from it. If you must step toward a no-go zone then you should limit step size certainly per the operator’s recommendation and perhaps less if there are any questions.

Closed-loop tuning is very risky and generally not recommended. However, should you intend to perform a closed-loop control test you should set controller output clamps before starting testing. The risk is that as you increase controller gain in the search for the ultimate gain you may go too far. If this should happen the controller will “go there,” perhaps faster than you can stop it. Output clamps will limit the process swing to something tolerable assuming you haven’t set the limits too wide. (I almost tripped a gas plant boiler on low fuel gas pressure on my very first distributed control system installation project. That’s when I learned to always set output clamps and to avoid closed loop tuning if at all possible.)

Heuristic tuning involves stepping the controller setpoint in auto and looking for the pattern of the controller response. There is no hazard if you are reducing controller gain or slowing the controller integral. If, however, you are increasing controller gain and/or speeding up the controller integral there is a small risk of going unstable. The risk is very small if you follow the rules, but it isn’t zero.

Finally, when you do the final tuning test you should consider setting a controller output clamp if there is a hazard. While theoretically whatever tuning constants you end up with should be safe, a bad control valve can considerably affect tuning results, especially with open-loop tests.

What problems should I look for while I am tuning?

You have looked at the logs and the trends, spoken to whomever requested the tuning check, have the operator’s permission and have set up any required safeguards. There will be clues to what problems need to be solved. But what problems are we likely to run into and how do we identify them? In order of likelihood, they are:

Valve problems
Control loop interaction
Unrealistic expectations
Instrument problems
Process problems
Bad control design

Is it a bad valve?

Poor valve performance is the most common cause of control-loop performance problems that do not involve tuning.

You should be able to identify the limit cycle that valve stick-slip action causes based on the process trends:

The process variable of a flow controller will draw a square wave.
The process variable of a level controller will draw a saw tooth wave.
The process variable of a pressure or temperature controller will draw a shark fin wave.

If manual step tests of the valve results in different process variable responses, then it is likely the valve is sticking.

See PID spotlight part 18 for a thorough discussion of control valve performance issues and how you might address them.

Is it controller interaction, or why is this controller swinging?

If the controller you’ve been asked to tune is swinging you need to find out why it is swinging. Ask the operator to put the controller in manual. One of two things will happen:

If the controller stops swinging you have a tuning problem, or the valve is bad.
If the controller continues to swing another controller is driving this loop. You need to find and fix that poorly tuned controller.

There is a third possibility. You may tune the controller and, no matter what you do, the controller still swings when you put it back in auto. In this case you likely have another controller interacting with this controller. Control-loop interaction is prone to show up where there are internal recycles in the process. Common places where interaction is found include:

Distillation: Distillation recycles vapor to liquid and back again.
Heat exchanger networks: Particularly bad are feed versus product heat exchange. Distillation feed by bottoms product can be very difficult to manage.
Flow headers: Backpressure caused by the closing of one valve can cause flow to other passes to rise, causing those valves to close. Breaking the cycling that can occur requires special tuning methods. This is a case where the recycle is contained within the flow line in the form of pressure drop, which affects flow, which affects pressure drop, which… You get the picture.
Controllers with similar dynamics in series: A common example includes pressure and flow controllers in series, for example in balanced draft heaters. Special tuning methods are required here also.

Occasionally control loop interaction must be handled by feedforward schemes or adaptive tuning.

If you suspect controller interaction you can attempt to break the interaction by changing tuning. Slow control loops do not visibly affect fast process control loops. Fast loops can correct any disturbance caused by a slow loop before it becomes a problem. The rule of thumb is a fast loop will not be affected by slow loops that are three times slower, measured by deadtime plus lag. However, if you choose to go this route the slow controller will not manage disturbances caused by the fast controller, therefore the slow loop needs to be one where being off setpoint for possibly an extended amount of time can be tolerated.

Are there unrealistic loop-tuning expectations?

We are often confronted with a request to speed up a controller. Unfortunately, controller speed is limited by the laws of physics. It is a little-known fact that a controller cannot begin to correct a disturbance until one-half the natural period has passed. The natural period is approximately four times the deadtime. This can severely limit what we can do with very slow processes.

Of course, talking about the natural period will not likely work with operators or managers. There are a couple of strategies I’ve tried (with varied success):

Remind them of the size of the equipment – or take them on a tour if they are if they are unfamiliar with the equipment. This can work well with young engineers, and it is never a mistake to familiarize yourself with the equipment.
Tell them that moving this process is like walking an elephant. Once an elephant gets off course, it requires a lot of coaxing to get it back on path. It can be done, but it takes more than a little time. This is somewhat effective with operators who are already familiar with the equipment.

Have you found an instrument problem?

Most instrument problems result in immediate failure. You won’t be called about these.

However, there are a couple of problems that you will routinely see that occur slowly and are easy to miss:

Instrument drift
Partially plugged taps

Instrument drift can result in, for example, process limits violations. Depending on the limit the process can behave very differently. For example, if a controller is pushing distillation tower flooding limits, instrument drift can push the tower into flood, in which case the distillation tower will start to swing wildly. You may be called to tune the loop because of the swing. Understanding how the process reacts if a limit is crossed will save you many hours trying to fix a “tuning” problem that has nothing to do with tuning. This problem usually shows up suddenly when the drift drives the process into a new operating regime.

Partially plugged instrument taps will change the apparent process dynamics (the real dynamics haven’t changed). Plugged taps show up as slower process response, which will result in controller swinging. You will be asked to slow the controller down. Be aware of situations where process dynamics shouldn’t change (for example – levels). If significant tuning changes are required to maintain stability, or, in the worst case, you cannot establish stability no matter what tuning you put in, look for plugged taps. This can be a situation that creeps up on you – keeping a tuning log can help.

Finally certain types of instruments can have specific types of failures that are not obviously instrument failures. These are too numerous to describe here, but if you see something that doesn’t make sense, ask the old heads what they think.

Have you found a process problem?

The problem that young control professionals often have is tunnel vision. This can even affect older professionals. (I am sometimes guilty, too.)

To repeat, a controller tuning request is a call for help. In a well-tuned facility, most loop tuning requests are not because you have a loop tuning problem. It is usually something deeper. Therefore, the best thing you can do is keep your eyes open for problems that could affect tuning no matter the source. Refineries prefer to place process engineers in the control group specifically because they expect these engineers to bring their process knowledge to bear.

Sudden changes

If according to the loop tuning logs a controller has run well for years and then suddenly it simply stops working, look for a process problem. For example, early in my career I was asked why the composition controls on a preflash tower were working poorly. None of the data looked normal, which led to the question: “Did something happen?” The operator informed me that there was an upset where water blew through the tower from a desalter upset. I called for help, the tower was x-rayed which revealed that 3 of 11 trays had collapsed into the bottom of the tower. The problem was explained, and it was not a tuning problem. (This was more luck than brilliance.)

Slow changes

If you find you are making steady changes in controller tuning in one direction, you should suspect a slow developing process problem. Early in my career when I didn’t know better, I was changing the tuning of a temperature controller on a heat exchanger train on a regular basis. This continued for a couple of years until the process engineer did a temperature survey. This was followed by cleaning the heat exchangers because the loss of heat recovery was costing a lot of money. If I had understood the importance of the steady loop tuning trend, I could have alerted the process engineer to the problem earlier. The data was all there in the loop tuning logs; I didn’t understand the import.

Nonlinearities

Most processes are nonlinear. However they tend to get operated in a relatively narrow range, which means, we can get away with one set of controller tuning constants. However, if the process is run at different rates routinely, you may find yourself changing tuning based on rates (or feedstocks, or …). If you find you are frequently changing tuning constants to follow changing feed rates (or other) consider adaptive tuning.

Equipment limitations

Figure 2 is an example from a late career project where a blower supplying air to a waste water treatment plant aeration basin. The blower was designed with limited discharge pressure above the minimum necessary to aerate the basin. This was obvious based on a review of the blower curves, which means that if the inlet filters are even a little bit plugged the blower runs out of capacity. Every spring when cottonwood season visits Detroit there would be a call about why the controller stopped working. The response: “Did you check the filters?”

Is it bad control design?

It’s very rare to find a controller that simply doesn’t work. These are usually found during initial commissioning. If you should find one, usually by open-loop step testing, please help out your peers. Leave notes in the loop tuning log and in the controller logic, if possible. Lock the controller in manual if possible and start a management of change process to convert this to an indicator.

You may be tempted to avoid this work. Please do not. Someday there will be an effort in your facility to put all the controllers in their “proper” mode. This means that someone, given the short memory span of organizations, will have to waste time rediscovering what you know.

Closing out a loop-tuning session

You found out that the controller really did need tuning to minimize process disturbances, and you have finished tuning.

Because this is a unit charge controller, you probably set output clamps either during tuning if you used heuristics or during the final test if you did an open-loop test. Make sure that they are released.

You have told the operator that you are done and that based on your final test things should be better. The induced disturbance test suggests the controller will adequately reject a disturbance. This is not truly definitive, so you tell the operator that you will check back tomorrow to see if any disturbances have come through.

Presumably something has happened that is causing upsets. You probably don’t know what that could be, but suspect that it has something to do with the tank farm. Since the tank farm is not your unit you don’t feel comfortable looking into it. Instead, you will refer this to someone who is responsible for the tank farm.

Figure 3: Your completed loop-tuning log entry. Courtesy: Ed Bullerdiek, retired control engineer

Finally, you will fill out the loop tuning log. The controller gain has been increased to convert the tuning to disturbance rejection from setpoint tracking. The integral has been slowed to compensate for the increased gain (maintain same effective integral). A setpoint rate limit of 100 BPD/minute has been added to smooth transition when the setpoint is changed (this probably should have always been there, but it became necessary to prevent feedrate oscillations and the downstream effects this creates when the setpoint is changed).

You are not truly done even now. Tomorrow you will have to check back to see if what you have done has worked. But for today you are done.

Ed Bullerdiek is a retired control engineer with 37 years of process control experience in petroleum refining and oil production. Send comments and questions to [email protected]. Edited by Mark T. Hoske, editor-in-chief, Control Engineering, WTWH Media, [email protected].

CONSIDER THIS

How do you safely tune a PID controller? Will tuning fix what ails the controller, or are there other things you should be looking for while you are tuning?

Aug. 1 RCEP webcast is available for one year: How to automate series: The mechanics of loop tuning

PID series from Ed Bullerdiek, retired control engineer

Part 1: Three reasons to tune control loops: Safety, profit, energy efficiency

PID spotlight, part 2: Know these 13 terms, interactions

PID spotlight, part 3: How to select one of four process responses

PID spotlight, part 4: How to balance PID control for a self-limiting process

PID spotlight, part 5: What does good and bad controller tuning look like?

PID spotlight, part 6: Deadtime? How to boost controller performance anyway

PID spotlight, part 7: Open-loop tuning of a self-limiting process

PID spotlight, part 8: Closed-loop tuning for self-limiting processes

PID spotlight, part 9: Heuristic tuning for a self-limiting process (part A on heuristic tuning)

PID spotlight, part 10: Heuristic tuning in a self-limiting process