Recent Control & Safety Systems Discussions
Similar Posts
PIDPlus appears to turn off after GAIN or RATE changed
PID Faceplate doesn't show floating point numbers
Functionality of PID block for Process Type Changes
Delta V data appears "&&&&&"
Process History View of one of the area not appearing
Share
  • Not Answered

PID block doesn't appear to be responsive to tuning changes?

Hello DeltaV community,

I have a temperature control valve controlled by a PID loop in a Control Module and it doesn't appear to be responding to tuning changes.  I will change the GAIN, RESET, and RATE orders of magnitude (0.1 to 500) without any performance change to the control loop. (ie, the valve closes right as it crosses the SP).  If anyone has any suggestions on how to see if the PID is responding changes in GAIN, RESET and RATE I would appreciate it.

The details:

FF is Foundation Fieldbus

I am not able to get all the code from the Control Module into this forum but will try my best to describe the situation.  Inside the Control Module in the PID1 loop is a FFAI with the OUT wired to the IN of the PID1 block.  The OUT of the PID1 block is wired to a FFAO CAS_IN.  The BKCAL_OUT of the FFAO is wired with a dashed wire to the BKACAL_IN of the PID1 block.

Also on the PID1 block:

TRK_IN_D is connected to CND blocks for high temperature or high pressure conditions

TRK_VAL is wired to a variable with a value of zero.

The more complicated details:

There is a CND block with the following code:

IF "^PID1/MODE.ACTUAL' = AUTO

    THEN

    IF '//TIMERS/HEAT_TIME.CV' = 1 OR '//TIMERS/REACT_TIME.CV' = 1

    THEN

        '^PID1/GAIN.CV' := '/RX_GAIN.CV';

        '^PID1/RESET.CV' := '/RX_RESET.CV';

        ''^PID1/RATE.CV := /RX_RATE.CV;

    ELSE

        '^PID1/GAIN.CV' := '/DG_GAIN.CV';

        '^PID1/RESET.CV' := '/DG_RESET.CV';

        ''^PID1/RATE.CV := /DG_RATE.CV;

    ENDIF

ENDIF

rem 'about 50 lines of legacy code removed from previous programmers that was left in place when I found it'

When the Control Module is running in on-line mode I will see the values in the PID1 block change from the RX_ to DG_ tuning values, I will also see the gain, reset, and rate change in the controller Faceplate.  Yet, regardless of what I change the values to with module download or change during on-line mode, the PID response doesn't seem to change. 

One last note is that this is a very slow system in a batch processing.  The vessel gets a new batch of cold raw material and cools the vessel down, it then heats and reacts for 6 hours and then starts a new cycle.

Your help is appreciated.

daimyo505

