Rotameters(cone +float) A Very Bad Idea For Use In Closed Loops

What's with the additional control valve? Could it be that downstream turbulence from this valve is making the rotameter jump around a lot? Why else is it giving unstable 4-20ma readings?

Thanks for your responses.

The valve is downstream to the Flow-meter. Problem is compounded by the flow-meter's reaction to the valve as well. For any slight reduction in valve opening, the float moves down disproportionately and the valve in turn now reacts to this float's movement by opening rapidly!. The float + valve action & reaction dynamic is peculiar only to rotameters. You've to see it to believe it. The rotameter we were using had a range of 1000 to 10,000 LPH. For this the float's movement was about 65mm. Thus you see even 1mm movement of the float has an implication of 140 LPH.

With the background as above, we've to stabilise the float's movement by averaging. But then this introduces a huge lag of about 20-30 secs and when tuned, the control is at best sluggish!

Too much derivative action in the controller, perhaps?

Bad PV, bad control.

I'd never run into that (rotameter) before but thank you for the heads up.

Save money on the flow meter and lose money through poor control. Makes sense, huh?

By "averaged(sliding average)", I am guessing you mean what I would call a "Moving average".

Have you tried a first order lag filter? You don't mention what control system you are using, but you can build one in something as simple as an Allen-Bradley MicroLogix PLC.

PVf = PVf1 + (SampleInterval / (SampleInterval + LagTime)) * ( PV - PVf1)

PV = Process Variable

PVf = Filtered PV

PVf1 = Last value of PVf

By adjusting the sample interval and lag time, you might be able to filter out the large spikes, with less lag in the system.

But your best bet is going to be replacing the rotameter with a more stable flowmeter.

Thanks kw0,

I use Unity-Pro software which indeed has a lag filter function block. The output of this block is to introduce a first-order lag to the input and is used for killing spikes in signal.

Tuning was done by a heuristic autotune algorithm, which does a 2 step transient response analysis and verifies the same by evaluating the transient response to an impulse as well. In the configuration of auto-tune, there are enough guidelines for setting it up correctly. If not configured correctly you get specific errors which indicate why the auto-tune failed.

The loop's Kp, Ti. & Td values obtained by this auto-tune are very similar to what you would get without auto-tune when you maually do a Ziegler-Nichols closed-loop tuning method as well. Thus you have a no BS verification!

In the particular flow-loop we're talking about, the auto-tune yields a Ti of about 30 seconds. So change of set/point will result in the PV stabilising at close to 2 minutes. For any flow-loop this is very very sluggish. When you cascade this loop, your master loop (Say temperature-loop) has to have a time constant of at least 20 times this! So larger your slave-loop's time constant, the master-loop's time constant is correspondingly larger. Moral of this story is that lag is the enemy of control and any instruments which ask for unreasonably large lags is better not

the use of a lag filter was also attempted and the lag times introduced was similar to the averaging period. Yes Sliding average means moving average. Point is... either way to stabilise the flow-meter signal you've to filter or average it over an extended time period. Thus the loop becomes very sluggish.

I'd like to hear if at all anyone who has had a similar experience has met with any success. The reason I share my experience is to forewarn other engineers so that they make better decisions. The guy who sold us this FM (Krohne India) never told us that this meter would perform miserably in a closed loop! This unfortunately was left for me to find out. So fellas... thanks and ciao!

The whole way the question is asked, bothers me. The basic PID controller is analog. Never mind, if you produce a digitized value, in addition. That is not important, and a side issue. A meter with (magnetic or hydraulic damping)have to have a time constant of a fraction of a second to a second+. From that component alone, the regulatory loop time constant has to be a fraction of a second, normally.

Including digization in the loop is nonsense.

Let me ask a fundamental hydraulic design question......

How far away is the valve from the rotameter? Rule of thumb is 5 - 10 pipe diameters to minimize effects from turbulence and unstable flow regimes. If the valve is closer than that, flow will always be unstable at the point of measurement and no instrument can make up for that.

Try putting a valve upstream of the rotameter to make sure your system is as stable as possible.

Another alternative is to dampen the meter output so that the jumps in the meter are less noticeable.

Please,

Tell me how PID tuning is done for control valvein steps?...

Dear Hemant Bhai,

Where are you based. I am at Thane. One day you could join me at my work at some site!!!!.

Otherwise, 1.) google for "Tuning PID Loops + Ziegler & Nichols" OR

2.) Look up the help menu in your PLC programming software (PL-7, Codesys, RS Logix, Unity-Pro, PL-7, Simatic Manager) OR

3) Get the book by any common Instru. author such as William Bolton/Wolfgang Altmann

Above all, tell me what kind of loop you're trying to tune. I mean is it a flow/temp/pressure/level loop. Each needs to be handled a little differently.

There are again Automatic tuning function blocks available with many PLCs. These are easy to use.

Ciao,

Raj S. Iyer

