PID vs floating control

[Peter Nachtwey]

About my answer to BobB. We have several hydraulic systems at Delta. Some of you have trained on them. There is a red pipe that is the pressurized line and the blue return line. Th output of the pump first goes through some hose to get to the red pressure pip. The pressure pulses in the oil from the pump make the pipes vibrate though there is no metal connection. We have accumulators out about midway the length of the pipes. To reduce the humming sound or noise we could add an accumulator near the pump. We should also add one at the end of the line. Accumulators are like the small capacitors on circuit boards. There should be a small capacitor near every switching IC. It would be better if we had more accumulators too.

 

[kamenges]

Originally posted by Peter Nachtwey:

One complaint I have with how PID control is taught is that you are told that this gain does this, that gain does that, etc. In reality the gains place closed loop poles that determine how errors will decay. If you know where you want the poles and have the plant parameters, then you can calculate the controller gains to place the poles where you want, within reason.

Don’t go all modern quantum mechanics on me here, Peter. The system begets the model, not the other way around. The system doesn’t act the way it does because someone says the poles are at X. The poles are at X because of the way the system acts. Yes, the user has an influence over where the poles are located. But in the end, the desired location of the poles is a WANT. The actual location of the poles is a FACT. Changes to the controller gains have a tangible, measurable effect on a given physical system. And in general those changes can be predicted. So saying that increasing proportional gain will have a given effect on a system is true. Now, there is an argument to be made that this is not necessarily the most useful information and may not be the best way to approach a design. But to infer it isn’t factual flies in the face of reality.
It’s like the old calories out / calories in view of weight management. There are those out there that try to tell me this isn’t fact. This IS indeed a thermodynamic fact, liposuction excepted. Whether this information is truly useful to someone trying to manage their weight is certainly up for debate for a number of reasons. But to deny its truth just seems to ignore reality.

Originally posted by Peter Nachtwey:

If you know where you are placing the closed loop poles then there is no problem.

This is absolutely true. But it is also a little simplistic. “If a little left is good then WAY left must be better”. We both know it doesn’t work that way. There are many things that limit how quickly you can force a system to settle. But converting those limiting factors to numeric limits on the negative real axis of the s-plane is the real useful piece of information in the context of calculating gains based on desired pole locations. I think this is where many of the discussions about pole placement kind of fall apart. Well, here and at the next point.

Originally posted by Peter Nachtwey:

The real trick is finding an accurate model. Calculating the gains is easy.

Again, very true. As you have said many times before this is much more than just teasing some constants out of a data set. Evaluation is meaningless without determining the overall system type (integrating or non-integrating, number of poles, etc); in essence providing a framework for the constants to fall into. This will likely require more than just a casual glance from most of us. Calculating a set of PI gains for a plant with a complex conjugate pole pair will leave you wanting. As you said, this is the real trick. And what do you do when you end up with a 3-pole plant with all the poles in the area you need to operate in? Don’t answer that. I know what YOU would do. But that one is going to cause issues for most of us. No matter what, knowledge in this case is power. Knowing what you are dealing with is always better than not knowing BEFORE you bang your head against a wall for a week trying to do the impossible with the tools you have. Again, the hard part is getting that model.

Originally posted by Peter Nachtwey:

Now the question is it worth it to take the time to understand my pdf in order to get faster response.

And right there is the real question. I will never argue the fact that a model based approach to controller design is better than the tweak and hope method. I will also agree that a PID based controller will outperform floating control. The question becomes what are the tangible benefits to model based PID design? Increased performance is an obvious benefit of model based PID design. But do I really need that Ferrari to go pick up groceries? Yes, I’ll look pretty cool doing it. But is it really necessary?
Model based PID design will almost certainly result in reaching optimized control faster than any other method discussed here. But is the time savings worth the effort in system modelling required to calculate the gains? Yes, having an accurate plant transfer functions comes with additional benefits over and above gain calculation. But will that really produce tangible benefits?
And then there is what I THINK is the basis of Tom’s point. Is it really better for ME, as an engineer supporting customers, to embrace a design method that will EITHER require me to develop a suite of tools to support the method (think RMC Tools) OR try to manually drag my customers along as they try to learn the method? Or is it easier to use a lower performance option that I can easily explain to others? Seems to me we are kind of asking Tom to fall on the sword in the interest of increasing the overall capability of the industry for very little gain to himself or his customers.


