What’s the problem with overshoot?

Dear Control Engineering: I was looking at Back to Basics in the August issue about closed loop control. What is the main concern about overshoot? Why is it a problem, and can’t a controller prevent it?

An ideal controller should be able to move a process variable quickly to the desired setpoint without shooting past. Sometimes controllers will push the variable aggressively toward the setpoint knowing that it may go past, or overshoot the desired value and have to turn around and come back. In many applications, this isn’t a problem. For example, let’s say you’re trying to control flow. The sensor is a flowmeter and the controller is a valve. Assuming everything is sized appropriately, the valve should be able to accommodate the desired flow easily, so it’s no big deal if it goes a little above or below the setpoint because it can easily reverse its effort.

But, let’s say you’re trying to control the temperature of a large tank of liquid by modulating the amount of natural gas to a burner. If the liquid is too cold and you’re trying to bring the temperature up quickly, the controller may turn the gas all the way up. However, if you overshoot the setpoint, the controller can do nothing to make the liquid cooler. There is no reverse effort available. Eventually some of the heat will dissipate and some might be carried away by a cooler feedstock coming into the tank, but there may be no counter control effort beyond turning the burner off.

To complicate things further, let’s say the tank is filled with vanilla pudding and overheating will cause it to burn. You want it to boil, but not get too hot. In those situations, the controller has to be programmed in a way that it will not pass the desired point or the product could be ruined.

Controllers can be programmed to avoid overshoot, but this is usually at the expense of aggressiveness. It has to slow the control effort more and more as it approaches the setpoint, which drags out the time required to hit the desired value.