When the tunings are changed, it might be good to reset the integrals.

[rtek1000]

Hello, when the tunings are changed, it might be good to reset the integrals.

Code:
https://github.com/br3ttb/Arduino-PID-Library/blob/master/examples/PID_AdaptiveTunings/PID_AdaptiveTunings.ino

    myPID.SetMode(MANUAL);
    Output = 0;
    myPID.SetMode(AUTOMATIC);

Ref.:
https://forum.arduino.cc/t/using-arduino-pid-library-reseting-integrals/296451

[mrx23dot]

will be taken care of in the next task cycle, no need to duplicate code.

[drf5n]

Why? If you don't reset the integral, then the tuning changes should be bumpless, per http://brettbeauregard.com/blog/2017/06/proportional-on-measurement-the-code/ and http://brettbeauregard.com/blog/2011/04/improving-the-beginner%e2%80%99s-pid-tuning-changes/

[rtek1000]

In my case, resetting the integral helped a lot, it reduced the overshoot a lot.

[br3ttb]

Oftentimes, overshot can be lessened with different tuning parameters. To achieve an equivalent behavior to "resetting the integral" with this library (or the industrial PIDs it was designed to emulate) you change the mode to manual, set the output to a better value, then change it back to auto.

…

On Sun, Feb 26, 2023, 2:02 PM rtek1000 ***@***.***> wrote: In my case, resetting the integral helped a lot, it reduced the overshoot a lot. — Reply to this email directly, view it on GitHub <#125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACYX4QCLQDH33Y32KGEXHTWZOSFVANCNFSM6AAAAAAQWAY3CY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[drf5n]

Is this issue about overshoot? Or is it about SetTunings? I can't imagine the use-case for making SetTunings non- bumpless. I often operate heaters with PV far from zero, and resetting the integral to zero in SetTuning() would induce a bump.

If overshoot, I could see doing an integral reset to zero when crossing into the proportional zone at (SP-PV)>=outMax/kP.

[rtek1000]

I used two parameters and they are toggled when the input is close to the setpoint.

Below 2.5 degrees uses a softer parameter, above 2.5 degrees difference uses a more aggressive parameter.

I saw an additional function in another library, maybe it's related to this behavior.

AutoPID::setBangBang

Ref.: AutoPID

[drf5n]

Setting a high proportional constant (e.g. Kp=255, Kp=1e6...) makes the proportional band narrow, and then PID acts like bang-bang because either kPerror>outMax or kPerror<outMin.

Looks like AutoPID doesn't do anything at all to limit the integral:

https://github.com/r-downing/AutoPID/blob/fea6b99a4f05f2b53669d684fae6fe09b5391754/AutoPID.cpp#L43-L69

Maybe it behaves as a sort of conditional integration, where integration is depends on being within the band.

AutoPID does expose the integral, so a user could periodically check if it was wound up above outMax or outMax-error*Kp, etc., and reset it as desired.

[drf5n]

I was playing around with it and added a SetIntegral(double) and GetIntegral(double) in this sample at Wokwi:

https://wokwi.com/projects/358122536159671297

(If you play with it, be sure to toggle the SerialMonitor/SerialPlotter graph icon in the lower right corner.

I added a pull request: #132

[drf5n]

A smaller change to the library than #132 adding functions is to move the PID_v1.h:: outputSum variable from private up to public, which enables all sorts user-space tricks.

PR #133 -- Expose integral to enable user-space hacking:

It has a live example at https://wokwi.com/projects/358190033668210689