I have received some comments from Saul Mtakula, a control engineer originally from Zimbabwe but now residing in Canada, about one of my Case History articles, No. 126, published in 2012 under the heading of “Crazy Control Strategies”. He raises some 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 part of that Case History which refers:
Crazy level control cascade system
The outlet from a vessel feeds into another tank, with the level in this controlled by the system shown in Figure 1. The output from the tank feeds into four parallel streams, which go to other units in the plant. The flows will change under the dictates of the level controller tuned for ‘tight’ level control, i.e. the level kept at the desired setpoint as closely as possible.
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 feeds to the setpoint of the flow controllers that individually control the flow 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 other flow controllers. This is crazy. Firstly, there is no point in complicating things by 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 the other flow controllers. Secondly, the primary and secondary flow loops all run 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 wants 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 presently reprogramming the control system to drop the unnecessary flow controller.
Email 1 from Saul
Hi Mike,
I am from Zimbabwe 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’ Case History 126, in particular the level cascading onto a flow, which further cascades onto the four slaves, I would argue this is not that crazy after all. To make it work properly the flow loop just below the level must have super fast tuning. Sending the level output directly to the four slave flows means when some of them are not in service the process gain changes. 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 a boiler trips an equivalent of the slave flow would quickly find 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.
Thanks,
Saul.
Reply 1 to Saul
Hi Saul,
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 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:
• 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 fact, the total response time to setpoint changes is 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 only slightly, by loop gain changes.
• The most effective strategy to deal with the problem of changes in master loop gain 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.
Kind regards,
Mike.
Email 2 from Saul
Hi Mike
I saw your comments, which I mostly agree with, but here is my rejoinder.
First, with respect 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 problem. This usually would be sufficient for a tank, especially if used in some sort of surge type control.
However, there is a second problem. Let’s say you have four 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 manual and slam the valve shut it would make sense to drive the remaining three flows to 100% of their SP’s 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 three slaves at 100% right away with no dynamics. This is why people use the contentious intermediate controller plus very fast tuning: the normal five times slower rule does not necessarily have to apply for the loop.
However, let’s say the final flow loops are tuned for 10 seconds time constant. If the intermediate controller were 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 overkill for a tank, since the level can deviate from setpoint while the controller recovers. For plant master controlling header pressure there is less tolerance for pressure drops; if the fourth 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 four slaves in CAS if the level output went up by 10% the total would go up by 40% allocated 10% across four, whereas with three slaves the total would be allocated 13.3% across three without the main controller “caring”. It is akin to a flow loop linearising a non-linear valve wrt to a level master.
This has been a good conversation.
Regards,
Saul.
Reply 2 to Saul
Hi Saul,
Further to my previous reply to your first comments, I would like to make the following points:
1. Integrating processes are indeed very susceptible to cycling. However, the two most common causes for cycling are:
• Hysteresis in the control valve with P+I tuning will always result in a continuous cycle.
• Incorrect tuning, which is generally due to very few people understanding how to tune an 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 general statement, if you use P only control without an 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 do not 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. For the vast majority of flow processes with process gains of around unity, and which have good pneumatically actuated control valves, pole cancellation tuning generally comes up with very low gains (much less than unity) and very fast integrals in the region of just a few seconds (typically one or two 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 had 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 master pressure control for a boiler. In the case of a very slow primary like the level I am talking about, tune the level controller with relatively 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 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 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, and then if one or more of the flow loops shut off, the output of the master controller immediately increases 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.
Michael Brown is a specialist in control loop optimisation with many years of experience in process control instrumentation. His main activities are consulting, and teaching practical control loop analysis and optimisation. He gives training courses which can be held in clients’ plants, where students can have the added benefit of practising on live loops. His work takes him to plants all over South Africa and also to other countries. He can be contacted at Michael Brown Control Engineering cc, +27 (0)82 440 7790, [email protected], www.controlloop.co.za
| Email: | [email protected] |
| www: | www.controlloop.co.za |
| Articles: | More information and articles about Michael Brown Control Engineering |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version