PID vs floating control

[Peter Nachtwey]

Lately there have been threads that talk about floating control, input dead bands and input filters. I want to show that these KLUDGES are not necessary and are actually detrimental. Tom Jenkins has used floating control on sewage plants. Apparently the state doesn't change much so a very slow integrator ( floating control ) will work. However if the system state changes much or the set points change then a PID is the way to go. The problem is that most people do not know how to implement ( tune) a PID properly. The problem that Tom Jenkins was faced was dead time. If the floating control integrator is slow enough the dead time is not a problem until either the PV or SP change.


drbitboy wants to kludge his control system with input dead bands and input filters. I can prove this is not the way to go but the math gets deep. So in rebuttable, I have made a FOPDT simulation with a long dead time, 10 minutes. I also generate noise with a standard deviation of 3 degrees so there is lots of noise. I use an output filter instead. There are two plots. The first one shows the control output and the PV+noise. The second one shows the PV with out noise and the integrator term. The first part of the pdf just shows how I derive the controller gains. I am using the ISA form or dependent form of PID which is what most temperature controllers use.


Note, in the past I have bashed papers that say fuzzy logic is better than PID. I am able to prove the fuzzy logic advocates don't know how to tune a PID. I can show using their own numbers that I can tune a PID to work better than their Fuzzy Logic. The same goes for floating control.
https://deltamotion.com/peter/Mathcad/FOPDT/Mathcad - FOPDT PIDx.pdf

 

[BobB]

This is interesting Peter - I do a lot of work with swimming pools. Many have flow control. I have seen implementations where a flow meter has been input straight into a VSD and PID utilised. Unfortunately the flow meter goes all over the place and the system hunts like mad. Have also seen it done with a pressure transmitter - same result. The flow meter cannot really be placed in an ideal situation due to constraints in the plant room - too close to bends and the like - plant rooms are not leaseable space so they get belted down to an impossible size. I have developed a method where I add and subtract into the output channel of the PLC (analogue) and it works quite well. If the flow meter is wildly variable I extend the adjustment timers - if fairly stable I reduce the adjustment timers. I do not use filters or dead bands - just timers set to what is coming from the flow meter. I really wish that there was room in the plant room to place the flow meters in a straight section of pipe so that there could be a steady reading. I guess we have to adapt. I will be interested to see your comments.

 

[Peter Nachtwey]

My answer is WAY off topic. You probably know I have worked a lot with hydraulics. What I know for certain is that the flow from the pumps is not constant. There are vanes or pistons that push fluid out the exit ports intervals. In the big picture the flow seems constant but in reality it isn't at the millisecond level. I bet your flow meters are doing a pretty good job of measuring reality. You might find out fast you flow meter responds.

Water doesn't compress much so the little pulses of water increase the pressure. The pulse travel down the pipes at the speed of sound in water. So yes, you are going to see what looks like a lot of "noise" but I bet it isn't noise. So if your pump has 5 pistons or vanes and it is rotating at 600 rpm that is 10 revs per second. I your pump has 5 pistons or vanes then expect a pulse or pressure spike every 20 milliseconds.

drbitboy is going to like this answer. He is going to say "see, input filters rule!"
I like accumulators, they even out flow from pumps. Basically they are like a low pass filter on the input. This probably isn't an option for you.

So what I am going to suggest is to sample quickly relative to the 20 milliseconds I mentioned above. If the pump is spinning faster or has 7 instead of 5 pistons then the time between pulses is shorter. If the pump is turning only 60 rpm then the pulses will be 200 ms apart. Here is the problem. If your PLC is sampling out of phase with the pulses then the readings will be all over the place. So you must sample as fast as you can to try to find the high and low for the interval of a pulse. This time will change depending on the speed of the pump. PLCs are much faster now. Can you sample every 2 milliseconds? You should be able to capture readings close to the highs and lows. You can probably average them together. You could try averaging all the readings for a time between pulses but the length of time you would be averaging would vary as the speed of the pump changes.

I bet you didn't expect that.

 

[Tom Jenkins]

It seems to me the objective is to provide a control system that meets process objectives reliably. The algorithm used is a matter of indifference. If you accomplish the operator's goals with PID or floating control or any other technique then theoretical considerations on the algorithm are of academic interest only.

 

[Peter Nachtwey]

It seems to me the objective is to provide a control system that meets process objectives reliably.
The algorithm used is a matter of indifference.

if it works well enough, but no one should be led to believe PID bad and floating control good or floating control better than a well tuned PID. There is nothing magic about floating control. A PID will work too. PIDs can compensate for the dead time, within reason, and still respond faster than floating control. In my example the plant time constant is one minute and the dead time is 10 minutes.

 

[Steve Bailey]

but no one should be led to believe PID bad and floating control good