14 Replies

  • Andre Dicaire
    My first thought is that the logic looks to be writing to these parameters every scan, rather than by exception. I can't remember if this "locks" the PID and that you should only write by exception. i.e. if GAIN <> X, then write GAIN := X. etc. In your code, you check for which set of parameters to use and then write them continuously.

    Is the PID block a native DeltaV PID block or is it an FFPID assigned to a device. If assigned to a device, you definitely do not wan to be writing every scan as these affect the NVM of the device. Looks like it is a DeltaV PID as you refer the FFAI and FFAO but not FFPID.

    Try commenting out /bypassing the calc block writes and see if things work when you can manually adjust tuning on PID itself. If that works, make your writes by exception.

    Of if someone can confirm the continuous writes are or are not an issue.

    Andre Dicaire

  • James Beall

    In reply to Andre Dicaire:

    I don't know about a PID in a Foundation Fieldbuss device, but it is ok to write to the Gain, Reset and Rate every execution. However, I do NOT recommend this. I agree with Andre's suggestion to only write a parameter if it is NOT what you want it to be.
    I am curious what are the two sets of Gain, Reset and Rate. And, can you provide trends of SP, PV, OUT and not where tuning is changed.
  • eddysales001
    I can't say for sure with FF (or DeltaV) but I know in Provox you could not write to the tuning parameters every execution else the loop will not respond because on the initial execution of the PID after a tuning parameter change it back calculates the biases to ensure the tuning parameter change does not bump the output. Think old time analog controllers With AC2 analog controllers you also never changed the gain in auto as it would surely bump the output. You switch to manual, change the gain and then switch back to auto

    Ed Smigo

  • James Beall

    In reply to eddysales001:

    Hey Ed! You are absolutely correct on this issue with PROVOX and AC2. However, it is ok to do this in DeltaV (special consideration was made for this) but, as I said, I do not recommend writing EVERY scan if the parameter is already the desired value.

    FYI, the tuning parameters are changed base on whether the error (SP-PV) is positive or negative, it is like that there will be an offset between the PV and SP! It will look like the integral is not working!
  • Michael Krispin
    Hi Daimyo505,
    it would help to explain short why you want change the tuning parameter.
    It looks in a first view that you try to heat very fast and once a time or reaction gives the signal 1 then the tuning reduce to a more smooth one.
    In that case you should consider to overwrite the OUT_HI/LO_LIM depending on the Error and PV-Rate of change until near to the SP and then open the Out limits slowly to release the PID-Control. In that case, you still can let the main tuning parameters untouched.
    Additional there are also a handful other tuning parameter which can lead to a better control for your case.
  • Michael Krispin

    In reply to Michael Krispin:

    Forgot to ask, do you calculate the RX... and DG... Parameters even continuously or are they static?
    If they change also in every cycle a bit then the Balance Time might get active here.
  • John Rezabek

    In reply to James Beall:

    The older generation of fieldbus devices had a vulnerability with NVRAM, as best I recall, which made writing a non-volatile parameter (like tuning parameters) every cycle a problem. As far as I'm aware, the more recent vintage e.g. Fisher DVC6200 has an improved NVRAM technology that reduces or eliminates the issue. However I would concur that "writing on change only" is a better practice.
    The exact PID form used varies from chip maker to chip maker (Softing algorithm might differ from F-R), but the "response to setpoint change" is not configurable, at least last time I looked. Derivative (rarely used in FF loops, IMO) on PV and P+I on error (SP) (common for Cascade slaves / flows).
  • Andre Dicaire

    In reply to eddysales001:

    Ed, thanks for confirming I wasn't completely wrong. When you pointed out Provox, I went "oh yeah, that's the one that locks up... " I actually remember now when I learned that DeltaV allows the tuning to change without locking up and thought how great that was.

    The other thing is that the PID will not bump the output when the GAIN is changed. The Integral term will be adjusted to keep the Output from changing due the change in GAIN* error. If you expect the OUT to change when you alter the GAIN, as a measure of the PID accepting new changes, that would not work.

    Andre Dicaire

  • Andre Dicaire

    In reply to Andre Dicaire:

    One more suggestion. Create a test module with the PID/OUT feeding the PID/IN. Add a lead/lag block and maybe a DeadTime block to create a "process". Now you can test away on this module to understand any behaviors you come across. You can add your tuning adjustment logic to this module and see if you can recreate your situation and explore it further. A very useful reference that saves you from having to disrupt the process to solve your problems. You can make this as simple or as complex as you need. Start with simple.

    Andre Dicaire

  • daimyo505
    Thanks for all the suggestions. It takes a while to get results:
    Following Andre's suggestion, I commented out the code in the CND block. It should be just like a normal native DeltaV PID block now. When the vessel was close to set point, I tried to change the PID tuning parameters in On-line mode without a change in output. I also tried changing the GAIN parameter when the output was changing. The output and temperature profile looked exactly as the previous batch. I only tried increasing the P&I terms up to an order of magnitude without observing any change in output on the PID block.

    Michael,
    Yes, we are trying to heat the vessel very quickly and then once temperature is met to hold at that condition without overshooting temperature. The entire system has lag times: heating fluid warmup lag time (different system, different controller), lag time from heat applied or removed to observed temperature change. This vessel is the only one that has dual functionality. It looks like two different people have attempted different solutions, based on how they have tried to code and write variable names. I don't think it is necessary to have two different PID tuning parameters sets, it is how I found the control module. The parameters are static.

    James,
    I would have to hand draw the curves and attach, I will give it an attempt in the next reply.
  • Mark Coughran

    In reply to daimyo505:

    I have seen that writing to PID/RATE from a CALC block will freeze the integral action of the DeltaV PID. In twenty years of process optimization work I have never encountered a good reason for writing the RATE parameter on each execution of the module. So I agree with the above recommendations that you NOT write to the RATE.
  • Paul Hughes
    Following the thread below - do not change the values continuously. Use a change of state to pulse change them (specifically rate and reset). To be honest I have used dynamic gain calculations and updated them continuously before and it works fine (blending with normal feedback and not ratio control). That however was for the gain only.
  • James Beall

    In reply to Mark Coughran:

    Hey Mark,
    The example you gave of the changing Rate appearing to "freeze" the integral is what I warned about in my post above, "FYI, if the tuning parameters are changed base on whether the error (SP-PV) is positive or negative, it will result in an offset between the PV and SP! It will look like the integral is not working!" Just like the PV-SP offset created by incorrect ARW settings, while it appears to "freeze the integral", it is really just creating a non-linear control action that looks like it is "freezing" the integral! Good to point that out that example! Thanks!
  • James Beall

    In reply to daimyo505:

    Hi Daimyo505,
    I have not observed the issue you mention. Note that if you are using Dynamic Reset Limiting and the AO block has slow SP RATE LIMITS, it will slow the effective integral action of the PID. Is this a cascade scheme? If so, the DRL would limit the integral action if the secondary loop is responding slowly (and "uses PV for BCKAL_OUT"). It would be helpful have a trend of the PV, SP and OUT noting where tuning changes were made. Good luck!
    James

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.