Keith

 

[Peter Nachtwey]

Good questions, everyone read!

Don’t go all modern quantum mechanics on me here, Peter. The system begets the model, not the other way around.

This is true but I can determine what the model is by using a technique called system identification. The better auto tuning programs use a system identification technique. When I was contributing to the controlguru.com site back in 2005, Doug Cooper opened my eyes to a whole family of techniques which were much better than the least square fit type of function.

The system doesn’t act the way it does because someone says the poles are at X. The poles are at X because of the way the system acts.

Yes, when in open loop/manual mode.

System identification finds where the open loop poles and zeros are. Usually one only determines the open loop poles.

Yes, the user has an influence over where the poles are located. But in the end, the desired location of the poles is a WANT.

The user place the closed loop poles by choosing the right controller gains. There is a difference between open loop and closed loop poles.

The actual location of the poles is a FACT.

Yes, the actual location of the open loop poles is a fact.

Changes to the controller gains have a tangible, measurable effect on a given physical system. And in general those changes can be predicted.

Yes!!!!

So saying that increasing proportional gain will have a given effect on a system is true. Now, there is an argument to be made that this is not necessarily the most useful information and may not be the best way to approach a design. But to infer it isn’t factual flies in the face of reality.

I agree.

This is absolutely true. But it is also a little simplistic. “If a little left is good then WAY left must be better”. We both know it doesn’t work that way. There are many things that limit how quickly you can force a system to settle. But converting those limiting factors to numeric limits on the negative real axis of the s-plane is the real useful piece of information in the context of calculating gains based on desired pole locations. I think this is where many of the discussions about pole placement kind of fall apart. Well, here and at the next point.

Yes, there is reality. Feedback resolution and higher order poles and zeros will become more apparent at higher frequencies. In industrial hydraulics, most systems only need a bandwidth of 5Hz. In these cases there is no need to move the closed loop poles far to the left on the negative real axis. Testing systems are much different. Now higher speed and finder resolution feed back is required. The poles and zeros of the valve start to play a significant part. In motor systems the inertia of the motor and load is the most significant pole but if one considers the RL time constant of the windings in the motor then there are two poles. Fortunately they are both real poles unlike hydraulic systems that are similar to a mass between two springs.

Again, very true. As you have said many times before this is much more than just teasing some constants out of a data set. Evaluation is meaningless without determining the overall system type (integrating or non-integrating, number of poles, etc); in essence providing a framework for the constants to fall into. This will likely require more than just a casual glance from most of us. Calculating a set of PI gains for a plant with a complex conjugate pole pair will leave you wanting.

Yes, each pole requires a gain. However the integrator doesn't count because it comes with its pole.

As you said, this is the real trick. And what do you do when you end up with a 3-pole plant with all the poles in the area you need to operate in? Don’t answer that. I know what YOU would do. But that one is going to cause issues for most of us.

I wish you would stated what you think I would do. I will tell the forum. Hydraulic systems can be basically modeled as a mass between two springs. This results in a complex pair of poles. Integrating velocity to position adds another pole. If an integrator is required then it adds a pole. So there are 4 closed loop poles so 4 gains are required. An integrator, proportional, derivative and second derivative gain. It is the second derivative gain that is the killer. Most people have problem with the derivative gain.

No matter what, knowledge in this case is power. Knowing what you are dealing with is always better than not knowing BEFORE you bang your head against a wall for a week trying to do the impossible with the tools you have. Again, the hard part is getting that model.