I don't see anything in this thread that suggests that. But since Peter linked Tom to floating control and lumped floating control in with

these KLUDGES

Tom's response is appropriate.

 

[Phrog30]

It seems to me the objective is to provide a control system that meets process objectives reliably. The algorithm used is a matter of indifference. If you accomplish the operator's goals with PID or floating control or any other technique then theoretical considerations on the algorithm are of academic interest only.

Absolutely. It's like everything else these days, if someone doesn't agree it's wrong.

Maybe too much time spent in a liberal state, sorry couldn't resist.

 

[lfe]

It seems to me the objective is to provide a control system that meets process objectives reliably. The algorithm used is a matter of indifference. If you accomplish the operator's goals with PID or floating control or any other technique then theoretical considerations on the algorithm are of academic interest only.

Quite agree, after having used a couple of algorithms taken from books, at the end I invented a fully floating one which is the one that worked best.

 

[Peter Nachtwey]

Tom has been anti PID. He has claimed that floating control is more stable than PID and that PID doesn't work well with long dead times.
Tom, go search your past posts.

One the first point, Tom is wrong. Stability occurs when the closed loop poles are in the left hand side of the S-plane. I can place the closed loop poles are. I usually place them on the negative real axis in the s-plane so that the response will not over shoot. Floating control is only stable if the integrator is very low compared to what can be achieved with a PID. Some second order systems are under damped to begin with so adding only an integrator term is making things worse.
PIDs don't do well with very long dead times. If the dead time is long, a PID will not do much better than floating control. However, if a Smith Predictor is added, it can compensate for the dead time, noise and lack of feed back resolution.


If performance is not an issue then floating control will do and it doesn't take much effort. Floating control is very simple. If performance is an issue and process errors or lack of response costs money then it is worth while to learn more advanced techniques because it will pay off in the end.

Quite agree, after having used a couple of algorithms taken from books, at the end I invented a fully floating one which is the one that worked best

That is because you don't fully understand PID yet.


I am attaching a link to a pdf that shows a comparison between floating control and a PID augmented with a Smith Predictor. I show all the calculations. The two implementations use as much the same code as possible. I simulate dead time, noise and feed back resolution. The floating control integrator constant must be very long to get the best result. I also implemented a dead band so the integrator will not hunt. This causes a slow response relative to the PID with SP.
https://deltamotion.com/peter/Mathcad/SOPDT/Mathcad - SOPDT SP vs FC.pdf


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.

 

[drbitboy]

Hey @PeterN,

I noticed in your SOPDT PDF, that in the last plot (p. 15/15) the CO is drifting up at the end. Is that expected? Did the floating control overshoot a bit and that is the recovery?

Also, I was under the impression that floating control as practiced by @TomJ used a dead band on the input, as it is not meant for fine control, presumably because the profit characteristic is flat near the set point (e.g. Dissolved Oxygen in wastewater treatment).

 

[Peter Nachtwey]

Hey @PeterN,
I noticed in your SOPDT PDF, that in the last plot (p. 15/15) the CO is drifting up at the end. Is that expected?

It isn't unexpected because there is a +/- 3 degree dead band in the floating control simulation and both simulations have a lot of random noise added to the PV with a standard deviation of 3 degrees. This means 35% of the reading will be outside the dead band. The floating control will react to that. The noise should actually be helpful at keeping the PV at the SP.

Do you want me to change the dead band or the noise and run it again? I could set the noise to 0 just to show what happens.

Did the floating control overshoot a bit and that is the recovery?

Yes, that is the way integrators work. The integrator term winds up and then unwinds to reach a steady state value. The integrator is proportional to the difference of the areas below and above the SP.

Also, I was under the impression that floating control as practiced by @TomJ used a dead band on the input, as it is not meant for fine control, presumably because the profit characteristic is flat near the set point (e.g. Dissolved Oxygen in wastewater treatment).

Look at page 13/15. I implemented a dead on the error between the the SP and PV. There is a variable called dead_band. It is set to +/- 3 degrees.

i could have plotted the error by itself to show the PID+SP error is less than the floating control's dead band. When the floating control reaches the dead band, in theory the PV should go back and forth between the high and low limits. Because I generated random noise that exceeded the limits the noise should cause the integrator to bring the PV to the SP. This won't happen if the there is no noise or the noise doesn't exceed the dead band. So!, if you are going to implement a dead band , set it so there is at least a little noise that is greater than the dead band. Does this make sense?

 

[drbitboy]

Ah thank you!

Sigh. I apologize for missing some (rather obvious!) items (you think "dead_band" woul have been somewhat of a clue LOL). So much to take in from your posts, but that is no excuse.

So if the CO is drifting up, am I to understand it is because there are [PV signal plus negative error "measurements"] below the lower limit of the dead band? Or at least more frequent, on average, than [PV signal plus positive error "measurements"] are above the upper limit of the dead band?

