Emerson Exchange 365

PIDPlus appears to turn off after GAIN or RATE changed

I am using the PIDPlus feature in DeltaV 13.1.  If I change GAIN or RATE, the PID block starts changing OUT every scan instead of when PV changes.  The only way I have found to stop it is to change mode to MAN and back to AUTO.  Then PIDPlus starts working properly again.  I am wanting to do gain scheduling, which means I would have to toggle the mode every time the gain changes.  But I don't want to toggle the mode, because I am using dynamic reset limiting.  Why does PIDPlus do this?  Is there a way to stop this from happening?

Mark Bendele

• 1 Dec 2020 5:45 PM
• Cancel

5 Replies

• James Beall

  

  • 1 Dec 2020 6:19 PM

  Mark,
  This is very interesting! Is the PV absolutely locked at the same value when you change the Gain or Rate? Note that if the PV is coming in on an Analog Input, any variation of the PV (even just noise) will cause the PIDPlus to see this as an update PV. The workaround for this is to configure a "hysteresis" calc such that the PV has to move more that the hysteresis amount to actually change the input to the PID.
  Another question is whether this is a non-zero error (SP-PV) when you make the change in Gain. If so, I can see the OUT changing due to the change in the product of Gain*Errror. I will do some testing on this tomorrow.
  James

  • Cancel
• Mark Bendele

  

  • 1 Dec 2020 11:53 PM

  In reply to James Beall:

  Yes, the PV is locked (no noise). I have set up a test module with PID to AO to FLTR (to simulate a process) to a calc block that occasionally outputs to PID/IN. If I change SP and then change GAIN, OUT starts changing every scan. If I keep changing SP, eventually OUT goes back to changing with PV, but I can't see what condition makes this happen. You mentioned GAIN*ERROR. I limited the output of the AO before changing SP and eventually OUT became constant, associated with GAIN*ERROR I suppose. When I released the output limit, OUT went back to changing with PV.

  • Cancel
• James Beall

  

  • 9 Dec 2020 8:47 PM

  In reply to Mark Bendele:

  Mark,

  Sorry for the delay.  Originally the PIDPlus block did not change the controller output unless the PV changed.  However, this meant that  if the SP was changed, the OUT did not move until the PV changed, thus the move to the new SP was delayed.  So, the algorithm was changed to perform the Proportional action immediately when the SP was changed.  In other words, the Proportional action is always updated even if the PV is not moving.  The Integral and Derivative Action are only updated when the PV changes.  Additionally, the DeltaV PID is a "positional" algorithm and as such the Proportional contribution is Gain*Error.  So, if you change the Gain when there is a non-zero error, the OUT will change even though the PV is not moving.  However, by design, the change in OUT due to the change in Gain times the error is filtered in with a time constant equal to the Reset time (takes about 4 * Reset time to complete, Reset=5 seconds in my test PIDPlus).  With the regular PID, the Integral is responding in the opposite direction and you don't see this change in OUT when you change the Gain when the error is non-zero.  In the screen print below, you can see this action.

  As I expected, I did not see an impact when changed the Derivative as long as the PV was constant.  If you saw this, please provide some more information so I can duplicate this issue.

  So, this may give you problems with your applications.  With the normal PID, you could choose a PID Structure where Proportional on PV rather than Error.  However, the PIDPlus appears to work a bit differently in this regard.  So, I am checking into this and will get back to you.

  

  • Cancel
• doug bray

  

  • 9 Dec 2020 9:11 PM

  In reply to James Beall:

  Is there any way for a layman to have access to how the PID actually does its calculations? I know the general math as shown in BOL, but as you show here, there are always choices made in how the math is executed under different conditions. Maybe it is proprietary?

  • Cancel
• James Beall

  

  • 9 Dec 2020 9:20 PM

  In reply to doug bray:

  Hey Doug!
  Be careful what you ask for! LOL! It is proprietary on many of the details. I have been working on a new (1 year old) ISA subcommittee on the PID function block (there was not one before!). The committee is focused on defining terms and explaining the various ways to implement the PID. As such, maybe I can share details from the perspective of the ISA 5.9 Technical Reference. I'll start thinking about this.
  James

  • Cancel