YES! YES! YES! but one must also understand what it is trying to tell you.

And right there is the real question. I will never argue the fact that a model based approach to controller design is better than the tweak and hope method. I will also agree that a PID based controller will outperform floating control. The question becomes what are the tangible benefits to model based PID design? Increased performance is an obvious benefit of model based PID design. But do I really need that Ferrari to go pick up groceries? Yes, I’ll look pretty cool doing it. But is it really necessary?

Often times no, but we must be able to offer Ferrari performance when the customer wants it.

Model based PID design will almost certainly result in reaching optimized control faster than any other method discussed here. But is the time savings worth the effort in system modelling required to calculate the gains?

We provide auto tuning. It is MUCH faster than trial and error. He is an example of tuning a motor in torque mode. I was really testing the picture in picture feature.
https://deltamotion.com/peter/Videos/AutoTuneTest2.mp4
I kept this around because I get the motor tuned in 2 minutes. That is MUCH better/faster/precise than guessing.

Yes, having an accurate plant transfer functions comes with additional benefits over and above gain calculation. But will that really produce tangible benefits?

Yes! It helps with the design to. We call it "test at your desk". If you have a motion trajectory you must be able to achieve then you can program the trajectory. You can then adjust the built in system simulator until the desired results are achieved. Now you know the open loop gain, damping factor and natural frequency the real system much achieve.

And then there is what I THINK is the basis of Tom’s point. Is it really better for ME, as an engineer supporting customers, to embrace a design method that will EITHER require me to develop a suite of tools to support the method (think RMC Tools) OR try to manually drag my customers along as they try to learn the method?

Good question. I think it depend on the volume. RMCTools is great because we can debug systems all over the world because of the internet. Most people on this forum are supporting local customers. Can you show your customer a return on investment. I once did a project for Coors Tech, a spinoff from Adolf Coors. I saw what they were doing and I had to convince them they were doing wrong. They agreed to try and their defects fell dramatically. Unfortunately for us we didn't sell two more controller because now the one machine could do what 3 could do in the past.

Or is it easier to use a lower performance option that I can easily explain to others? Seems to me we are kind of asking Tom to fall on the sword in the interest of increasing the overall capability of the industry for very little gain to himself or his customers.

No doubt Tom has been successful doing his way. If my way would have ROI for his kind of systems then he would have had problems. Fortunately I was not in his market. That is also why the control guru, Doug Cooper, gave me some hits back in 2005. All I need are hints.



Good questions and comments.


BTW. our sales jumped over 10% this year. Much of our sales are export. About 40-45%. Being able to support people around the world is a must and that is why RMCTools is so important. RMCTools and the firmware are full of mathemagic. That is stuff you will not find in text books.

 

[Tom Jenkins]

Thanks for the support, Keith.

It is important to remember that wastewater treatment plants aren't run by engineers. The only poles they know of are used to break up floating sludge. They have to contend with 2:1 load swings from midnight to noon, slugs loads from industry and internal sidestreams that further double process loads, mass transfer coefficients that change by 50% during the course of every day, non-linear characteristics of flow control valves & blower curves, and non-linear variations in mass transfer as actual concentrations change. All of this supports a biological system with variable oxygen utilization rates in mixed liquor soup that takes 5 to 15 minutes to stabilize after a step change in airflow.

These guys don't care about theory, and they don't care about mathematical niceties. They certainly aren't going to change loop tuning on an hourly basis to match the response to the current load and process characteristics.

What they want is reasonable stability for the process and measurable improvement in energy consumption. In my experience that is more achievable when you get rid of PID. Here is a couple of real-world examples:

 

[Peter Nachtwey]

The article only tell me that someone doesn't know how to tune a PID. floating control is a PID without the P and D. I can see where the derivative gain would be a problem in your applications but a little proportional control should be an improvement.

mass transfer coefficients that change by 50% during the course of every day

