Flow Control On Tank Without Many Inbound Signals

SilverShotBee said:

I know I shouldn't resurrect a 7 year old thread, but I never saw these replies and it's awesome to come back and see this discussion. I know a lot more now than I did back then and completely agree with Tom. It was an impossible situation, I needed to control level and flow to achieve what they wanted and its just not possible.

Sure, I could have added some buffering / smoothing to the level, but that wasn't the goal either. The level was violent, I needed to see the changes asap. In the end, I believe they added a much larger tank (4x the size) to help balance out the input.

Anyway, really nice to find this, here's a huge belated thanks!

Click to expand...

Would you be willing to answer a few queries about the processes involved?

drbitboy said:

Would you be willing to answer a few queries about the processes involved?

Click to expand...

What do you want to know?

SilverShotBee said:

I've been trying to design a system to control the flow leaving a product tank
...


Anywhere between 7m and 9m, the setpoint of the PID does not get adjusted, allowing the flow to stay perfectly stable. If the level gets above 9m OR a "Level is rising quickly" is detected from the level instrument then the setpoint for the PID is increased by a small amount, this repeats every 30 seconds until the condition is no longer true. And the same if the tank is falling, the pumps a slowed down.
...

Click to expand...

So this could be called zeroth order Integral control. i.e. ΔI = Ki (E**0) Δt = Ki Δt, with a deadband. It's also similar to bang-bang control with 7m and 9m as the low and high trigger levels, respectively, but with variable rates beyond the trigger levels.

Modeling this in our heads, we can see that what actually happens as the level crosses the high trigger, assuming constant inlet flowrate, is that

• the level traces a parabola in time, with a negative quadratic (order 2) coefficient,
• while the controlled outlet flowrate goes from [inlet flowrate - Δ] as the level crosses the high trigger going up,
• to [inlet flowrate + Δ] as the level crosses the high trigger going down,
• once the level is back between the triggers, the level continues to drop (at Δ/CSA m/s) to the low trigger where the process repeats, but with opposite sign:
  • level crosses low trigger going down with outlet flowrate = [inlet flowrate + Δ],
  • level traces parabola with positive quadratic coeff.,
  • level crosses low trigger going up with outlet flowrate = [inlet flowrate - Δ]

And then the whole process starts over again.

One trick would be, for each level excursion above or below the deadband (triggers), to count the number of increments added (or subtracted) to the outlet flowrate PID setpoint, and then give half of them back as the level returns to the deadband, because that will set the outlet flowrate in the ballpark of the inlet flowrate.

SilverShotBee said:

What do you want to know?

Click to expand...

oh! oh! you came back! i thought I was going to have to wait another seven years ...

I'll take that as a yes.

1. What was the cross-sectional area of the tank (or its radius or diameter)? I would guess it was in the 10-25m diameter range?
2. How quickly did the inlet flowrate change?
   1. if it drops from 2kl/s to 1.05kl/s, or vice versa, how long would that take
   2. what was the biggest expected single change in flowrate?
      1. Was it all of the 950kl/s (between the min and max)
   3. if the 500kl/s diversion occurs
      1. how long would that take?
      2. how long would it last?
      3. how often would it occur
         1. you said every few hours, but if that happened once, would it be likely to end and start again more frequently, say every 5-10 minutes, after that once for a bit?
      4. when would it occur?
         1. E.g. only when inlet flowrate was at a max (2kl/s)?
         2. or could it happen when inlet flowrate was at a min (1.05kl/s)?
3. What were the actual constraints, qualitative or quantitative, on variation of flowrate out of the tank?
   1. How "constant" did it have to be?
      1. Presumable Would @PeterN's continuous filtering approach have worked?
      2. Or would it have been better if it was constant for so many seconds, then a step change?
      3. For example, your initial algorithm changed by a fixed increment at most every 30s; was that acceptable?
         1. What was the magnitude of an acceptable fixed increment
         2. Or could the magnitude be better expressed as a percentage

Ballpark numbers, or "don't know," are good enough, of course.

Thank you.

drbitboy said:

So this could be called zeroth order Integral control. i.e. ΔI = Ki (E**0) Δt = Ki Δt, with a deadband. ......

Click to expand...

I'm not going to pretend I know what you are talking about, but I get the gist of what you are saying.

I kind of ended up implementing something similar to what I think you are talking about. I tracked the number of occasions where the level would increase faster than Xm/s. Everytime this counter increased, it was used to calculate an incremental offset to the outflow pump speed. I did the reverse too if I saw the level falling faster than Ym/s.
This gave the effect of the pumps learning to be more aggressive when required over time. As different long term factors changed things, these counters affected the speed of the pump.

I didn't really get a chance to see it over a long period though as I left the company.

SilverShotBee said:

I'm not going to pretend I know what you are talking about, but I get the gist of what you are saying.

Click to expand...

This came up a few months ago; see this link; also this link later in the same thread.

I did a chemical plant waste treatment system many years ago where they wanted a "constant" discharge flow from a collection tank to a downstream treatment process. But, wanted to maintain the collection tank level too. This was a very large tank and it might go up 15% per hour.

My solution was to do a 1 hour rolling average, ( 60, 1 minute samples) of the level in the tank and use this average value, as the process variable to a PID loop, it worked well.