PID tuning woes

[parky]

usiwe na wasiwasi

 

[drbitboy]

usiwe na wasiwasi

bcopy .

 

[drbitboy]

Btw, from the logging plots a few posts ago, around 12:00:00 the Pump 2 flow went from its VFD's min to max range (65gpm to 140gpm) in about half an hour, with no trip.

That's a rate of change at least 2.5gpm/min, with no trip from the UV system, counter to how OP understood the process originally.

So I think the trips to avoid ("cost functions") are the Tank HH (and LL?) level alarms.

 

[drbitboy]

(due to the chaos in scaling I think trial and error will be faster)

Not to mention the political chaos .

 

[mobil1syn]

todays test is setting update time to .010 and going back to 21 on the Kp to test MaxK settings.

got a lot of weather last night and this morning causing others issues, so i cant babysit things enough to make aggressive changes.

 

[drbitboy]

todays test is setting update time to .010 and going back to 21 on the Kp to test MaxK settings/

This will prove it was done wrong in the first place, and possibly pave the way to fixing it via periodic task or a timer.

 

[MaxK]

I'm a total noob at PID blocks. So can anyone answer my follow up questions?

1. Process value (PID input)
- Sensor: 0 ft = 4 mA, 11,536247 ft = 20 mA. Correct?
- Analog input (12-bit ADC) 0 mA = 0, 20 mA = 4095. Correct?
What value is fed into the PID input, i.e. How is the recalculation done?

2. PID “formula”

CV(t) = Kp*E(t) + Ki*I E(t) dt + Kd* dE(t)/dt Correct?

3. Control value (PID output)
- Output Bias = 73,89%. It means if PID-formula output = 0 then PID block output = 73,89%, PID-formula output = 1 then PID block output = 74,89%, PID-formula output = -1 then PID block output = 72,89% Correct?
The Output Bias has no action on the PID controller gains. Correct?
- CV Low Limit = 50% CV High Limit = 85%. WHAT DOES IT MEANS?
- Loop Update Time = 0.5 secs. It means dt = 0.5 for Integral term (U(i)=U(i-1)+Ki*E(i)*dt), but PID block calls by some timer. Correct? (special thanks to AB programmers)

4. Pump controlled by powerflex 525
- How is the PID block output scaled to powerflex 525 frequency?
- P1 flow min is 50gpm (30hz), max 125gpm (51hz). 50gpm /30hz = 1.667, 125gpm / 51hz = 2.45 - such a non-linear performance characteristics.
- P2 flow min is 65gpm (30hz), max 140gpm (54hz). 65gpm /30hz = 2.167, 140gpm / 54hz = 2.6 - such a non-linear performance characteristics.

 

[MaxK]

This will prove it was done wrong in the first place, and possibly pave the way to fixing it via periodic task or a timer.

For example it possible to find level derivations (flow mismatch) then calculate required pump flow to stay at level limits at given time (“Derivative-based control” chart). But many difficulties must be overcome along the way.

Btw, from the logging plots a few posts ago, around 12:00:00 the Pump 2 flow went from its VFD's min to max range (65gpm to 140gpm) in about half an hour, with no trip.

That's a rate of change at least 2.5gpm/min, with no trip from the UV system, counter to how OP understood the process originally.

So I think the trips to avoid ("cost functions") are the Tank HH (and LL?) level alarms.