I believe that. However, in both the floating control and PID case the integrator needs to be increased or decreased as a function of flow. Basically the integrator must be scaled by the flow. I bet this wasn't done. There was a recent thread where a forum member noticed this and asked why.


I read the pdf. Yes, the integrator for floating control can be set low or slow enough that is doesn't cause any problem but it increase response time. Are you going to tell me that the integrator on the PLC can't be set to the same value as in the floating control and there is NO value of the proportional gain that will make the response better?


I didn't see any information in the document that mentioned scaling gains as a function of flow or mass transfer. Basically, they just dumbed down the control to floating control. Even the floating control would work better if the integrator gain was scaled as a function of flow. Think about it. If the flow is higher then anything the integrator does will be diluted more by the extra mass or flow.



The document reminds of the fuzzy logic vs PID papers where it is evident the author didn't know how to tune a PID so he could make is fuzzy logic seem better.

 

[Tom Jenkins]

The article only tell me that someone doesn't know how to tune a PID. ...

And I'm sure you could do better, Peter. However, there are 16,000 treatment plants in the US, and you aren't available to all of them. I have rarely seen a PID-based control that matches the performance I achieve. Most engineers can't tune a PID properly, much less the average operator. Theoretical considerations don't mean squat - meeting operator expectations is the goal.

... in both the floating control and PID case the integrator needs to be increased or decreased as a function of flow. Basically, the integrator must be scaled by the flow. ...

Flow pacing has often been tried and has not been successful. The organic loading, which determines oxygen demand, isn't always proportional to flow. For example, industrial discharges, and internal plant events like running a belt press or decanting a digester can have huge impacts on organic load with a negligible change in flow rate. When it rains the first flush increases both the flow rate and organic load as the material settled in the sewers washes out. After that the flow rate is still elevated, but the oxygen demand decreases because the infiltration is DO saturated rainwater with no organic content.

I read the pdf. Yes, the integrator for floating control can be set low or slow enough that is doesn't cause any problem but it increase response time. Are you going to tell me that the integrator on the PLC can't be set to the same value as in the floating control and there is NO value of the proportional gain that will make the response better?

It is certainly possible, and I have often used proportional speed floating control. I've also used tricks like different gain on rising and falling controlled variable, and rate of change inhibit, and explicit ±tolerance on errors to bypass calculations. In some cases the distinction between PID and the algorithm I use is thin, and frankly, I don't care. I go by whether or not the operator is happy.

I didn't see any information in the document that mentioned scaling gains as a function of flow or mass transfer. Basically, they just dumbed down the control to floating control. Even the floating control would work better if the integrator gain was scaled as a function of flow. Think about it. If the flow is higher then anything the integrator does will be diluted more by the extra mass or flow.

This assumes a constant concentration of pollutants and a constant rate of metabolization of the waste. Neither is true. A dump from a candy processor, for example, is readily metabolized sugars. A dump from a packing plant is slowly metabolized (blood and other proteins).

The document reminds of the fuzzy logic vs PID papers where it is evident the author didn't know how to tune a PID so he could make is fuzzy logic seem better.

Well, I will certainly admit to a lack of expertise in PID. I also claim success in the control objectives, as illustrated by the paper. Nobody paid me to create a theoretically elegant algorithm. They paid for control with the accuracy illustrated in my article.

It doesn't matter, Peter, that you have the expertise to tune a PID loop to perform as desired. In the real world of wastewater, a system integrator grabs a standard PID off the menu bar, tunes it so it looks OK for a couple of hours of dry weather flow, and then gets out of Dodge. I built a business and reputation on doing better.

 

[Phrog30]

Well to put this to bed, Peter needs to get a water/waste water project and document things. Then we can see if he's all talk or not. Talk is cheap and easy.

I've used a RMC before but at this point I might go out of my way not to just by this thread alone.

 

[Peter Nachtwey]

Well to put this to bed, Peter needs to get a water/waste water project and document things. Then we can see if he's all talk or not. Talk is cheap and easy.