Anyway, this has been fun. I'm in Trondheim Norway (aqvavit and pickled herring, yee haa!), still in quarantine for another day or two, with family so my posts have been brief and not as well thought out.

Merry Christmas and Happy New Year to @PeterN and all!

 

[drbitboy]

Do you want me to change the dead band or the noise and run it again? I could set the noise to 0 just to show what happens.

Actually, what would be interesting from the aspect of our other thread would be to increase it to 9 (3σ) and then maybe add some drift to the CO-to-PV model/relationship, analogous to a process load change*. Obviously my expectation would be that the PV signal, i.e. sans noise (x[n+1]?), would deviate (drift) slightly from SP, to be continually corrected by CO moves.

* Maybe a slow, low-amplitude sine wave, representing diurnal temperature change affecting the performance of a cooling or heating device in the process.

 

[Tom Jenkins]

Peter, I don't see any point in making this personal.

I have said many times that, in my experience, floating control works better for processes with long lag times. You allude to PID shortcomings in long dead-time processes in your posts. I have also stated that in my experience the typical operator finds tuning of floating control simpler, more accommodating to load and process parameter changes, and more intuitive than tuning PID. In my experience, the floating control algorithm is more forgiving of tuning errors than PID.

I don't pretend to understand the elegant mathematics associated with control theory, and that doesn't bother me a bit. I have yet to meet an operator that wanted to see a Bode Diagram or had one ask for a Smith Predictor. The guys in the plant just want to see a process trend with the controlled variable maintained within their parameters. I've done it with PID, and I've done it with floating control. Of the two my experience is that floating control works better in the processes I control.

There is a cottage industry based on tuning PID loops. That includes dozens of books, hundreds of magazine articles, various software, so-called self-tuning algorithms, etc. It has always seemed to me that an algorithm that needs that much support may have some flaws. But that's an opinion, and all are entitled to their own.

I have offered support and suggestions to use floating control many times over the years. If my attempt to help is successful, I'm glad. If my opinion is ignored, that's OK with me too.

 

[Peter Nachtwey]

Peter, I don't see any point in making this personal.

I am trying not to.

I have said many times that, in my experience, floating control works better for processes with long lag times. You allude to PID shortcomings in long dead-time processes in your posts.

Yes, but anything without some way of predicting what will happen will suffer. The floating control is just a PID without the PD terms.


I really tried to make the floating control look as good as I could. I couldn't make the time constant any shorter or the response would oscillate. I added noise that was more extreme than the dead band so as long as the noise is Gaussian, it will move the PV to the SP.

I have also stated that in my experience the typical operator finds tuning of floating control simpler, more accommodating to load and process parameter changes, and more intuitive than tuning PID.

The operator doesn't know what is possible. Obviously adjusting only an integrator time constant is easier than adjusting 3 gains but does it really work better?

In my experience, the floating control algorithm is more forgiving of tuning errors than PID.

If you know where you are placing the closed loop poles then there is no problem. What I/we have done with our motion controller is given the person tuning the system ONE slider bar that moves the closed loop poles along the negative real axis and THEN calculates the gains. There are about 30-50 people on this forum that have done this.

I don't pretend to understand the elegant mathematics associated with control theory, and that doesn't bother me a bit. I have yet to meet an operator that wanted to see a Bode Diagram or had one ask for a Smith Predictor.

If they don't know they won't ask. Now the people on this forum know. Bode plots are not that useful when the response is slow.

Then one must know what they mean.

The guys in the plant just want to see a process trend with the controlled variable maintained within their parameters. I've done it with PID, and I've done it with floating control. Of the two my experience is that floating control works better in the processes I control.

I get that. What about doing it better? Is there a return on investment?

There is a cottage industry based on tuning PID loops. That includes dozens of books, hundreds of magazine articles, various software, so-called self-tuning algorithms, etc. It has always seemed to me that an algorithm that needs that much support may have some flaws. But that's an opinion, and all are entitled to their own.

What support? The tuning algorithms are easy and complexity "hidden" from the operators. The real trick is finding an accurate model. Calculating the gains is easy.

I have offered support and suggestions to use floating control many times over the years. If my attempt to help is successful, I'm glad. If my opinion is ignored, that's OK with me too.

For a PLC forum that is fine. It is better than nothing and is understandable. I just raised the high bar a bit. Now the question is it worth it to take the time to understand my pdf in order to get faster response.

There is a reason why programs like Expertune and Control Station exist. The problem is that I have provided Python code that will calculate the plant parameters and the gains in the past. It largely gets ignored as I said in the other thread.


Also, I hope that my comments about how to adjust the dead band relative to the noise helps those that use floating control.


About the books. Too many are written by people that don't have real experience. Too many just cite other people.