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

You see the limits: 0.2 ... 1 (4 ... 20 mA = 0 ... 100%)

At closed and opened the valves have nasty bumps:

But here 0.5 reserve. Only 0.3 are used. Total 0.8

In reality I suggest to add 20%.

If the water tank is e.g. empty or full there is nothing to control automatically beyond these limits.

Sorry I can't see a 'real' resemblance to the tank level control. Maybe a car rocket for towards to 100% (wall) and a car rocket for backwards to 0% (hole) from the wall. You could apply a benchmark scheme, too. The acceleration v1'' should not exceed 5g. The process transfer function is mathematical similar to the tank level transfer function.

I would accept this if disturbance is not 0.1 but less than 0.05

points)

Exceeding limits cause trouble. That's for sure.

If you have high concentrated acid in the tank it is dangerous, too. For you if acid is spread around you or the pumps running dry. Insurance companies don't like that.

-- snip --

Eh? Nearly every control system I've ever worked with saturates the controller during a gross move. If you're not saturating the controller you're either working on a system with very odd requirements or you've grossly over-specified the actuator.

Exceeding the limits of what you'd get out of a purely linear controller doesn't lead to _invalid_ control, it leads to what you see in the _real world_, _every day_, _day in_ and _day out_.

Yes, that's quite apparent. In fact, reality is distressingly lacking in many of your posted examples -- which is why you're getting so much flak. This lack of anything that ties your pretend systems to the real world is what has Peter upset, and is what is pulling me into the fray (for a while -- you're at the water trough, if you won't drink soon I'm going to go look for a more sensible horse).

Then to be complete you should show that your controller responds appropriately to a control input that takes the actuator to the limits of its range for a good long time. For many control systems the loop is routinely driven into actuator saturation, or would be if the executive controller allows it -- any responsible designer will investigate what happens when the actuators saturate, and correct any nasty problems, before they call a system "good".

This is, perhaps the crux of the problem.

To you, "simulation" means "mathematically appropriate". To me (and to Peter too, I'll bet), "simulation" should darn well mean "matches reality well enough to make good predictions". If it doesn't then "simulation" means "waste of time".

"Matches reality well enough to make good predictions" is a much smaller set than merely "mathematically appropriate". To make good predictions "simulation" has to incorporate physics, a good reading of manufacturer's data sheets, an understanding of the system requirements, and some experience with how real components don't always live up to their data sheets, besides.

I spend most of my time redesigning systems that some poor guy with inadequate control systems training has put together wrong, or that someone put together in a hurry knowing that getting product out the door that worked 90% was better than not getting product out the door at all. But I've spent quite enough time fixing problems created by guys (and it has been, uniformly, men) who had their heads stuck so deep in the books that they couldn't see the obvious. It's certainly been enough to have developed an allergy to systems that show an excessive attention to theory without attention paid to the real-world behavior of physical systems if they should happen to be used outside the lab.

...

I was once called in to troubleshoot a system put together by a Ph.D. with about ten years of paper experience and three weeks of trying on his own to make it work. It kept blowing the filter capacitors on the negative supply, sometimes explosively. I fixed it in ten minutes. He wanted to know what I did, and I showed him that the big 'lytic symbol on the schematic has one curved line and one straight. He said, "A capacitor is a capacitor. What difference does it make?"

Jerry

4 mA Min 20 mA Max

via split ranch control

See comment later.

Again: v2 on all diagrams.

4 mA Min, 2 V, 0.2 intern 20 mA Max, 10 V, 1.0 intern

Jan:

Tim:

What can a controller do if the valve is already open or closed? There will something happen. But NOT controlled.

Ok, tell me where, not that it is wrong:

Fact is you simulate linear and later you linearize e.g. the valve behavior if data are known. Then you have almost a linear system that matches with the simulated one. If data input have accuracy of 99% calculation is 99% accurate. If 50% then calculation is 50% accurate. The calculation itself can do it with 10^-3%.

There no alternative. The aim is linearization of systems! I have done it on few plants. Otherwise you can't control them properly. In chemical plants you approach that with positioners (e.g. valve controller). Any transmitter and amplifier does it. The P-controller does it. And having digital equipment it's done, too. You do it on hardware and you do it with software. And if done very well you have done as much as possible having a linear system.

Again:

1. Any simulation has to be 'linear' in a math model. It is the aim for well controlled plants to be linear. (simulation is 'set point', real is 'process value'). The 'process value' has to approach the 'set point'.

1. Therefor the real system must be made linear by hardware and/or software (the model is already linear).

Again:

A linear real system is the best system. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ compare with

I modeled a linear mathematical system. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My tool is MATHEMATICS. If you don't like mathematics do not respond.

Anyway, PID and PD3(PI) comparisons can be dicussed right away. It gives useful answers. How can anyone know the difference if not having made a simulation before. I did it on equal conditions with ITAE criteria and found that PD3(PI) is much better. Anyone is invited to do it better.

Notes to Peter's polemics: Examples

1. I made clear that if loop gain k goes to infinity ouput will be equal to input (x=u if c=1) and then the system is linearized. I didn't say loop gain must/should be infinity. I said gain should be as high as possible and gave examples.

See

1. Peter resembled heaters cooling or coolers heating. He said I applied it in equations for level control. I made clear that this is not possible. Heating systems have completely different process transfer functions. For heating v1>0 and for tank level v1=0.

See

1. 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.

Hey, I wish I could spend this much time on a simple tank level control app!!

"Bruce Varley" schrieb im Newsbeitrag news: snipped-for-privacy@quokka.wn.com.au...

Times ago drum level control in power stations wasn't simple. The drum was fed with cooler feed water to increase level. Instead the level dropped first for physical reason and increased thereafter.

The controller was 'irritated'. Generally the 3-component concept was applied. Tuning was difficult for high steam demand (power increase).

I don't know whether a better concept has been found yet.

OK, you asked for it.

On page 1 you have indicate the k->infinity. Now you tell me it doesn't necessarily have to be infinity. What is the value of k then? I don't see it on page 1,2 or 3. I have ask you to show your work and you ignore me. It is you that is asking for blind faith.

One page 1 you should show no limiter between the PD3I controller and the process. How do you limit the output in the s domain? Curious minds want to know. I don't see how you limit the output from 4-20ma all claim to.

Page 2. The set point takes a jump to .9 and the target starts moving in that direction, OK. However, it looks like the controller output also takes a jump ( the brown line ) and the process value tries to follow. Can't you see what is wrong here? If there is no in-flow then the tank level will not rise. All the valve can do is close and wait for the level to rise to the set point. IT IS JUST THAT SIMPLE. Normally one doesn't change the SP, it is the in-flow or disturbance that changes. Also, the gain is negative when the valve in on the outlet. It look like you are opening the valve to let fluid in.

All you have done is change the SP level without regard to the disturbances or changes in the in-flow.

Page 3. Your PID tuning is awful, I showed you an example on how to do tune right in the .pdf. The Scilab script also has the formulas for calculating the PID gains given the model and a desired closed loop time constant. You can always make PIDs look bad with bad tuning. Why doesn't your PID tuning look as good as my PID tuning? I showed you how I did it but you ignore it. You just want to claim I am attacking you.

You are still assuming the valve will remove or add fluid as necessary. This happens when you ignore the output limits on the controller. How many times have I said this yet it is you that accuses me of just saying it is wrong.

It looks like your control output is following the set point. If there is no in-flow then the output should go to 0 as the error goes to 0. Why is your control output matching the SP?

I think I have bent over backwards showing you some good examples of level control, converting the models to discrete time, implementing output limits, how to calculate gains, and how to model disturbances and all you think I am doing is attacking you. What is wrong with you? Who else on this newsgroup has done so much? If I were wrong the others would be very quick to point it out, but I see the others only telling you that you are wrong. I have wasted enough time.

Peter Nachtwey

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.

k=10V/1µV=10^6, error=0.00001=0.001%

If you can't utilize k=10^6 for some reason you must reduce k for having stable conditions.

Limits are 0.2 and 1.0

I use time domain. It is more flexible.

I do it in time domain:

If v2>20 then v2=20 elseif v2 Page 2. The set point takes a jump to .9 and the target starts moving in

That belongs to the PD3 Modeling discussion:

Controller v2 and step w take the same jump.

That is the point of 100% time compensation! v2 is input to the process. You see v1 equals u if not disturbed.

PID controller 'could' never do that. Ok, I could find a good result iteratively using ITAE criteria. That is completely ok.

But not my motivation. My motivation is: Are there better methods?

Let's go back to tank level control:

1

I mentioned already: completely different (v1=0)

BTW: v1 is not existent but used. v1' is integrated to v1 in the model and measured in real plants. It is needed for error value e = u - v1

Sorry for those who can't understand that. It's very abstract (See also Page

2).

The benchmark scheme says: Get water in and get water out. You need 2 valves controlled in split range.

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)

That's right. But I defined a benchmark scheme (w) including disturbances (z1, z2). Not a normal level control. You constantly have ignored it.

You have 3 systems working together:

Controller 4...20 mA Valve 1 4...20 mA Valve 2 4...20 mA

The split range control unit splits the signal. Using pneumatic valves the positioner on each valve can do the split.

The positioner can also linearize the valve characteristic like flow proportional to position. There is nothing 100%. But much better than nothing.

I forced level change u plus disturbance z1 (valve) plus disturbance z2 (level) at certain times. This is shown in the benchmark scheme. Then I was interested in to see what happens with the process value v1.

Sorry, I tuned WITH a benchmark scheme. You refer to a different task: Normal level control.

Going to level control PD(PI)

I claim that using PID is worse for the defined benchmark test. I proved it. And my tuning experiences tells me:

Use feedforward if ever possible!

Yes, 100%, valve 1 for fluid-in and valve 2 for fluid-out using split range control. There is no chance to do it with just one valve.

The diagram shows you opening and closing both valves.

Again:

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)