I had the following plan to tune the PID controller:
Stage 1: find PI settings for “stable” levels (as example #28 curves).
Stage 2: then clarify terms and conditions (requirements and limitations) then gently step by step fine-tune PI (as example “Fine-tuned PI” chart).
I think it's more realistic

 

[Peter Nachtwey]

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

If your are referring to the number of posts then no. Paula's 'learning by doing" thread has this one beat by many times. I think we have 600+ more posts to go.

I have run out of popcorn. I need to buy some more.
I can't believe all the effort drbitboy has put into this. This is pulling teeth without Xylocaine. MaxK is basically verifying drbitboy's simulations.

 

[parky]

Won't take you long now then
I'm off to sunnier climes next week for a month perhaps when I get back it's made it.

 

[drbitboy]

Caveat: this reply is based on a combination of reading documentation, reading what OP wrote, and my empirical experience.

I'm a total noob at PID blocks. So can anyone answer my follow up questions?

Yeah I had to shave the yak a bit on this one too, especially because of the multiple and synergistic mistakes made by whoever handed OP this hot mess.

1. Process value (PID input)
- Sensor: 0 ft = 4 mA, 11,536247 ft = 20 mA. Correct?
- Analog input (12-bit ADC) 0 mA = 0, 20 mA = 4095. Correct?
What value is fed into the PID input, i.e. How is the recalculation done?

This is the easy one, and was done correctly: the analog input card has its own configuration block that includes scaling. So the 0-4095DN raw value, LT100.Input (Unscaled Input), does not have to be seen or used outside the analog input card's configuration block: it writes the 0-11,53ft result of its internal scaling directly to tag LT100.Value (Scaled Output), and I am fairly certain that LT100.Value tag is the value fed to the PID as Process Variable (PV). The key thing to understand is that this scaling, as defined in the configuration block of the analog input card (left side of image below), happens upstream, and independent of, any PID-internal scaling.

So at this point, we have a PV, in engineering units of ft with a range of 0-11,53ft, fed to the PID. In practice, the actual range of possible values is 0-5ft, but that does not matter. We can see this card-scaled PV input to the PID block (after PID-internal scaling; more about this later), with an instantaneous value of 2.2654305, between the Setpoint and the Error, near the bottom of the PID Scaling tab on the right side of this image:

The next thing to consider is the PID-internal scaling, defined in that same Scaling tab of the PID configuration block above. Apparently, either not all input cards have scaling from raw DN (Data Number) to EU (Engineering Units) built in or some people choose* to not use that feature of the input card, so Allen-Bradley decided to include a PV scaling option in the PID itself; that option comprises the two Max/Min pairs of values in the Process Variable (PV) block at the top of the PID Scaling tab. So the PID PV input tag, LT100.Value, has a position somewhere in the PV Unscaled Max/Min range, and that is linearly scaled to the Engineering Unit Max/Min range. The EU number would be only for display; both Max's represent 100% of the PV% input range, and both Min's represent 0% of the PV% range. Here we see the first hint that the original coder (not OP) has a comprehension problem: since they have already scaled LT100.Value to engineering units in the AI card configuration, the Max/Min entries are identical 4095/0 pairs, so the PID-internal scaling is 1:1, which is fine. But those ranges are 819 times larger than the possible input value range (0-5ft). So even though the PV% range is 0-100%, the practical PV% will be 0-0.122. The math will still work, of course, but gains will have to be increased by a few orders of magnitude to compensate for this. It's not a fatal mistake**, but it's a telling one.

* e.g. it would be simpler to traing maintenance staff to have a standard "default scale 1:1 i.e. 0-4095 to 0-4095" policy when installing a new AI card, so less needs to be done at 3AM when an old AI card fails.

** Up to a dozen bits of resolution are lost in the REAL mantissa, but that leaves another dozen to do the job, and the raw AI resolution is only 12 bits anyway.

So at this point we have the PV input to the PID as an EU value of 0-5ft and as a PV% value of 0-0.122%

2. PID “formula”

CV%(t) = Kp*E%(t) + Ki*∫E%(t) dt + Kd* dE%(t)/dt + OutputBias%

Correct?

Yes, close, now correct with the added + OutputBias% term above; I also added % suffixes to all PV- and CV-related values; N.B. Error is linear with PV.

Also note that

• the Integral term is implemented via a persistent PID-internal Integral Accumulation value,
  • so the PID instruction on any one scan need only have the current input values and the previous scan's accumulation, and
• that Integral Accumulation value
  • is updated on each scan by the that scan's discrete Integral term calculation
    • Ki*∫E%(t) dt is implemented as K_i*ΣE%(t) Δt,
    • so the per-scan calculation is IntegralAccumulation = IntegralAccumulation + K_i*E%(t) Δt
  • may be modified by other function of the PID implementation e.g.
    • Anti-windup reset
    • Bumpless transfer
    • etc.

3. Control value (PID output)
- Output Bias = 73,89%. It means if PID-formula output = 0 then PID block output = 73,89%, PID-formula output = 1 then PID block output = 74,89%, PID-formula output = -1 then PID block output = 72,89% Correct?

Yes. Note that, in operation when Setpoint% = PV% (so Error% = 0)and a non-zero K_i, any OutputBias% will have effected an offset of the same magnitude and opposite sign in the persistent PID-internal IntegralAccumulation term. So OutputBias% usually has relevance only when K_i=0.

The Output Bias has no action on the PID controller gains. Correct?

Yes

Before we get to CV Low Limit and CV High Limit, I want to cover CV% scaling, i.e. the Control Variable (CV) section of the PID Scaling tab. This is where the PID-internal CV% range of 0-100% gets scaled to some other units, let's call them CVEU; internal to the PID these values are called .MAXCV and .MINCV.

The relevance here is that the PID gains scale some form (E%, ∫E%dt, dE%/dt) of the error, as a percentage of the PV range, to CV%, as a percentage of the CV range. .MAXCV and .MINCV define the 100% and 0% tiepoints of the CV% value to those "other" CV units.

Just to reiterate this key point: the CV Max (at 100%) and CV Min (at 0%) values in the PID Scaling tab define what the magnitudes of the PID gains mean, in concert with the PV Max and Min values on the same tab.

In our case, it's 1:1 and those other units are 0-100%; downstream of, and external to, the PID, those other units are scaled to 0-6000cHz in an AOI and sent to the VFD as a frequency.

- CV Low Limit = 50% CV High Limit = 85%. WHAT DOES IT MEANS?

These are clamping values to limit the CV% value output by the PID. They are independent of the CVEU values (.MAXCV and .MINCV) mentioned above. If the PID instruction calculates a CV% that is outside this range, then the output CV% is set to the nearest limit. I would assume they also come into play with Anti-Windup Reset.

In our case, apparently they want a lower limit of 50% (30Hz) to be sent to either Pump's VFD, and upper limits of 85% (51Hz) for Pump 1 and 90% (54Hz) for Pump 2.


N.B. these do not change any scaling that relates to the PID gains

- Loop Update Time = 0.5 secs. It means dt = 0.5 for Integral term (U(i)=U(i-1)+Ki*E(i)*dt), but PID block calls by some timer. Correct? (special thanks to AB programmers)

Yes.

The Loop Update Time parameter value in the PID configuration tells the PID instruction the actual update time, i.e. period, at which the PID instruction execute. The PID instruction has no way to check if the value is correct; neither does the PID instruction choose when to run based on that value. The PID instruction makes it calculation according to the formula above on the unquestioned assumption that the configured Loop Update Time value (Δt) is correct.

The recommended scheme for ensuring the PID executes at the period specified by the Loop Update Time value is to place the PID in a periodic task with the same period.

The primary mistake of the original coder was to specify the Loop Update Times as 0.500s (500ms) while placing the PID instructions in a continuous task, where they ran at about 5.5ms. From the PID equation above, it should be clear that this effectively increase the Integral-action gain by a factor of ninety.

4. Pump controlled by powerflex 525
- How is the PID block output scaled to powerflex 525 frequency?

The 0-100 CV values, actually 50-85 or 50-90, after clamping, from the PIDs are passed to an AOI where they are multiplied by 60, so 100 become 6000. I am pretty sure that is cHz i.e. 6000cHz = 60Hz.

- P1 flow min is 50gpm (30hz), max 125gpm (51hz). 50gpm /30hz = 1.667, 125gpm / 51hz = 2.45 - such a non-linear performance characteristics.
- P2 flow min is 65gpm (30hz), max 140gpm (54hz). 65gpm /30hz = 2.167, 140gpm / 54hz = 2.6 - such a non-linear performance characteristics.

Yes, with a sand filter and centrifugal pump curves, the Hz-to-gpm relationship is not only non-linear, but it probably changes over time.

For simple modeling I suspect linear interpolation between those tiepoints is good enough, which is what I have done.

 

[mobil1syn]

so here is the trending from todays experiment, tried .005 and .001 yesterday on the update time and it was too slow to respond. so i went with .1 this morning and things went ok. i am just focusing on T1 and will deal with T2 when i get a handle on T1.

it handled the decant input just fine, but did not adjust once the decant stopped. i let it run until P1 went off on low level to give it as much time as possible. is dropping the 12.5 to 8 the best solution to close up the oscillation?

 

[drbitboy]

so here is the trending from todays experiment, tried .005 and .001 yesterday on the update time and it was too slow to respond. so i went with .1 this morning and things went ok. i am just focusing on T1 and will deal with T2 when i get a handle on T1.

it handled the decant input just fine, but did not adjust once the decant stopped. i let it run until P1 went off on low level to give it as much time as possible. is dropping the 12.5 to 8 the best solution to close up the oscillation?

Are we still scaling LT100.Value (LT100 AI_Handler Properties, Parameters tab, in feet) over the PV range 0-4095 Unscaled and 0-4095 Engineering Units (PID Scaling tab)?

And does that latest trend show a decant cycle from about 08:00 to around 10:37?

Assuming PV scaling of PV=LT100.Value is still 0-4095, I think you need to increase K_p, and effectively decrease the integral gain by dropping the Loop Update Time.

 

[mobil1syn]

scaling is the same as it has always been like shown in post #116

yea decant was 8:00 to 10:30ish. after i had started the trend i was kicking myself for not adding the decant tank to the trend. i added after so i have it for the future

 

[drbitboy]

It takes around 40minutes, from ~08:00 when the decant cycle starts and the level was somewhat steady, for the flow at ~100gpm (4-wells base load, no decant) to increase to 115gpm (decant load) at ~08:35, at which point net flow is 0 and the level is not changing.

Over that time, the level initially increases by 1.7ft-, from 2.3ft+ to 4.0ft.

By the end of the decant flow (115gpm), because the level has not recovered and has instead almost completed its first oscillation, it is ~1.98 and increasing.

Although the relative conditions are not identical to when the decant flow started, when the decant flow stops I would expect a similar initial swing with the level decreasing by 1.7ft (or so, maybe more, maybe less, but in that neighborhood), which would almost certainly pull the level below the 1ft low limit.

Increasing K_p will increase the flow more quickly as the level rises, which will attenuate the level rise, which in turn will attenuate the Integral Accumulation, which in turn will mean the level will not need to go as low to eliminate the excess Integral Accumulation.

P.S. Yes, I am groaning with you, @Peter, that I explain it this way, but I don't think throwing the Laplace domain, which is of course the right thing to do, at OP is going to help here.

Maybe we could set up a Jupyterlab page to simulate this, with time-domain and s-/Laplace-domain (complex-plane, IIRC?) plots. Once validated (although the model is so simple, that should be trivial), OP could tweak the gains to see that there is no way to improve on the optimal poles.