PID tuning woes

[mobil1syn]

I have long since stopped caring whether OP is still engaged. You provided the answer in Post #2 (only because you got there first ), the rest has been my attempt at exposition. It's past the Friday deadline, so they either listened to you and succeeded or they didn't.

i am still following along, i really do appreciate the effort and knowledge that you and peter have shared.

in the O&M call last week i told them i am out of ideas to achieve the desired results on the flow characteristics. gave the design engineer the trend data and told him see if there is someone in his company who has some ideas on how to make this work, but that doesnt mean i am just going to give up and wait for an answer.

flow and tank level all over the place, but the unit didnt shut down. tomorrow i will probably reduced the P on the p300 to try to increase response time. there is the one blimp on the flow trend when i got a HH level on t300 because p300 was slow to response.

so friday afternoon i reduced the P of 21 that MaxK suggested to 15 to reduce the flow variations. the system ran all weekend. and from the daily data email (values are only taken every 5mins but it something) the UV system was able to bring online another section without tripping so the increase in flowrate was within its capabilities.

i am going to read through drbitboy post a few more times and come up with a plan to try to incorporate a P only approach.

i also may take the ask for forgiveness than permission and move the PID to a periodic operation.

 

[mobil1syn]

the system does a data dump nightly, sample rate is every 5 minutes so its not terribly useful but it shows T-100 is handling things well. T-3 never gets to a calm state.

 

[drbitboy]

Assuming you are using @MaxK's system tuning parameters, then those PIDs outputs are still dominated by the Integral action, which is badly mismatched to the process, Everyone should be confident in those K_p and K_i values, so I will bet all the money in @MaxK's pockets the fundamental reason for that mismatch is that the PIDs are still in the continuous task, and also that you have not yet fixed and/or changed the Loop Update Time parameters in the PID Configuration menus.

If you change them to something like 0.005-0.010s, there is no doubt in my mind that those levels and flows will both smooth right out.

I understand if you are hesitant to take advice like this from the 'net; but you came to us, plus by this point you may be under suspicion for having caused a few trips so far when trying to tune the system. But whoever set up these PIDs did it wrong, and if you cannot reconfigure the PID program to put them into a 500ms periodic task, then this is the only way to fix it. It is far from ideal, and @Peter Nachtwey may justifiably mock me because it's a band-aid not a proper fix.

So IFF those Loop Update Times are still 0.5s and the two orders of magnitude decrease I am suggesting seems like too radical a change, then try decreasing them by about 10-20% about an hour or so after the next backwash/decant finishes: I am fairly certain you will see a slight improvement over the following few hours; it will certainly be no worse. You might want to do that to the T1/P1 loop only first, as that loop already reaches stability, if barely, so this small change cannot make it significantly worse. If you don't see a noticeable improvement, continue with decreases of 10-20% as long as it does not get worse, but don't go below 0.005-0.001s.

The question is, ...

 

[drbitboy]

 

[drbitboy]

i am still following along, ...

Whoops, I didn't see this post when I wrote the last one (two, punk ).


I think incremental small decreases of the loop update time of t1/p1 is a decent intermediate step.

I don't know what the political situation is, but if you can get anybody, anybody, who has some process and PID credentials in either organization (look for a gray-haired Chemical Engineer who survived, or a sharp young one), then get them to look at the program and point out the PIDs that are running in the continuous task, and the problem should get solved immediately. Competent engineers who have identified a problem have neither time nor patience for political baloney, nor any fear of managers.

 

[mobil1syn]

I understand if you are hesitant to take advice like this from the 'net; but you came to us, plus by this point you may be under suspicion for having caused a few trips so far when trying to tune the system. But whoever set up these PIDs did it wrong, and if you cannot reconfigure the PID program to put them into a 500ms periodic task, then this is the only way to fix it. It is far from ideal, and @Peter Nachtwey may justifiably mock me because it's a band-aid not a proper fix.

The question is, ...

i aint scared. it is known that there are issues, there is a lot of fingers being pointed at the UV company (which i dont agree with, its a flow issue) for their to really be any expectations or people counting downtime.

also, i have parameters that "work", so zero down side to get aggressive in my opinion.

Tank 1 loop PI settings: Kp = 12.5 Ki = 0.0078

Tank 2 loop PI settings: Kp = 21 Ki = 0.0133