That is split range control. 1 signal (controller output) is split into 2 signals for 2 valves.

You see that in the diagram. They work alternatively. Both can be closed but both can't be opened at the same time.

That's the only way to tackle the benchmark scheme that you constantly ignore.

Yes it is. More demand needs more water and vice versa.

PD(PI) Level Control

1

Control output v2 is NOT matching set point u.

Nothing. You ignore the benchmark scheme. All I say is based on it. I didn't specify a normal level control with constant set point!

Sorry for that.

"JCH" schrieb im Newsbeitrag news:46571da2$0$23132$ snipped-for-privacy@newsspool1.arcor-online.net...

I added Page 3

Solution without distubances. Just target moving:

If there is one, then AFAIK it hasn't reached the real world yet. Boilers I've seen in recent times still have the traditional 3-element setup. That's OK for a limited range of conditions, but it struggles with boiler loads significantly below MCR. Aspects of the theory (the linear bits) are well known and documented, and suggest that some sort of adaptive system would be required to improve the operating range.

I think the problem is that in practice the problem is seriously nonlinear, and most likely chaotic at times, like a lot of real world process control dilemmas.

(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" schrieb im Newsbeitrag news:rZWdne0zdeQCL8rbnZ2dnUVZ snipped-for-privacy@web-ster.com...

[..]

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.

: > On page 1 you have indicate the k->infinity. Now you tell me it doesn't : > necessarily have to be infinity. What is the value of k then? I don't : > see it on page 1,2 or 3. I have ask you to show your work and you ignore : > me. It is you that is asking for blind faith. : : : k->infinity applies to feedback control. : : k = 1000 ...

How how tall is the tank in your model? What is the resolution of the AtoD converte?. An error of one count in the feedback will generate how much output? : : k=10V/1µV=10^6, error=0.00001=0.001% : : If you can't utilize k=10^6 for some reason you must reduce k for having : stable conditions. : So an error of 1 uV in the feedback will cause 10 volts of output? You must know that will not work. You must take into account the resolution of the feedback device and typical noise levels. When fluid is entering the tank don't you think it will at least make a ripple?

: > Page 2. The set point takes a jump to .9 and the target starts moving in : > that direction, OK. However, it looks like the controller output also : > takes a jump ( the brown line ) and the process value tries to follow. : > Can't you see what is wrong here? : : : That belongs to the PD3 Modeling discussion: :

thought we were looking at page 2?

: : Controller v2 and step w take the same jump. : : That is the point of 100% time compensation! v2 is input to the process. : You see v1 equals u if not disturbed. : : PID controller 'could' never do that. Do what? Follow the target u? That is easy on paper. As I said before, don't need the feed forwards in such a simple application.

Ok, I could find a good result : iteratively using ITAE criteria. That is completely ok. : : But not my motivation. My motivation is: Are there better methods? Yes, but you are not listening so why bother?

: : : The benchmark scheme says: Get water in and get water out. You need 2 valves : controlled in split range. : : : 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) : : Ah, this is where reality is changed to fit the model. Isn't math wonderful? I can see your valves can add AND remove liquid. Bruce, Fred do you use such a scheme to control your tank levels? Inquiring minds want to know.

