PD(PI) Math Model (e.g.Tank Level)

[...]


<cited> Amplifiers and transmitters (e.g. temperature, 4...20mA output) are pure P-controllers with internally high gain k. kV/1V^6, error=0.00001=0.001% </cited>
Please read again: Amplifiers and transmitters!!
Please read again

You still don't have the same BENCHMARK SCHEME
Sorry, I can't compare.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: :: : You still don't have the same : BENCHMARK SCHEME : : Sorry, I can't compare. No kidding. That is because you really have a flow control system and apparently don't care about the level at all! It isn't clear to me what flow you are controlling, is it the in flow, out flow or the differential flow? These facts seem to change to fit your math.
My Scilab example is just trying to maintain a set point of 2 meters and the in flow changes. All you see is the level varying a bit until the integrator winds up or down to the match the in-flow ( disturbance ).
As I said many times before, you don't show your work. Anybody can load my TankLevel.sce and run it to reproduce the graph in the link. They can examine all the code and comments. You should use better labels on your graphs than u, v2 f2, etc. Label the graphs it is easy to see what you are trying to show. You do not make your assumptions clear. You didn't indicate that the graphs were about flow instead of level. OK, I agree a flow control graph would look something ( we'll ignore the non-linear realities ) like you have shown if you have a valve(s) that lets fluid in and out. It has taken too many posts to make that clear. You know you aren't doing yourself any favors with your posts.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
[...]

Peter, this topic is not easy.
I specified all in a mathematical way: http://home.arcor.de/janch/janch/_control/20070521-controldoc / Page 2
My program is under construction and is not compatible to anything.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: : [...] : : > It has taken too many posts to make that clear. You know you : > aren't doing yourself any favors with your posts. : : : Peter, this topic is not easy. : : I specified all in a mathematical way: : http://home.arcor.de/janch/janch/_control/20070521-controldoc / : Page 2
I noticed that you finally are doing level control instead of flow control.. That is an improvement. You are still assuming you have two valves. That isn't real. Bruce and Fred can correct me on this if I am wrong. You don't need to feed forwards. They are unnecessay. I don't use them on this simple example and my control looks as good as yours. Stop using the infinite or high gain controller. It only works on paper. : : My program is under construction and is not compatible to anything. Yes, so why not use a math package compatible with what others are using?. Tim convinced me to use Scilab last year. I think it would be best if you learned Scilab because then we could check your numbers and see how you came up with your numbers.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote in message
[...]

I have always controlled level v1 and refer to http://home.arcor.de/janch/janch/_control/20070521-controldoc / Basis is BENCHMARK SCHEME as you can see.

It is absolutely necessary for the defined BENCHMARK SCHEME.
See 'split range control' http://www.aurelsystems.com/techcorner/splitrangecontroller.htm
<cited> During the first half of the split range controller's output, the level control will be done by sending excess flow away from the tank through valve 028 as shown in the figure. At half way point, the flow through valve 028 will be shut off, and the mill water valve 011 starts to open. </cited>
Is that real?
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

Obviously there are systems like that. However, you have redefined your valves once again so that reality matches the math. You have also added another output to the controller so your math matches reality. None of this was in your original post. If you would have mentioned all of this up front I would have thought it was OK. I still wouldn't let you off the hook though. I would still point out the high or infinite gain controller will not work. Why do you ignore this? Even the TankLevel.sce control starts to look rough when I truncate the PV to match a feedback resolution of 0.001m.
See
ftp://ftp.deltacompsys.com/public/NG/TankLevelWithQuantizing.gif
ftp://ftp.deltacompsys.com/public/NG/tanklevel.sce
ftp://ftp.deltacompsys.com/public/NG/TankLevel.gif
Compare with my previous TankLevel.gif. You can see how just a little reality can ruin a theoretically perfect control scheme. My gains aren't near as high as yours. I haven't even included noise or ripple caused by the in and out flow. Tim has been giving me/us a pass so far. Your high gain system would be very hard on the valves if it work at all. The control output would probably just go from one extreme to the other.
Quantizing/feedback resolution can't be ignored. This is one of the biggest factors that limits gains. BTW, what is your sample time?
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I published my actual solution on May/21 2007 (today: May/28 2007)

Read carefully first and last sentence:
<exact citation from May/25. 2007> k->infinity applies to feedback control. Examples: k=infinity x = u/(1+1/infinity) = u Steady state error 0% k = 100 x = u/(1+1/100)=u/1.01=0.99*u Steady state error of 1% k = 1000 ... I guess that 95% P-controller are used in level control. One does not care about error. If you care then PI-controller and PID-controller are used. Amplifiers and transmitters (e.g. temperature, 4...20mA output) are pure P-controllers with internally high gain k. kV/1V^6, error=0.00001=0.001% If you can't utilize k^6 for some reason you must reduce k for having stable conditions. </exact citation>
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

I wouldn't say that. A simple proportional band controller will do the trick as long as the proportional band doesn't let the tank over flow. This way the gains can be very low and the ripple in the tank and quantizing of the feedback will not be noticeable.

In reality I wouldn't spend the time on it. The only reason why I am bothering with this lost cause is that you will corrupt other rookies that are just lurking and trying to learn.
You shouldn't be teaching anybody and you refuse to learn. Why do you bother? You seem think you know it all already so why bother with us?

I don't understand why you are so stubborn about this. Can't you see that just a little noise or quantizing greatly affects my controller and my open loop gains are much lower than your gains. If have said this so many times and then you claim I am just saying that you are wrong without reason.
I don't see why you refuse to show your calculations like I have shown mine.
You refused to answer many of my questions.
Believe me, your precious calculations are not a top secret if if they were right.
I don't see why you refuse to answer my questions or look at my Tanklevel.sce and ask why I did things the way I did.
YOU WILL ALWAYS BE WRONG AS LONG AS YOU INSIST THE OPEN LOOP GAIN IS K BECAUSE NOTHING HAS AN INFINITE BANDWIDTH. DON'T FEEL HURT AND CLAIM I AM ACTING LIKE THE POPE. I AM JUST TELLING IT LIKE IT IS.
It is time for a new horse. It wouldn't drink. I tried shoving it into the water but it wouldn't budge. This horse is ready for the glue factory.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
[...]

Topic: PD(PI) Math Model(e.g.Tank Level) with BENCHMARK SCHEME ^^^^^ Anything is defined and solved in 4 pages: http://home.arcor.de/janch/janch/_control/20070521-controldoc / That is 100% calculated (formulae in page 2).
Your response: ^^^^^^^^^^^^^ Normal PID level control without BENCHMARK SCHEME test conditions.
Please, EQUAL CONDITIONS! Then I can compare.

<Citation May/24 2007> 3. Peter warns students that what I am writing is wrong, completely wrong. But he can't tell what is wrong. He just knows that's wrong. The pope can argue this way. But not engineers.
</Citation>

You still ignore the BENCHMARK SCHEME in your simulation. Then your control is much (note: much) easier than using BENCHMARK SCHEME.
Please, be fair and use the BENCHMARK SCHEME! All what I have done is based on it.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
See the difference: PD(PI) and PID
http://home.arcor.de/janch/janch/_control/20070521-controldoc / Page 3, 2nd Fig. PID
That is PD feedforward with PI feedback control Fig.1 compared with PID feedback control normally used.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: See the difference: PD(PI) and PID : : http://home.arcor.de/janch/janch/_control/20070521-controldoc / : Page 3, 2nd Fig. PID : : That is PD feedforward with PI feedback control Fig.1 compared with PID : feedback control normally used.
Why does your PID look so much worse than my PID? My PID doesn't over shoot and oscillate. Well? Why would you even bother to show this comparison? All it shows it that you don't know how to tune a PID. You are not doing yourself any favors with your posts.
Would you stop this. Someone that doesn't know better might believe your comparison. 1. Your high gain controller will not work in reality. Therefore the PID wins. 2. Your PID is tuning is awful and it makes PID tuning look bad. For not 'playing fair' you lose. 3. Your PD with feed fowards assumes you have a linear system and you have modeled the system perfectly. This is impossible. Therefore you will always have some amount of error. The integrator on the PID will eventually compensate for the non-linearities. The PID wins gain. 4. You didn't show your work, AGAIN. What are the PID gains? How did you determine them? You get no credit because you didn't show your work. I have showed a symbolic way of calculating gains and number crunching method, Ackermann's.
Why not listen for once. It took how many posts before you figured out the difference between level and flow control when I have been telling you your system isn't right from the beginning. You didn't figure out that you needed two valves to make your control work until I mentioned it. Does this mean when you get around to heaters that your control system will cool when the control output goes negative? I bet you just add a cooling system just like you added the second valve. Do you see what I mean now? The others did. I think you should do less posting and more studying.
Peter Nachtwey .
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I specified all that could be specified. You find this in http://home.arcor.de/janch/janch/_control/20070521-controldoc / Page 1, 2, 3, 4
Look at page 4 for higher target change and keeping precision.
Note: I have made 1 error, found it myself and corrected it on the same day (May/21 2007, introduction of split range control). I defined PD(PI) Math Model (e.g.Tank Level) and gave you 'all' data (page 2). It was not intented to simulate just PID control with fixed set point. All (note: all) what I have written so far is correct.
All diagrams show: BENCHMARK SCHEME
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 24 May 2007 11:35:06 +0200, JCH wrote:

(attempts to tie your argument with Peter into my statements snipped)

The controller can darn well keep itself from getting into a state that will mess things up, and it can schedule the valve closure (or opening) so that the system comes to rest as soon and as gracefully as possible. See "integrator windup", and for an example with a motorized system "trapezoidal velocity profile" (which ought, come to think of it, work for a tank filling/draining problem as well).

I have already told you what my issues are. I have absolutely no inclination to read even more stuff, because we haven't resolved this discussion.

No, _I_ don't. _I_ take system nonlinearities into account up front instead of living in cloud-cukoo land. If, _after_ looking at the nonlinearities I think I can linearize the system sufficiently then I thank my lucky stars, I linearize, and I do my _analysis_ with the linearized system. But any _simulation_ I do is done with the nonlinearities in place, to verify that the linearizing assumptions were correct.

There are many alternatives. The real world isn't linear, so you'd better get used to it. If you can linearize a system and then do your design, fine. But _no_ real system is linear so there is no alternative to dealing with nonlinearities. Even while many systems can be linearized in seemingly effective ways, nearly all systems, even if they show no other nonlinearities, will show actuator saturation.

I have put so many loops of various kinds into service that I've lost count. Many of them have linearities that _must_ not be ignored if the system is going to work correctly. And nearly all of by designs still have instances that are giving good service to my customers, or my customers' customers, today.

I do fine, thank you. There are many techniques for dealing with nonlinear plants, and they are of varying effectiveness. Many of them deal with pretending that the plant is linear -- but only to the extent that the pretense is valid -- past that point you must take the nonlinearities into account, or stand back and watch your system fail to do its job.

I'm glad that you admit to the "as much as possible". Too bad your examples and your rhetoric don't support that statement.

No.
There is absolutely no reason for a simulation to be based on a linear model. It only has to be tractable enough for the ODE solver to deal with it. You often want to linearize a system to do analysis, but analysis and simulation are two entirely different things.
If you have a linear model then the simulation is trivial, and you shouldn't waste time on it. If you're doing simulation at all it should either be for education or because you are taking nonlinearities into account.

No.
It is the aim for well controlled plants to do their jobs. If that can be done by assuming that they're linear, all the better. But that's not the aim -- just a convenient way to pave the road, sometimes.

Simulation is math, and math isn't real. Real is what falls off the machine when it oscillates too hard. I understand set point and process value, thank you very much.

No.
The real system can't be made linear. No real system is entirely linear. Anything will bend, break or burn if you push it hard enough, and all three of those are nonlinear behaviors.

That is an oxymoron. There are no real linear systems. Even a vacuum being excited by an electric field will eventually tear itself apart into charged particles. The only place that linear systems exist is in our imaginations; there are none in the real world.

Yes, we noticed. That is our point.

I have no problem with mathematics. It's a great tool. You're just misusing it by mistaking it for reality. Mathematics isn't reality, it cannot replace reality, and if you believe your math before you believe the real world then you'll be a failure at engineering, no matter what your fellow mathematicians think of you.

--
Tim Wescott
Control systems and communications consulting
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
[..]

AS I SEE IT
Refering to valves in chemistry:
But in planning power stations or chemical plants you haven't data to take into account. You just can plan performance for linearization using
- nothing (20% if in cloud-cukoo land to 80% if you are very lucky) - positioner for position control and semi-nonlinearity compensation (>80%) - flow control for best linearization (>97%)
The ideal sytem is a totally linearized system and matches the simulation if done so. But that's not feasible. So try the best with the money that is available.
Refering to control devices:
A temperature transmitter e.g. is a P-controller 'controlling' the output current 4...20 mA. The internal gain is very high and therefore the transmitter linearized.
If performance counts linearize all devices as much as possible and the system works as best as possible.
Refering concepts:
Use simulation if you have to decide concepts. It will always be of advantage if much money is involved. You won't get necessarily real answers but you can say concept A is better than concept B or vice versa. Do it under 'equal conditions'. Define a benchmark scheme.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

At least once a class meeting I remind them that while the analysis is linear, the real systems aren't. So you use the linear approximation to get close to a solution, or to get a solution that's close.
I do keep throwing out hints -- I was just thinking that this week's homework will have an example of treating a nonlinearity (friction in this case) as a disturbance, and using the known magnitude of the discrepancy to predict the worst-case deviation of the real system from the predictions of the linear model.
I _am_ saving the nonlinear analysis for later (or in this case for another class because I only have one quarter). But it's there in my book, and in a form that can be handled by someone with greasy hands and a pencil to do the math, instead of a form that requires access to a university math department and a super computer or two.
Note that I'm not dissing simulation here, or higher math: they're both excellent tools. But without understanding the underlying issues simulation is just a quicker way to fart around in the lab until you stumble on something that works on that day, at that temperature, with that particular choice of components. You need the understanding to guide the simulation, and to understand the results. On the other hand, for most people the higher math is a bar across the door rather than a window to let the light in. For those who do understand the math one can easily get lost in the beauty of it and forget to connect it back to the physical reality of the system that you're trying to get working.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Please show me your solution for the benchmark test I defined in: http://home.arcor.de/janch/janch/_control/20070521-controldoc /
If you have a different 'time domain solution' I would think about it. Putting hands on something is NOT a solution I could appreciate. Sorry.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

Why? Peter's comments, and my joke, are about your controller output taking on absurd values. I don't have to go past looking at your controller output on the first page of your presentation to know that you're being unrealistic, and if you aren't speaking about real things I see no reason to jump through hoops of your making.
Your control output works just like all valves and most pumps don't: it's bilateral. It's as if you expect to jump into your car, put it in gear, pull up on the accelerator, and go backwards. That can happen in mathemagic land, but here in the real world things simply don't work that way.
* your accelerator is restricted to making the motor go faster -- below a certain point it stops doing anything. To be more precise, your accelerator is restricted to making the motor try harder, and is restrained from allowing it to stall out.
* your brake pedal is restricted to making your car go slower -- you hope.
* Valves can be opened, partially opened, or closed. Once they're closed they can't be opened in reverse to make the liquid flow up hill.
* I suppose I could build a perverse sort of pump that would pump backwards if I spun it backwards, but nearly all economically feasible pumps have an input and an output, and they only pump in the given direction.
* Systems that don't saturate the control output are trivial. You show your control output as a decaying exponential, with no flat- topping where your valve is fully opened or your pump is running flat out. Valves that only open so far, motors that can only deliver so much torque without burning, and can only go so fast without flying apart, heaters that can only deliver so much power without tripping a breaker or burning themselves up -- that's _real_ control.
Linear systems are a Platonic ideal that we use to make the math manageable, but we have to step back from reality to make the math work. The price we pay for this separation from reality is that the linear analysis is _wrong_; before you use it for real you have to correct for the wrong parts so you can use the right parts.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Have you ever heard of 'Split Range Control'? http://www.aurelsystems.com/techcorner/splitrangecontroller.htm
In real life: e.g. Controller output 4 ... 20 mA
2 Valves operating
Valve 1 Water Inlet 12 ... 20 mA (closed to fully open) Valve 2 Water Outlet 12 ... 4 mA (closed to fully open)
It's simple, isn't it?
In chemical reaction plants you have the same principle:
Heating with valve 1 and then cooling with valve 2. It's a bit more difficult because of extreme nonlinearity. All I planned and tuned work fine.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

I have, and I've contemplated using it. So let's forget the control going negative part, and concentrate on the lack of any limits to your control effort.
Here's an experiment to try:
Let's say that your car will decelerate at 10m/s^2 when you push the brake pedal all the way to the floor (it's a really nice car). Let's say that the distance the pedal moves is 10cm.
Now let's say that you're traveling toward a brick wall at 180km/hour, and you want to stop before you hit it, to avoid damage to you and the car.
By my reasoning, you'd have to apply the brakes at least 125 meters short of the wall, or get a nasty bump.
By your reasoning you could wait until you're only one meter away from the wall, depress the pedal 125cm, and come to a smooth stop.
To you, the following are just insignificant details: * the pedal will only go 10cm, * if it could go farther it wouldn't make any difference because the tires would be locked, * your leg isn't that long, * and if it were, and the pedal would go that far, and the tires could grip, then the car would decelerate at 125g and you'd be jelly on the windshield.
Because, aside from these minor details, the math works!
Note: If you try this experiment in reality, please leave me on the curb -- I don't take extreme deceleration very well.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Tim Wescott wrote:
...

Just for reference, 1 g = (very nearly) 22 mph/sec.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.