Slow Acting Long Time Interval PID Tuning

@GrizzlyC, I am curious: how much noise in the temperature measurement e.g. how much in the raw signal, how much in the 10s-filtered signal?

Also, what is the target control range? +/- 0.05? +/-0.01?

drbitboy said:

@GrizzlyC, I am curious: how much noise in the temperature measurement e.g. how much in the raw signal, how much in the 10s-filtered signal?

Click to expand...

No noise at that 10 second or even 5 second time its pretty smooth. The raw signal is pretty noisy still usually bouncing a couple hundredth of a degree up or down a second.

drbitboy said:

Also, what is the target control range? +/- 0.05? +/-0.01?

Click to expand...

The target control range should be around +/- 0.05 with no occilation

Ive got a new tank with the following parameters in it

p = 10
i = 80
d = 5

Execution time = 5sec

Initial results are showing the valve is winding down before the PV crosses the SP. Ill post the results once I get enough data.

GrizzlyC said:

...
Initial results are showing the valve is winding down before the PV crosses the SP. ...

Click to expand...

Woo hoo!


Whatever you do, don't tell anyone you got the answer from here. You'll be the local guru, and seeing a good result is, I suspect, already enough for @Mispeld; it certainly is for me.


P.S. we should have a pool how the valve will behave when the process gets to steady-state; my estimate is 93% of the time at 3, 7% at 4, i.e. 3.07 mean.

GrizzlyC said:

Ive got a new tank with the following parameters in it

p = 10
i = 80
d = 5

Execution time = 5sec

Click to expand...

I think @Mispeld is right and that Td should be 0.


Is this a different tank? Because if it's the same tank, and not that my model is Truth, but it predicts the following result



With an update time of 45s it's a bit better:

drbitboy said:

not that my model is Truth, but it predicts the following result...

Click to expand...

Summary


Get rid of that Td!




TL;DR


How fast can the valve move? I.e. how many percent can the valve move in one PIDE update time of 5s?



I wonder, with a Kc of 10, Td of 5min, and update time of 5, the standard 0.01 change in PV would change the error by 0.01 and derivative action would therefore change the CV by



Kc * 60 * Td * deltaE / updatetime = 10 * 60 * 5 * 0.01 / 5 = 6%.


On the next execution, the PV would be the same so the change in error would be -0.01, i.e. same magnitude but opposite sign,. and derivative action would move the valve back to its original setting, minus any change due to P or I, of course, but now it's spent 5s at 6% more open than necessary.



In my model such as it is, that 6% change in CV translates to a instantaneous change in valve position, and is then used as part of the next process model timestep.


However, in real life, that valve movement only starts at that point, and I suspect that even valve gets to the 6% change by the next PIDE update time, that the integral of its position is only half of the commanded 6%, and the effect will not be quite as severe as my modeling indicate.


Note also that a 45s update time cuts that 6% by a factor of 9, to .67%, which might not even move the valve to the next whole percent position.


Cf. https://literature.rockwellautomation.com/idc/groups/literature/documents/wp/logix-wp008_-en-p.pdf

drbitboy said:

Summary


Get rid of that Td!

Click to expand...

Maybe he has DSmoothing := TRUE?

From memory this adds a filter of 1/10th your derivative time constant to your derivative term, but I couldn't find the reference to this calculation.

AustralIan said:

Maybe he has DSmoothing := TRUE?

From memory this adds a filter of 1/10th your derivative time constant to your derivative term, but I couldn't find the reference to this calculation.

Click to expand...

Wow, that is an interesting idea. So if a derivative term is calculated as 10% CV movement at an update, DSSmoothing only adds 1/10th of that, i.e. 1% CV, on that update, and then accumulates 9% for the next update, where it will cause 0.9% CV on the next update, leaving 8.1% in the accumulator, etc., along with accumulating any other D-driven CV changes on each scan?

Why does the CV change in 1% steps in post #98?
If the calculations are done in floating point, the output should have much finer resolution.


I can see the control output changing in steps if the feedback resolution is poor.


Changing the update rate to 5 seconds almost make the control output look like PWM. Changing to 1 second updates would provide more resolution.


BTW,in China they call the OP the landlord and each post is a floor.
So post #98 is called floor #98.

drbitboy said:

Wow, that is an interesting idea. So if a derivative term is calculated as 10% CV movement at an update, DSSmoothing only adds 1/10th of that, i.e. 1% CV, on that update, and then accumulates 9% for the next update, where it will cause 0.9% CV on the next update, leaving 8.1% in the accumulator, etc., along with accumulating any other D-driven CV changes on each scan?

Click to expand...

Sorry, I mean..
Derivative component becomes something like Td.s / (1 + 0.1 Td s)

So a first order filter with one tenth the time constant of the derivative.

Peter Nachtwey said:

Why does the CV change in 1% steps in post #98?


...

I can see the control output changing in steps if the feedback resolution is poor.

Click to expand...

Summary


That is the reason why.


TL;DR


The OP stated early in this thread that the valve "tends to not move or get stuck in position if [they] send it micro increment adjustments," so they post-process the CV from the PIDE instruction and convert (round?) it to integer percentage values. They also offset the CV at 0% to be around 7ma output to the valve positioner (just under 20%), which is just before the valve actually opens, as determined by bench testing.

AustralIan said:

Maybe he has DSmoothing := TRUE?

From memory this adds a filter of 1/10th your derivative time constant to your derivative term, but I couldn't find the reference to this calculation.

Click to expand...

Found it in Table 7 here: https://literature.rockwellautomati...ocuments/rm/syslib-rm045_-en-p.pdf#G4.1056785


It's Cfg_DerivSmooth as an input, which is an alias for Wrk_PIDE.DSmoothing.

drbitboy said:

They also offset the CV at 0% to be around 7ma output to the valve positioner (just under 20%), which is just before the valve actually opens, as determined by bench testing.

Click to expand...

That use to be a problem with hydraulic valves. The answer was to super impose dither signal. This could be as much as adding or subtracting 20% of the full range of the control signal on top of the actual signal. The dither kept the valve from every really stopping so valve didn't suffer from the stick slip or Stribeck friction.


https://qualityhydraulics.com/blog/valves/what-dither-versus-pwm


I would plot the control output without the dither so it is possible to see what the PID is doing. The dither can be added or subtracted every 1 second or 0.1 second or every scan. The dither basically gets filtered out by the valve. If the dither is too fast the valve will not respond at all so it may stick anyway.