I'm still puzzled by your setup, so please correct me if I'm wrong. If I understand the OP correctly, there is a variable orifice flow-meter sensing the flow into a downstream back-pressure control valve while at the same time attempting to control the output of the same valve. With all due respect to the OP's demonstrated knowledge, isn't this a classic case of the difficulty of tuning a feed-forward control where the process conditions have entered an unstable state; i.e., the dynamic conditions of this fluid flow is such that there is an interaction between the sensor and the sensed leading to an oscillatory condition between them. I don't know what your process fluid conditions are but here's what I see happening; the upstream flow-meter is acting as a variable orifice flow controller and presenting a variable flow to the control valve while at the same time the control valve is providing a back pressure pulse as it is being stroked, thereby affecting the flow through the rotameter. Again without knowledge of the internals of the rotameter, the settings of the controller or the type of control valve, I suspect that the problem lies not so much with the rotameter but its internal design; i.e., the float is of a different material than the strictly visual ones you normally use. It has a lighter mass and is therefore more sensitive to the downstream flow/pressure variations provided by the control valve, that coupled with how accurately the 4-20 ma transmitter follows the actual position of the float, sets up the conditions for oscillations, which can become quite strong as resonance is neared.

Solutions? This is a physical, not a tuning, problem. As others have suggested make sure that there is sufficient distance between the sensor and the controller, but as we know pressure pulsation, standing waves and water hammer can travel great distances unabated. You might try contacting your vendor and see if you can get a float made of a different material that whose inertia will put its response just outside of the area of resonance, or if conditions permit, put the sensor downstream of the control valve. Please let us know what worked for you.

Thanks RAMConsult, really thanks a lot.

For the first time, someone has correctly expressed what I was trying to say. I like the way you explicitly describe the interaction between the flow-meter and the CV and which lead to the oscillations seen.

FYI, the distance is more than 5 metres between the FM & CV. I've tried putting the flow-meter downstream of the valve. The same issue, but a lot of turbulence as well. Basically the available meter is physically unsuitable as you say. The fluids used were petroleum fractions such as light aromatics grade etc.. which are being fractionated to obtain specific BP ranges as products.

Again, the flow-signal's accuracy is Horrible!. This is very, very dependent on the temperature and density of the fluid. We'd chosen a meter calibrated for fluid with a density 0.833 kg/l at 150 degs. C. ; as in practise we would use feeds having density anything between 0.75 to 0.93. For example, the observed accuracy at a density of 0.78 was +/- 15% . Additional errors were seen when the temperature would go down to 80degs. or reach 170 degs at times!. All in all we could rely on avg. +/- 20% accuracy. Thus I'd not use a rotameter unless of course the fluid's density, temperature and viscosity were to remain constant at all times.

Our solution was to recommend the use of Vortex flow-meters made by E&H.

Thanks for your help and honest advise.

Raj S. Iyer

Now, that static aspects are well discussed, it is time to return to the basic dynamic behaviour I focused in #6, and others have touched upon. And I come from the instrumentation / control logic side.

1,. Variable orifice meters are good for visual reading, but lousy as sensors. At low flow their damping is halfway ok, but at high flow high flow they are way underdampened with a slooow settling time, before the oscillations die down to the required precision. Building control loops within spec. with such a sensor is ulcer inducing to impossible.

2,. The Time Constant and Settling Time of a sensor is a given. You cannot build a control loop any faster, than that.

Gas flowmeter VO TC=1sec ST=30sec

. Thermal transfer TC=5msec ST=20msec

The examples are rough approximations, after all I did not even bother define ST. I do not care, if the output is analog or digital for this discussion. In the first case the control valve's TC normally does not matter, in the second it most likely the control factor, with the flow settling time close second.

3,. Sliding window averaging is an open loop data collection application. It has no place whatsoever in any feedback loop. Its TC is horrendous, detailed characteristics as filter undefined. In a non-realtime operating system variable and noisy. IMHO.

4,. Delays and induced phase phase shifts exceeding the loop safety margin WILL set up designer induced oscillations.

5,. Dead bands lead to 4,.

6,. Sensors driven outside their specification can lead to 4,. at the most inopportune times. This is a hydraulic / pneumatic problem. NOT solvable past the sensor at all.

7,. Impulse example. Sensor TC=1msec, ST=1msec, output=8bits. Nice and fast, maybe sufficient resolution. Impulsive overload causes a 1sec blind output after the analog/digital conversion. What will the loop do during that time? Guess what, you better invoke Murphy's law.

A well written program is a pleasant drudgery alleviating aid. It does not replace detailed knowledge of control loops structures and behaviour. And what you do nor know about sensors, will come back to you to bite firmly in the behind. As the original question amply illustrated.

All said and done, my original question remains un-answered. That is whether am I right in saying that one must never use rotameters in PID (ie.Closed) loops.

Or... is it that someone like you with perhaps a higher level of knowledge may still be able to tune the average flow loop having a rotameter as sensor.

Since we are able to manually set the required flow with rotameters, does it not imply that there may exist some other method (such as AI based algorithms) to automatically control flow in a stable & reliable manner.

We gave you all the answers you need, not those you like. What is done with them is up to the recipient. By the way - with few exception - these are the facts of the profession. Anybody's liking is immaterial.

You can decide, to put in lifelong learning, and gradually become a fully capable, successful member. Or not, that is a choice.

What somebody might tease out of a bad setup is entirely immaterial for you at this stage. There is no learning experience in that. Bye.