JCH, tell us. What happens to the fluid that you don't allow into the tank when you restrict the in-flow? Spill on the ground? Oops! I bet the others will tell you there is just one pump or valve on the outlet.

: : > Normally one doesn't change the SP, it is the in-flow or disturbance that : > changes. : : : That's right. But I defined a benchmark scheme (w) including disturbances : (z1, z2). Not a normal level control. You constantly have ignored it.

I have seen them. So where do these disturbances come from if you are controlling the inlet AND outlet? Normally, the distrubances are the change in in-flow.

: > Also, the gain is negative when the valve in on the outlet. It look like : > you are opening the valve to let fluid in.

: You have 3 systems working together: : : Controller 4...20 mA : Valve 1 4...20 mA : Valve 2 4...20 mA : : The split range control unit splits the signal. Using pneumatic valves the : positioner on each valve can do the split.

Yes, I see but you didn't mention there were two valves before now. You must have seen that one valve would do what your model suggested. :

: I claim that using PID is worse for the defined benchmark test. I proved it. That is only because you don't know how to tune the PID so it will have the same response as the target u.

: And my tuning experiences tells me: : : Use feedforward if ever possible!

Yes, I believe in feed forwards too. They are necessary for motion control. Feed fowards do you no good when the control system is just trying to hold position and responding to distrubances. : : : : You see that in the diagram. They work alternatively. Both can be closed but : both can't be opened at the same time. : What diagram?

: That's the only way to tackle the benchmark scheme that you constantly : ignore. : : : > It looks like your control output is following the set point.

: Yes it is. More demand needs more water and vice versa. : But this is level control not flow control. w is level not flow or have you changed that too?

: : : >>>>>>>>>>>> BENCHMARK SCHEME !!

"Peter Nachtwey" schrieb im Newsbeitrag news:6rSdnZvJA6xg-MXbnZ2dnUVZ snipped-for-privacy@comcast.com...

[...]

Amplifiers and transmitters (e.g. temperature, 4...20mA output) are pure P-controllers with internally high gain k. k=10V/1µV=10^6, error=0.00001=0.001%

Please read again: Amplifiers and transmitters!!

Please read again

You still don't have the same BENCHMARK SCHEME

Sorry, I can't compare.

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

See the difference: PD(PI) and PID

3, 2nd Fig. PID

That is PD feedforward with PI feedback control Fig.1 compared with PID feedback control normally used.

"Peter Nachtwey" schrieb im Newsbeitrag news:Z8-dnV0uJssqFsXbnZ2dnUVZ snipped-for-privacy@comcast.com...

[...]

Peter, this topic is not easy.

I specified all in a mathematical way:

2

My program is under construction and is not compatible to anything.

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

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 .