using these values, but a Kp of 21 would get the tank values close to trip on LL and HH, dropping down to 15 seems to have cured that.

I don't know what the political situation is, but if you can get anybody, anybody, who has some process and PID credentials in either organization (look for a gray-haired Chemical Engineer who survived, or a sharp young one), then get them to look at the program and point out the PIDs that are running in the continuous task, and the problem should get solved immediately. Competent engineers who have identified a problem have neither time nor patience for political baloney, nor any fear of managers.

i am going to **** around with a few things tomorrow and am heavily considering with just making the changes myself on weds and dealing with the fallout. we shall see

 

[drbitboy]

Here are a couple of P-only solutions, attached as a .ZIP. The tunings are estimates, acceptable values should be close but should be findable by trial and error (or modeling with better models i.e. more data such as pump curves).

The ones with _4k_ in the filenames use the current scaling, as far as I could tell i.e. with the two [0-4095] min-max pairs in the PV section.

The ones without _4k_ in the filenames use a more sensible scaling for PV, but the KL_p has been adjusted so the system behaves in exactly the same way.

The model is basically the same as what OP provided (64" diameter by 5ft high tank 1; 96" diameter by 6ft high tank 2), with the diameters scaled so that it has the same effective tank gains running 500 times faster, so instead of a 12h (43200s) decant on-off cycle, it has an 86.4s (= 43200s / 500) cycle.

The key to this working is getting the correct percentage into the output bias.

For Tank 1/Pump 1:

• Output Bias = 73.333% (Tuning tab)
  • I estimated that CV=73.333% was where the pump runs at a flowrate of 100gpm, equal to the base load of 4 wells only i.e. no decant flow.
  • So 73.333% is what I used for the PID Output Bias
  • That 73.333% is only an estimate on my part.
    • At this point, you can wait a few hours after the end of a decant, i.e. after the PID, as currently tuned, has finally settled down, to determine what the base load bias actually is, and use that instead.
    • Another option would be to put the PID into manual and manually tweak the CV output until the level seems reasonably steady, and then use that value as the Output Bias
• Setpoint = 1.0ft (Tuning tab)
  • For a P-only PID, the level setpoint is not a target level that the PID will chase as the input flow rate changes
  • Instead, the PID instruction uses the Setpoint parameter as a nominal value to determine the level at which the PID algorithm will set the CV to the Output Bias value
  • To ensure the tank does not run dry at that base load, I set the setpoint to 1.0ft,
    • So there is some room for the PID to tell the VFD to run the pump slower if the base load drops below that 100gpm causing the level to drop below the nominal 1.0ft Setpoint.
• Kp[/p] (Tuning tab)
  
  • The gain configures how much the PID changes the CV as the level changes.
  • In my case, I chose a target level of 4.0ft to be the point at which the CV will cause the pump to match the [base load + decant] flow rate of 115gpm.
    • I estimated that 155gpm to correspond to a CV of 80.333%
      • Again, you could determine the actual CV% value empirically during a decant.
    • The 4.0ft upper level leaves some room for the PID to increase the output if the [base load + decant] flow exceeds 115gpm.
  • To recap, I want
    • CV = 73.333% at PV (i.e.level) = 1.0ft
    • CV = 80.333% at PV = 4.0ft
  • So the PID gain I want to see is (80.333-73.333) CV% / (4.0-1.0)PVft
    • The PID gain should be 7/3 CV%/PVft
  • The PID instruction's K_p gain is kind of unitless, but is actually expressed in units of CV%/PV%,
    • and PV% = (PVft / 4095ft) * 100%
    • or PVft/PV% = (4095 / 100).
  • Substituting that back into the PID gain,
    • PID gain = 7/3 CV%/PVft
    • = 7/3 CV%/PVft * (4095/100) PVft/PV%
    • = (7/3) * (4095/100) CV%/PV%
    • K_p = 95.55
  
  

That's it; the rest of the PID settings tabs are the same as OP has shown before.

Again, my estimates for the Output CV% are just that: estimates. A safer play might be to run the CV%=50% at 0.5ft, and CV%=85% at 5.0ft, so the full range of the pump would be available at levels which neither overflow nor drain the tank.

• Output Bias = 50% (CV Low Limit, Configuration tab)
  • => 50gpm
