Last updated 23 Aug 2018
Control Loop Case History 129
INCORRECT LEVEL CONTROL STRATEGIES CAUSING INSTABILITY
I was recently asked to sort out some control problems in a chemical plant. One of the major problems of great concern was the control of an important process where it was desired to control a flow of liquid, split into 4 streams, which were passing through a furnace to heat the liquid. It was desired to keep the flows as constant as possible, and if they did change then the changes should be kept as slow as possible. The reason for this will be explained later. The system is shown in Figure 1.
The liquid is pumped out of a tank. The level in this is not of high importance except that it must not go too high or too low to so as to prevent overflow of the tank, or cavitation of the pump. To achieve this a level controller is employed. The level controller is then cascaded to a flow controller, which in turn is cascaded to the four controllers in the individual streams in parallel.
If the flows through the furnace change then the furnace temperature is affected, and it is vital that this temperature be kept at setpoint as closely as possible. The process specifications actually call for the temperature to be kept constant within a ±½°C range, which is extremely difficult to achieve. The big problem is that the temperature is a very slow process and as discussed in previous articles, slow processes can only be controlled slowly.
Therefore if the liquid flows changed quickly the temperature control would not be able to catch the resultant temperature swing.
When the control system was being implemented the system designer had correctly recognised that the level control could be very slow as long as the high and low limits were not exceeded, so he had implemented a non-linear level control system using a controller employing an error squared algorithm.
This algorithm as usually included as a standard option in most DCS control systems. (It is very seldom offered as standard on PLC's and usually has to be specially programmed.) It basically works by squaring the error as the PV moves away from setpoint, so in cases like this, the setpoint is usually set at 50% and the control action is extremely slow with small errors but increases in a 'squared' manner as the error increases. This is supposed to result in very little control action near the 50% setpoint level, and the response gets faster and faster as the level move away from setpoint.
Unfortunately the system didn't work as planned. The Operators would get the processes operating at desired value and when the plant was running at steady state they put the controllers into automatic. All was well as long as the steady state conditions lasted, which in this type of plant could be for literally months, but as soon as a load disturbance occurred on any of the processes in the system, the level and associated flow controls started a slow cycle that could go on indefinitely, and the Operators had to intervene, and take over the controls in manual.
The Problems with the Control Strategies
There are two strong reasons why instability could occur. The first is due to the double cascade system. A double cascade system was fully discussed in Case History 126, entitled "Crazy Control Strategies" which was published in July 2012. The system was very similar in fact to the one discussed here, which is not surprising as they both in the same plant.
The article explained how essential it is that a cascade secondary process must be very much faster than the primary process, or interaction can occur and cycling may well result. The single flow controller cascaded from the output of the level may therefore cause interaction with the four flow loops cascaded from its output. This flow controller is in fact completely superfluous, and should be removed. The output from the level controller can then be fed directly in parallel to the setpoints of the four flow controllers.
The second reason for instability is more complex. The error squared level control could also cause cycling to occur if applied incorrectly.
Level control is a subject that has been discussed in great detail in previous articles. Control of level can be effected in one of two ways depending on the process requirements:
1. The more common requirement is to keep level constant under changing load conditions or occasionally to follow setpoint changes. This requires a fast response, and the tuning must generally be as fast as possible particularly if the vessel has a long retention time. Therefore one usually puts relatively high proportional gains into the controllers, which can cause rapid valve movements when changes occur, particularly if they are step changes in setpoint. This results in rapid and possibly large changes in the flow through the valve, and one must always bear in mind this can affect downstream processes. This type of control would be completely unacceptable in the current case.
2. The second type of level control is where the level is in itself relatively unimportant, and as in this case, the only reason that level control is being employed, is to prevent it going too low or too high. A completely different control philosophy needs to be applied here. It is usually referred to as surge level control. In my article Loop Signature LS1-29, it was suggested that for several reasons normal types of controller should not be used, and it was far better to merely insert a simple 'curve shaping block' between the transmitter and the valve to control the valve in such a manner that very little and slow movements of the valve occur over most of the tank range, but that the valve will start moving faster but smoothly near the high and low limits. a typical curve that could be inserted in the block is shown in Figure 2.
What is wrong with the use of the error squared controller that had been implemented? The problem with such a controller is that people do not know how to apply them properly. When using this form of control on integrating processes, such as levels, the control will work. if the squared error is only applied to the P term and integral is not used. If it is applied to both the P & I terms then instability can easily result. The reasons behind this are fairly complex, and are beyond the scope of this article.