Some History of Loop Control, and What it Teaches, Part 2
#1
As discussed earlier, an intuitive understanding of steering ships and heating frying pans can aid understanding of computerized control loops. That intuitive grasp tends to come unhinged when a control system is disturbed and falls out of regulation. I'll explain.

My mentor, in explaining the new solid state “operational amplifiers” back in the 1960's, said to imagine that an operator was working the amplifier. He would monitor two inputs, plus and minus, and adjust one output. If the plus input was larger he would do all he could to increase the output. If the minus input was larger, he would do all he could to decrease it. If you think of an op amp as an agent following a simple set of rules, that will help in understanding circuit behavior.
 
Like that operator, put yourself in the loop, looking at inputs and adjusting outputs. Take the simple case of the frying pan temperature described in part one. You watch the temperature, as measured at the burner, keeping in mind the desired temperature, and turn the power up and down to match the set point. Sounds easy, but complicating the situation is that the temperature sensor is in the stove, not in the pan itself. That adds delay, the heavier the pan, the more delay. If the pan had no thermal mass, it would immediately heat when the power went up, and would immediately cool when it went down. But the system does have thermal mass, so the control difficulty stems from the delayed response. You, the operator, determine the pan is too cool, so you turn up the heat. Nothing happens right away, so you turn it up more. Still too cool. Before the pan gets to the set point, you may have turned the burner all the way up. The pan temperature sails right past the desired heat and keeps on getting hotter. So, you turn down the heat more and more until the burner is off. We have here a classic oscillating control loop.

My mentor often quoted the engineer's variation on Murphy's Law - all amplifiers will oscillate and all oscillators will amplify. But that is another story. The question here is what you do, as the operative agent, in the burner control loop in order to stabilize the temperature? Intuitively what you do is decide to make smaller adjustments. That helps limit the oscillation. We call that property the gain of an amplifier or control system. A proportional control system makes adjustments in proportion to the magnitude of the difference between the present  state and the desired state. Too much gain tends to encourage oscillation. If you make really tiny adjustments, it will take a very long time to get the pan to the desired temperature. But if you make enough of those smaller adjustments quickly enough, you will still end up alternating between one extreme and the other instead of finding the correct middle setting. The gain is only part of the picture. Simply reducing the gain while using proportional control is not a complete solution.

There is also the issue of time. Like the ships wheel, we need to slow down the response. In an operational amplifier circuit, you slow down response by adding filter capacitance. In a computer-in-the-loop system, you average. In addition to the proportional control, you can also pay attention to the average temperature. If the average is too high, you aim a little lower, and vice versa. Simple enough, but over what length of time does your average apply? The longer the period, the more stable the average, but also, the longer the system will take to stabilize if it is disturbed. What happens to the average when you change the set point? If you are aiming for the wrong point because of heavy averaging, that integral term can actually cause oscillation instead of curing it. The average is called an integral term in the language of control. If you pick a moderate time period for avergaing, that helps the system settle to the right place without slowing it down too badly or inducing slow oscillation.

In the helmsman's case, the wake might be perfectly straight, but the ship could still be slightly off course. The integral term could serve to correct the direction, but that average term would make only small corrections, and only slowly, so as not to disturb that nice staright wake.

Back to the frying pan, you can now get the temperature to the right place, and limit oscillations, but a disturbance still causes an instability that takes a long while to settle out. That instability looks like undershoot and/or overshoot. To limit those effects, you need to pay attention to rate of change, which, like the integral, is another time-related term. The rate of change is described as a differential term. If the temperature is too low, but is rapidly approaching the desired temperature, you could turn down the heat in advance of reaching the set point. That will limit overshoot. The idea is to approach the setpoint slowly enough to prevent the overshoot, but not so slowly that it takes a very long time to get there. This aspect of control turns out to be the hardest to get right, because the timing of adjustments is delayed by the integral and sped up by the differential. The operator can loose his bearings, like a helmsman in a fog.

Once you put all these rules in place, in particular the differential term, it becomes more likely to loose your orientation. Let's say you have turned up the burner because the temperature was too low, then turned it down because the temperature was rapidly approaching the set point. You still want the temperature to rise, but you turned the burner down, hmm. Now say the temperature is still too low but rising, so do you turn it up assuming the overshoot correction was too much, or do you turn it down assuming the rise will continue? The sensible thing to do when you don't know know whether your setting is too high or too low is to do nothing, because if you guess wrong, you are starting down the path to an ever increasing oscillation. It is easier for you, as an imagined operator, to know when you are lost than it is for a computer following a set of rules to conclude that it isn't sure what to do. You don't want your computer-in-the-loop system to end up on the virtual rocks.

Allow me to inteject a personal anecdote at this point to illustrate. I am driving on Interstate 15 in rural Idaho during a snow storm. Nobody else is on the road, and the snow is accumulating on the road surface. The safe speed has fallen to 40 MPH, or so it seems. The road takes a very minor turn to the left. I turn the wheel a bit to follow, but soon I notice that the car is still going straight. It is only my eyes that tell me. There is no change in the hiss of the tires or change in the feel of the steering wheel. The road is wide and empty, and my progress toward the shoulder is barely perceptable. It occurs to me that there is no one else anywhere near, and I that I am unlikely to be able to get the car back up on the road without help. So, I begin to make very small corrections at the wheel, really tiny adjustments. No change. The scene progresses in super-slow motion. Maybe 15 seconds have gone by already. I made the intentional decision to slow down my corrections even further, since I still had plenty of time, though the car was nearing the shoulder. I finally found the exact spot to hold the wheel where the car was rolling, not skidding. Then, I could very gently steer back toward the center of the lane. By that time I had slowed down some, and could safely keep the car on the road at the reduced speed. In context, the point is that I, the operator, did not know which way to turn the wheel in order to regain control. If I had tried larger corrections, in either direction, it is unlikely that I could have found just the right wheel position to regain control before the thicker snow on the shoulder sucked the car off the road. The hard part is knowing when to do nothing, or nearly nothing.

All of the above is towards an intuitive understanding of control loops, in general, and PID (Proportional, Integral, Differential) control more particularly. There will be situations where the control decisions are not apparent, even given plenty of time to consider. Your controls need to be able to recover from those tricky situations, or else you will find yourself in the metaphorical ditch. We find there are better ways to manage tricky control loops than PID. We call the principle Predictive Energy Balancing. PEB was developed for regulating power converters, but it has much more general applicability. Stay tuned for more on the subject, another day.
 

Tom Lawson
December 2021
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)