• Setpoint = 0.5ft level (assuming this will not harm pump)
• K_p = 318.5
  • Target 85% CV (CV High Limit, Configuration tab)
    • 125gpm, so 10gpm headroom over max inflow
  • Target 5ft level (assuming this will not overflow tank)
  • Level Range, ft = 4.5ft (Target 5.0ft - Setpoint 0.5ft)
  • Level Range, % = 0.1099% = 100* (4.5 / 4095)
  • CV Range = 35% (Target 85% - Bias 50%)
  • K_p = 318.5 (= 35% / 0.1099%)

 

[drbitboy]

using these values, but a Kp of 21 would get the tank values close to trip on LL and HH, dropping down to 15 seems to have cured that.

Did you consider dropping the K_i value instead? The Integral action is almost certainly dominating and causing this oscillating system behavior. I still think dividing the K<sub>i[/values] (Tuning tab) by 90 would achieve @MaxK's expected results, but the same effect could achieved* by doing the same with the Loop Update Time (Configuration tab).

* and more rationally vs. implementing a second wrong to make a right.

I can almost feel @Peter Nachtwey shaking his head, because I am suggesting tweaking values to try to waddle our way to a better control, when modeling is the way to go. And I agree with hime, but in this particular case, being a typical PLCtalk thread, the forum does not have enough information to make a model accurate enough to effect the cure, although we do have enough information to diagnose the general nature of the illness.</sub>

 

[Peter Nachtwey]

I can almost feel @Peter Nachtwey shaking his head, because I am suggesting tweaking values to try to waddle our way to a better control, when modeling is the way to go.

Yes! but you are doing it wrong. My beef is not with you or even mobil1syn. mobil1syn is not being provided good engineering support by his management.

@drbitboy, what we agree on is that P only gains will work well enough. We also agree that what happens in one tank or part of the system will affect another. I have proposed a bias to the proportional bands. I think we agree that the integrator is not helping the system since the bias will substitute.

So what are the best parameters for the bias and the min and max values for the proportional band for each tank? It would also be good to know the down stream flow requirements.

The way this is done is to develop a cost function. This can be the sum of square errors between desired flows and actual flows, desired flow rates and actual flow rates or desired levels and actual levels. There are algorithms like BFGS that can minimize the sum of squared errors of the cost function. Even Nelder-Mead can do it.

Most people are not aware this can be done. In a way this is doing the same as linear quadratic control but in a more general sense.

When you can write a good cost function and then minmize it, the world is suddenly different. You see the waste, confusion, and inefficiency.

 

[parky]

Wow, can this post get into the guinness book of records

 

[MaxK]

so friday afternoon i reduced the P of 21 that MaxK suggested to 15 to reduce the flow variations.

Wow! And now you avoided flow variations? INCREASE Kp 5-10 times and see what happens. (due to the chaos in scaling I think trial and error will be faster).

[*]K_p = 95.55

[*]K_p = 318.5 (= 35% / 0.1099%)

Not knowing the measurement range of the sensor?

 

[drbitboy]

Wow! And now [OP] avoided flow variations? ...

Yah, I thought the same thing.

[drbitboy] Not knowing the measurement range of the sensor?

Yah, I assumed it is set up the same as previous Post #50, and from the same post we know it it is a 0-5PSI* sensor driving 4-20mA to a PLC analog input channel, and that input is being scaled to feet of level.

* 0-11.53... feet of head

What did you assume for the range?

The model is rock-solid stable with a P-only gain of up to at least 819.0 (= 4095/5) for tank 1. Admittedly the model has no noise or output dynamics (delays), but this process is so slow I am pretty sure those do not matter.

 

[drbitboy]

When you can write a good cost function and then minmize it, the world is suddenly different. You see the waste, confusion, and inefficiency.

Hakuna Matata is one of the few solutions that can make it bearable ...

Also: LOL. I did not know Peter was such a poet.

 

[drbitboy]

You see the waste, confusion, and inefficiency.

Wow, can this post get into the guinness book of records

Yeah, we hit a century on this thread, when nearly a week ago OP had enough information to change two numbers in about half a minute, been the hero, and moved on.

Bloody typical.

Hakuna matata.

 

[drbitboy]

When you can write a good cost function and then minmize it

Um, the cost function here is a Heaviside function: don't trip the process.

Minimize that.