look a this
https://www.youtube.com/user/pnachtwey/videos?view=0&sort=dd&flow=grid
Do you really think I would have any trouble?

The control theory works. I think I have proven that I can develop control formulas from scratch. All I need is data to create a model. I have create models for valves that have about 15 different parameters.
https://deltamotion.com/peter/Videos/ValveID.mp4

Also, about the dead band. It is easy to see that a dead band can't be so wide it exceeds the noise. The noise keeps the PV centered in the dead band assuming the noise is Gaussian. There is also the matter of changing the gains as a function of flow.

I've used a RMC before but at this point I might go out of my way not to just by this thread alone.

I don't see why you are so upset. I am sharing information. The RMCs use the chain rule which effectively changes the gains as a function of the master speed. Actually it changes the feedforward terms. We can get the position from the master and use that to estimate the master's velocity and acceleration ( hard ). The slave axes make use of this data. Just gearing to position isn't good enough. There would always be following errors.


I don't mean to sound abrasive. I am trying to educate and let people know what is possible. The documents Tom posted seem similar to the paper that say fuzzy logic is better than a PID. Nothing is said as to why the PID failed. I can guess why. Just because there is a paper on something doesn't mean it is correct. I have shown all my work/calculations and have hidden nothing. When drbitboy said the dead band should be wider, I made another simulation using the same data but just a wider dead band to show drbitboy what would happen. I did that to educate on how to set the dead band even though I don't like dead bands. Many hydraulic valves have a dead band. We have code that does a decent job of trying to eliminate the effects of dead band. Otherwise the system will oscillate back and forth as the valve spool moves from one side, through the dead band, to the other side to change directions.

 

[Phrog30]

Peter, there are better ways to educate. I'll leave it at that.

And yes, I think you would have trouble, or at least understand what others have been trying to say.

 

[Peter Nachtwey]

Peter, there are better ways to educate. I'll leave it at that.

That isn't good enough. That is is what I call a hit and run comment. How would you do it better?
BTW, I text drbitboy often to suggest things. We really don't argue that much. I also have told him he puts too much into extracting data from the OPs that don't provide enough data. That is why I post my pulling teeth picture. Norm D, Pandiani, drbitboy and L [AR1,P#0] are able to learn these things. There may be more.

And yes, I think you would have trouble, or at least understand what others have been trying to say.

I understand. I simulated what drbitboy wanted me to simulate. I didn't argue, I just did what he wanted. I am good with that.

What I don't like is the pdfs that say they switch from PID to floating control without any evidence of the problems they had and why they had them. Again, I call this hit and run. No information is provided for a rebuttal. Floating control is simple because there is only ONE parameter to change. "Even a caveman can do it". I get it. It might be good enough for many applications but when Tom mentions how much things can change by a factor of two, I know that just having one fixed parameter for the integrator gain is not optimal. How can you ignore what another forum member said about needing the change the gains as a function of flow. I confirmed he was right to do so.
What I have added is that the integrator gain really should change as a function of flow. Second, I have pointed out the dead band should not be so wide that it ignores the noise. On another thread I pointed out why there is noise because the pumps output causes small pressure spikes. I can't see where this is wrong. Should I just let people be clueless?


The cars following a line is the same problem. The gains need to change as a function of the car speed. There are many application where the controller gains need to change because the process is speeding up or slowing down. This can't be ignored and still be optimal.



Controller gains can be changed on-the-fly. As conditions change.


BTW, PID works well most of the time but sometimes it needs to be augmented with the Smith Predictor to compensate for dead time and in motion control, feed forwards must be added.


Another option is model predictive control. In this case there are no gains. Yet is works and is good for compensating for dead time. The problem I have is that it is very CPU intensive but CPU power increases all the time.

 

[Tom Jenkins]

... The documents Tom posted seem similar to the paper that say fuzzy logic is better than a PID. Nothing is said as to why the PID failed. I can guess why. ...

First, I agree with you that fuzzy logic is a scam. I've never used it.

You don't have to guess why PID failed - I stated clearly that the issue is tuning.

1) The operators and engineers working with these systems are not controls experts, and their tuning skills will not match yours.

