Last updated 26 September 2017
CONTROL LOOP CASE HISTORY 148
DISCUSSIONS ON “CRAZY CONTROL STRATEGY”
I have received some comments from Saul Mtakula, a control engineer originally from Zimbabwe but now residing In Edmonton, Alberta, Canada, about one of my Case History articles, No. 126, which was published in 2012 under the heading of Crazy Control Strategies). He raises some really excellent questions and I thought it would make a good new Case History to publish them together with my replies. However first let us have look at the section of that Case History he was referring to:
Crazy Level Control Cascade System
The outlet from a vessel is fed into another tank. The level in this is controlled by the system shown in Figure 1. The output from the tank is fed into four parallel streams which go to other units in the plant. The flows will change in accordance with the dictates of the level controller which was tuned for ‘tight’ level control, i.e. the level was to be kept at the desired setpoint as closely as possible. (An advanced control system was also configured to keep the flows in the four streams as equal as possible. This is not shown in the figure as it is not really relevant to this discussion.)
The control strategy as implemented in the plant incorporated a master flow controller the setpoint of which came from the output of the level controller. The output of this flow controller was then fed to the setpoint of each of the individual flow controllers which individually control the flow of each of the four streams.
Once again someone had come up with a complex cascade system. The level cascades to a ‘master’ flow controller which cascades in parallel to the four individual flow controllers. This is crazy. Firstly there is no point whatsoever in complicating things putting in the ‘master’ flow controller as it would have made much more sense to send the output of the level controller directly in parallel to each of the four individual flow controllers. Secondly as discussed earlier, the primary and secondary flow loops all operate at the same speed, and unless one drastically detunes the secondary flow controllers there will be terrible interaction and almost definite cycling.
The net result of the strategy leads to poor level control, because one does want the secondary flow control loops to act quickly so they will not interact with the level loop which is of course slower.
The plant is currently reprogramming the control system to eliminate the unnecessary flow controller.
Email No 1 from Saul Mtakula
I am from Zim now resident in Canada, working in process control and enjoy reading your case histories. You have one of the best sites on the web for practical controls.
Regarding the Crazy Control Strategies Cas eHistory, in particular the level cascading onto a flow, which further cascades onto the four slaves, I would argue is not that crazy after all. To make it work properly the flow loop just below the level has to be tuned super fast. Sending the level output directly to the four slave flows means when some of them are not in service the process gains change. For a level loop, a reduction of gain to 1/4 its appropriate value can be disastrous for stability. Dukelow uses such a scheme for driving several boilers from one plant master; if one boiler trips an equivalent of the slave flow would quickly determine the appropriate output to the remaining boilers units with minimal impact on steam pressure. Of course context is everything in these things and there might be more than I could see but that is my two cents.
Reply No 1 to Saul Mtakula
Thanks for your comments on the over complex level-multiple flow cascade-system. I really appreciate people coming back with such comments. My thoughts are as follows:
1. I fully agree with you that if any of the four flow loops are out of service it will affect the process gain of the level control. However this will equally apply if you had an intermediate “master” flow loop. It would also be affected, even more so than the level process which is an integrating process with a very low process gain (long tank retention time), and these processes are very robust and extremely hard to make unstable with loop gain changes.
2. The next problem is that as mentioned in the original article, practice dictates that the master of a cascade loop should be much slower than the secondary loop to avoid instability. In the case of flow to flow cascades, it would be necessary to drastically detune (i.e. slow down) the master loop to prevent cycling. This would in turn affect the performance of the level loop, which in this case needs a control that should be as tight and as fast as possible.
3. If loop gain changes on a master loop are a problem then there are better ways of dealing with it:
a. As you said it is possible to detune the master to prevent instability if the gain increases. Typically if you tune a loop to react to setpoint changes with critical damping (largest possible gain with no overshoot), then if you increase the gain by a factor of roughly three it takes you up to slightly less than quarter wave damping. This is quite a large range, and in actual fact the total response time to setpoint changes are not that different over the range. (Please note that this remark really applies to self-regulating processes as integrating processes tuned with P+I terms will always overshoot on setpoint changes.) The disadvantage of this strategy is that the loop performance is of course affected, even if slightly, by loop gain changes.
b. The most effective strategy of dealing with the problem of master loop gain changes is to use “gain scheduling” or “adaptive tuning”. In other words you insert optimum tuning in the master controller for the particular number of secondary loops that are on line. This is a powerful technique which is not used enough to deal with differencing conditions that affect the process dynamics.
Email No 2 from Saul Mtakula
I saw your comments which I mostly agree with but here is my rejoinder. My apologies for the length of the response but I sometimes struggle make myself understood.
First in relation to changing model gain, my worry was in relation to reduction in loop gain causing instability. Integrating processes show this behaviour where too high a gain or too low a gain can be oscillatory. For self regulating processes the worry is just on the high side of the gain. I agree that gain scheduling would solve the gain problem. This usually would be sufficient for a tank, especially if it is used in some sort of surge type control.
But there is a second problem. Let’s say you have 4 flow slaves each of which is equivalent to 25% of total level output and that the tank is running steady at 75% level output with each of the slaves in CAS, at a SP equivalent to 75% of their ratings. If the operator were to put one loop in MAN and slam the valve shut it would make sense to drive the remaining 3 flows to 100% of their SPs immediately. The level would hardly budge, and the transition from 75% to 100% does not have to be slow at all. There are people who do this arithmetically and they do it very fast; 75% total is equivalent to the 3 slaves at 100% right away with no dynamics. This is why there are people who use the contentious intermediate controller under discussion with very fast tuning to do this. The normal five times slower rule does not necessarily have to apply for the loop. But lets say the final flow loops are tuned for 10 seconds time constant. The intermediate controller could be tuned for 30-50 seconds time constant and the level for a 90-250 seconds arrest time which for a large tank is not unusual, so it could still work even allowing for slower tuning. I agree the arrangement itself is a bit of overkill for a tank since the level can be allowed to deviate from setpoint while the controller recovers. For plant master controlling header pressure there is less tolerance for pressure drops; if the 4th boiler trips but the remainder have capacity, the controls should allow pickup quickly. In that case the slow tuning might not be an issue because a boiler trip does not equal immediate loss of heat.
Lastly with the intermediate controller in place the main level controller would not need gain scheduling because its output is allocated automatically across the slaves by the intermediate controller. With 4 slaves in CAS if the level output went up by 10% the total would go up by 40% allocated 10% across 4, whereas with 3 slaves the total would be allocated 13.3% across 3 without the main controller "caring". It’s akin to a flow loop linearizing a non-linear valve w.r.t to level master. I am tempted to quote Trump and say believe me here. This has been a good conversation.
Reply No 2 to Saul Mtakula
Further to your response to my previous reply to your first comments I would like to make the following further points:
1. Integrating processes are indeed very susceptible to cycling. However the two most common causes for cycling are:
a. Hysteresis in the control valve with P+I tuning will always result in a continuous cycle.
b. Incorrect tuning; which is generally due to the fact that very few people understand how to tune integrating processes. The most common mistake they make is to make the integral term too fast compared with the proportional gain. It is actually not low gain by itself that causes cycling but a bad combination of gain and integral. In fact as a very general statement, if you use P only control without the I term, then you could make the gain as small as you like, and all it will do is slow the response, but will be stable. Proportional gain is the main factor that determines speed of response in automatic. I find that in most integrating loops where tight (fast) level control is required, most people don’t use a high enough gain (they are very nervous of higher gains), and far too fast an integral. A great rule of thumb when changing the speed of control response on a well tuned linear integrating process is to vary the gain and integral in the same proportion. For example if you want a slower response then you decrease the gain and make the integral slower by the same proportion.
2. I am not sure what you consider as fast tuning for flow control, but for the vast majority of flow processes with process gains of around unity, and that have good pneumatically actuated control valves, pole cancellation tuning generally comes up with very low gains of much less than unity and very fast integrals in the region of just a few seconds (typically 1 or 2 seconds/repeat). This gives extremely robust and excellent fast response.
3. The problem of changing the overall process dynamics when one or more of the flows goes offline is not eliminated by using an intermediate “master” flow control. All that happens really is that you transfer the problem of changed dynamics from the primary controller (in this case the level controller) to the intermediate “master” flow controller, and to me this is more of a problem as flow has such fast dynamics. In the particular example I referred to in Case History 126, instability had been a problem for many years, and many people has attempted to tune the loops. However they needed very fast response and they could only get stability by slowing them all down dramatically. Once we eliminated the intermediate flow controller and tuned things correctly, there have been no more problems and the people on the plant still mention how well it has worked ever since.
4. I would agree that your concern is valid for similar schemes applied to faster primary processes like the one you quote which is boiler master pressure control. In the case of a very slow primary like the level I am talking about, the level controller is tuned with relatively very high gain which gives extremely fast and stable level control, and losing one or two of the flows would have little effect on the level. The master control would quickly ramp up its output to deal with the problem. I do however agree with you that it could cause quite bad “bumps” on pressure control type systems with fast dynamics. I still do not like the idea of using an intermediate total flow cascade controller to deal with the problem. Flow cascaded to flow is basically not a good idea, and requires very careful and slower tuning on one of the controllers in the chain to avoid instability. Very few people in most plants understand the rationale behind complex control strategies and tuning is in most cases wrong. In the few cases like this that I have come across, cycling was occurring frequently. The best solution to deal with the problem is to incorporate a simple system so that when one or more of the flow loops are shut off, the output of the master controller is immediately increased proportionally to keep the process gain of the level process constant. I assume this is what you mean when you said some people do it “mathematically”. This would certainly eliminate the problem. It is a good solution.