Modeling a column bottom level with bottom draw flow

TheRomanov wrote:


Your confusion confuses me.  So I assume I'm not getting something.

If you have a column of known dimensions, and you're truly controlling
the outlet flow (as opposed to the position of the valve or some other
indirect method), and you're working with an incompressible fluid and a
rigid column, then deriving the level vs. flow should be a problem from
a 1st-year calculus class.

Taking level = 0 as an empty tank, then

          level
          /
volume = | area(x) dx = f(level)
          /
          0

So level = f^-1(volume)

If the column has a constant cross section then

volume = level * area,

and

level = volume / area.

You must have some inflow, or your problem will become pretty boring
once all the fluid is drawn out.  so

total flow = inflow - draw,

and

          /
volume = | (total flow) dt
          /

which leads to

             ( /                 )
level = f^-1( | (total flow) dt )
             ( /                 )

And you're done.

So what did I miss?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim.

The final equation doesn't help me much. If you ever use or deal with
software like RMPCT or DMCplus, you would understand my question. Yes
the column has a known dimension based on mechanical drawing while
under basic control, the level is managed by cascading to the flow
controller. I'm dealing with real hydrocarbon here. Reason why I
mentioned basic control is because I'm working on APC. Therefore, I'm
more interested with equation like;

G(s) = Kp * (1/S+1) * e^-s

that tells me relationship between the level response to a step change
in bottom flow.

Thanks anyway for the assistance.

Tim Wescott wrote:

TheRomanov wrote:

(top posting fixed)


-- snip --


No, I haven't had the pleasure (?) of working with commercial industrial
control software.  All of the control systems I've built have been
purpose-built to be embedded in manufactured products, and I've been
given (or designed) a board with ADC(s), processor(s), DAC(s) and
driver(s).  The most purchased code that I've ever used has been
real-time OS code, and the most pre-made control code I've ever used has
been stuff that I've written for reuse.  So I am, for the most part,
blissfully unaware of the limitations imposed by your environment.

Be that as it may, if the column area is constant and known, and if
you're looking at level change vs. flow change (_not_ flow command), and
if your sensors don't introduce any significant delay, then your
equation is just

G(s) = Kp * (1/S) * e^0,

and Kp should be easy to calculate from your known column area and your
known sensor gains -- hence my confusion over your confusion.

If your sensors have delay thats a significant fraction of your intended
closed-loop response time, and you don't know what it is, then I can see
  your concern, and my confusion is resolved.

Does your practical problem with system ID stem from the fact that you
cannot take the plant off-line to do the test, or that it hasn't been
commissioned yet, or some other such thing?

If it were me, and if the system performance requirements allowed it, I
would investigate determining my expected plant transfer function from
first principals.  Then I'd make the World's Most Conservative tuning
that accommodates the performance requirements and what I know about the
plant and see if it works.

If the plant were running I think I'd also investigate whether I could
monitor the input/output relationship of the column, to see if I could
collect enough ambient data to pour into an ARMA model and determine the
plant parameters.  This does require that there be _some_ tuning
information available, it is fraught with errors, and it makes you
_really_ want to know what the inflow is -- but it may give you a model
that's enough better than a first-principals model to let you proceed.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

What you need is possibility something like:
http://home.arcor.de/janch/janch/_news/levelcontrol.htm

Maybe the German programm twb works also with your Windows system:
http://home.arcor.de/janch/janch/twb.zip
.NET framework 2.0

Have also a look to:
http://home.arcor.de/janch/janch/regeltechnik.htm
for using the result.


--
Regards / Gruss  Jan C. Hoffmann
http://home.arcor.de/janch/janch/menue.htm
Skype: janch01, janch[@]arcor[.]de

TheRomanov wrote:

Here is a recent thread that covers this topic.
http://www.plctalk.net/qanda/showthread.php?t&395&highlight=Advanced+Control

Peter Nachtwey

Based on the rest of the thread, assuming that this is to be treated as an
integrating CV  then all the control package should need to know is some
variant of the time it takes the level signal to travel full scale for a
nominated change in the bottoms flow. The bottom flow is an easy MV, you can
calculate it as described earlier simply based on the vessel diameter and LT
span. Then you just need to know what form the resulting integral time is to
be specified in, the package documentation will cover this.

The other models - base level vs other tower MVs - can be more difficult,
because the level controller needs to be out of play during the plant tests,
and there are likely to be significant additional dynamics on top of the
level integrator.

Bruce Varley wrote:

Is it correct for me to reword it by saying the time taken to drain the
level from 100 to 0% by 1m3/hr of bottom flow?


Once I obtained the rate, where do I specify the value presuming I can
enter the information onto the offline ID software such as Profit
Suite? I know the software provides direct entry in the following form;

Kp * (1/S) * e^-S

But which one refers to the rate? Kp?

The response of a level system is characterised by the hold-up time, which
is the time taken to raise the level from 0% to 100% (or vice versa) when
the manipulated flow (read "control valve stroke") is at 100%.

The reciprocal of this time gives the coefficient of the integral term in
normalised form.

Level (pu) = 1/TH x integral(inflow(pu) - outflow(pu))

Bruce.

That's the one. e^s refers to dead time (take a look at your college control
text). You need to go to the documentation for your particular MVC to find
out specifically what it means.

Occurred to me later that I'm not sure why you'd actually go to the effort
to get this model in your controller. The bottoms level doesn't (AFAIK) have
a significant effect on the operation of the column as long as it stays
within working limits. It's common to have a simple LC on the base, and
apply the MVC to the interacting, performance-sensitive variables such as
reflux, bottoms heat, etc.