2) Because of the huge load changes and changes in mass transfer characteristics the tuning that provides stable and responsive control at midnight won't do the job at 8:00 AM and neither will do the job at noon.

Your concern about wastewater flow is a red herring. Oxygen demand from the organic load and the mass transfer characteristics of oxygen into the mixed liquor determine the relationship between airflow rate, the manipulated variable, and dissolved oxygen concentration, the controlled variable.

I've done feed-forward control, based on a process model. (See the attached paper) To make it work you need to have continuous real-time info on both the load and the oxygen transfer characteristics. This data isn't available in most plants, and the instrumentation I invented to provide it is too expensive for most of the market.

With all due respect, most temperature and motion control tasks are comparatively simple with regard to the number of variables of influence. Here is a partial list of the factors that influence process response when controlling airflow to maintain a desirable dissolved oxygen concentration:

Actual O2 concentration (higher actual dissolved oxygen decreases O2 transfer efficiency)
Mixed liquor suspended solids (amount of microorganisms) concentration
Wastewater Temperature (higher temperature both increases biological activity and decreases O2 transfer efficiency)
Air Temperature (affects air density)
Oxygen transfer efficiency of aeration device (varies non-linearly with airflow through the diffusers)
Surfactants and dissolved solids in the mixed liquor (affects oxygen transfer efficiency)
Organic load (higher load, of course, means more O2 demand)
Characteristics of load - simple vs. complex organics, amount of ammonia vs. organic compounds vs. H2S, etc. (each compound has a different O2 demand, and some compounds have specific organism requirements with differing metabolic rates)
Hydraulic residence time (at last we get to influent flow, which is what neophytes tend to fixate on, erroneously)

Each of these factors will vary continuously in the typical treatment plant, with 2:1 ratios on a good day and 4:1 or 5:1 common occurrences.

I won't argue with your elegant mathematics, and frankly, I'm not competent to do so.

To tell the truth I don't care about control theory. I will only state that for over forty years I have observed that consistently PID controls are not successful and the rude, crude inelegant methods I espouse are. You may be right in stating that is a result of ignorance on my part, and of the industry as a whole. I don't care.

 

[drbitboy]

Hydraulic residence time (at last we get to influent flow, which is what neophytes tend to fixate on, erroneously)

Guilty as charged, LOL.

Update:

F = Fouling factor = Ratio of aeration system performance after use to new aeration system performance, decimal

Ah Tom, you are a kidder (or maybe the EPA is): "Fouling factor" indeed. I may not know the process, but I know a Fudge factor when I see one!

 

[drbitboy]

This is a great paper:

Any inaccuracies will simply appear as an increase or decrease in αF.

TL;DR

This is reminiscent of something my Dad and his colleagues used to say. As I have mentioned before, my Dad used to be part of a group that tested large steam turbines, up to a GW and more (he used to call industrial turbines, e.g. for steam-power co-gen, "peanut roasters," but I digress).

There was one configuration, "cross compound" IIRC, where they could validate their calculations because the intermediate outlet steam was still superheated; in that situation, the double-check indicated their accuracy was better than a quarter of a percent, with a slight trend with throughput IIRC.

For every other configuration, they used to say

All the errors end up in the condenser.

 

[Tom Jenkins]

Ah Tom, you are a kidder (or maybe the EPA is): "Fouling factor" indeed. I may not know the process, but I know a Fudge factor when I see one!

The EPA has a really good sense of humor. Not only is F a fudge factor, but so is α. It is just so much more impressive to use Greek letters!

One could conclude that the whole industry is full of s...

 

[drbitboy]

The EPA has a really good sense of humor. Not only is F a fudge factor, but so is α. It is just so much more impressive to use Greek letters!

One could conclude that the whole industry is full of s...

You need an L in there.