Different performance of PIDs with same parameters

There are 2 identical pelletizing systems in 2 separate DeltaV systems/manufacturing cells.

Different versions - DV7 and DV13.

In DV7 PID performance is satisfactory with gain=0.5, reset=5, PVfilter=10s :

However in DV13 system, where whole project is copied/converted from DV7 system), performance is much worse:

PID tuning is not identical(gain=0.52, reset=10.5, PVfilter=8s) because otherwise pelletizer interlocks because of pressure/flow overshoot.

However, what mystifies me is not performance.

DV7 PID responds to -100 SP change with roughly -2% change to OUT. And DV13 PID has longer reset(so theoretically should be slower), yet responds to same -100 SP change with -5% OUT.

Why 2 PID blocks with the ~identical parameters/scaling/configuration/controlled devices, same PV, same SP change(and therefore error) - return that much different OUT???

  • Hi

    The performance for the pid output is depends on the pid tunning parameter . As these pids are having different tunning parameters . So the pid output response is different.
    Another thing these pids are used for different purposes . So tunning parameters are different .

    Regards

    Prashant
  • In reply to PRASHANT-MUTTEPAWAR:

    The PID block sees the process as a function of its Input response to its Output. For one to reach steady state with a 2% change and the other with 5%, they each see a different Process gain, assuming these are self regulating loops. Nonlinearities in the valve response, process, sensors, calibrations etc., all add up to define the process response as seen by each PID. PID tuning would effect how fast the PID reaches steady state but the end output value is a function of process gain.

    Andre Dicaire

  • In reply to Andre Dicaire:

    >Nonlinearities in the valve response, process, sensors, calibrations etc., all add up to define the process response as seen by each PID.

    Yes I'm aware of it - same type same manufacturer machines are not identical and discrepancies add up. But in this case, I see that for both processes/machines discrepancies are not actually significant - for same SP steady state OUT and PV historical trends are quite similar.

    > For one to reach steady state with a 2% change and the other with 5%,

    I'm not talking about steady state. For both PID's OUT steady state evens out with ~ -1.5% change(this is also case in argument that processes themselves for both PID's are not different).

    > PID tuning would effect how fast the PID reaches steady state but the end output value is a function of process gain.

    About PID tuning - this is part of my confusion, PID with same gain and longer reset should be slower yet it exhibits 3x bigger initial OUT change. All other PID parameters are identical(except some Insight parameters which do not exist in DV7).

    I'm specifically asking about initial OUT jump after instant error due to SP change.

    Please look at numbers in attached trends so as not to make assumptions.

  • In reply to Mindaugas:

    It appears to me that the "initial change" you are referring to includes not only the Proportional action but also the Integral action. As has been correctly pointed out, the OUT movement after the first scan depends on both the Tuning and the Process Response. The amount of "initial proportional action" due to a SP change occurs on the first execution of the PID after the SP changes. On the next scan, you get P, I and D (if not 0) action. The trend detail is not sufficient for me to see the Proportional action on the first execution after the SP change except for the second step in the V13 trend. For this step you can see the Proportional step and the subsequent I action during the dead time portion of the PV response, then the P&I response once the PV starts to move. (I can also see the process response is not the same in the UP and DOWN direction.) Thus, the trend scale would need to zoomed in on the time scale (less time) to clearly see the initial proportional action. It appears the Rate (derivative) is set to 0. May I ask for the PV_SCALE, OUT_SCALE, ARW_HI_LIM, ARW_LO_LIM, PID/STRUCTURE and the (PID) module execution time. Also, what is the historian trend update rate (e.g. 1 second or 5 seconds) . I'd be happy to dig into this a bit more!
  • In reply to James Beall:

    James Beall said:
    I'd be happy to dig into this a bit more!

    Okay. Then, some details I omitted for the sake of focus/brevity:

    Process itself is gear pump, maintaining flow of viscous polymer through pelletizer orifice plate. PV(Flow) is calculated from temperature, pressure, viscosity and PID OUT(rescaled into kg/h). I know it's a bit strange, using OUT instead of true feedback, but this is from technology vendor.

    Manufacturing cell has 4 such pelletizers, fed from 1 reactor; pressure in common feed is maintained by separate gear pump/PID loop. There are running 3 manufacturing cells built using +- same project. So, I got a lot of theoretically identical process/pelletizer behaviours to compare.

    New DeltaV13 manufacturing cell with pelletizer PID's in question is running for ~1,5 years; it's notable because any bad scaling would have surfaced through raw/product logistic/accounting reports. Problem existed from startup - I tuned all 4 pelletizer PID's to acceptable compromise between accuracy and speed and switched to more urgent tasks.

    FRC PID in question is CAS master, slave(P:0,25 I:0,3) is more or less used just for scaling/signal processing. I've put 1 slave into bypass and nothing changed much. Slave signal is sent via ProfibusDP to pelletizer PLC(Siemens). Siemens side code has only signal scaling, no PID.

    Siemens PLC sends 4-20mA output to frequency converter, which is same type and have identical config to all 12 other pelletizer frequency converters(I asked and it was confirmed onsite). Motors are same type, reducer ratios vary a bit but this is accounted for, gear pump is identical(same series manufacture).

    James Beall said:
    (I can also see the process response is not the same in the UP and DOWN direction.)

    Yes, this is the other part which confuses me - process/control up/down assymetry.

    It's also noticeable in 8 old pelletizers and this is to be expected with such pressures and viscosities, but in new DV13 system 4 pelletizers this assymetry is 10x bigger while steady-state process parameters are very similar. I did not ask about it because problems like this usually stem from hardware/process ... confusing part is that I find no noticeable differences there, so I'm re-checking control part.

    "How" I can manage if I'll be tasked for this - for example using 2-degrees of freedom PID and dynamic alpha/beta scripted to SP direction of change.

    What I'm looking for is "Why".

    James Beall said:
    The amount of "initial proportional action" due to a SP change occurs on the first execution of the PID after the SP changes.

    Yes, when SP changes only error changes(PV-SP) and PID is (roughly) just a formula converting error to OUT. By "initial" I meant first half-cycle in timeframe from disturbance to steady-state.

    James Beall said:
    Also, what is the historian trend update rate (e.g. 1 second or 5 seconds)

    Historian trend is real time, because of 1s update and data compression historical trends are not very useful. See for yourself - I've added the same period trend collected from historian for comparison.

    James Beall said:
    May I ask for the PV_SCALE, OUT_SCALE, ARW_HI_LIM, ARW_LO_LIM, PID/STRUCTURE and the (PID) module execution time.

    It looks like I can't attach module exports ... so:

    PV_SCALE: 0-7500kg/h;

    OUT_SCALE: 0-100%;

    ARW_HI_LIM:40; ARW_LO_LIM:0;

    PID1/STRUCTURE: PID action on error;

    Module execution time: 1s

    This is identical on both PID's compared in original question.

  • In reply to Mindaugas:

    Mindaugas,
    So when you say the "initial response", you are talking about the response of OUT from the time the SP change is made, until the directrion of the initial OUT change begins to reverse. This portion of the response includes Proportional AND Integral (and Derivative if not 0) and is impacted by the Process response. For example, during the dead time of the process response, the Integral will create a ramp.

    That being said, I can see that the downward action of the OUT is responding to the ARW_HI_LIM setting of 40 (units of OUT_SCALE=%). When the OUT is above the OUT_HI_LIM (40% in this case) and is moving downward, the Integral action is sped up by a factor of 16 (Effective Reset= Reset/16) until the OUT is below the OUT_HI_LIM! Books on line explains this. This is what is causing the increased speed and amount of movement on the downward SP step. I recommend that the ARW_HI_LIM be set to the 100% value of the OUT_SCALE (100% in this case). I see this action in both the V7 and the V13 examples. Apparently the difference in the two processes exacerbates the problem for the V13 case.

    Except in rare cases, the ARW feature in DeltaV is not needed and the ARW_HI_LIM and ARW_LO_LIM should be set to the high and low values of the OUT_SCALE to disable the feature during normal PID control. Note that these limits have the same units as the OUT_SCALE (e.g. if the OUT_SCALE is 0-5000 lb/hr, the OUT_HI_LIM should be 5000 and the OUT_LO_LIM should be 0).

    Please try this and let me know what you find. Don't hesitate to let me know if you want more information on this topic.
  • In reply to James Beall:

    Good thought James, re: Anti Reset Windup. Do I have a vague memory that ARW did not work as-advertised in earlier versions of DeltaV?

    These ARW settings have bitten me before, so I made a quick export-format (.fmt) file to check ARW settings vs OUT scale for all PID modules:

    For those who haven't used a custom format file in a while:

    First copy the .fmt file into the Bulk Edit folder. Then in DeltaV Explorer, highlight the plant area you are interested in (or all of Control Strategies) and select File | Export | User Defined… | Select All (!! This will take a while if you have a lot of modules!!) | Next | Browse for ‘ARW_Check.fmt’ | Next | <create an output-data file name> | Next | Export.
    Duncan will then create one line of txt for each module, with a heading for the module name, description, OUT_Scale_100, OUT_Scale_0, Out_Scale_Units, ARW_Hi_Lim, ARW_Lo_Lim.
    You can view the data in Excel using the Excel add-in found in the Bulk Edit folder. (example result attached – note non-PID modules will just show up with NULL data)
    Provided you only name PID blocks as "PID1", you can then compare the out scale settings and the ARW settings.
    This is created and tested on DeltaV v12

    As James says, you want to make sure the ARW limits match the OUT scale, unless you have a really good reason to employ the ARW functionality.


    An obscure UDEP suggestion would be to have the function block ‘dial-out’ the ARW settings when you change the OUT_Scale; in the same way as the function block dials-out the SP_Lim settings when you change the PV_Scale…

    ARW_Check.zip

  • In reply to Chris Goetz:

    Chris,
    Good to hear from you! Yes, ARW limits did not work until V7.3. Good suggestion!
    James
  • In reply to James Beall:

    Mindaugas,
    Did you get a chance to change the ARW limits and re-test? Let me know how it works.
    James
  • In reply to James Beall:

    James, your solution is correct. I marked your reply as valid answer.

    After changing ARW_HI_LIM: 40->100 problematic PID behaviour disappeared altogether:

    James Beall said:
    Except in rare cases, the ARW feature in DeltaV is not needed and the ARW_HI_LIM and ARW_LO_LIM should be set to the high and low values of the OUT_SCALE to disable the feature during normal PID control.

    I agree, in my 15 years I tried solving problems with ARW limits only twice, and in both cases I ended up using different solutions.

    Chris Goetz said:
    Do I have a vague memory that ARW did not work as-advertised in earlier versions of DeltaV?

    James Beall said:
    Yes, ARW limits did not work until V7.3. Good suggestion!

    Production cell A/B system which also has identical ARW_HI on all 8 pelletizers, is DeltaV7.4.

    However, I'm staying with an assumption that DeltaV7.4 ARW limits function differently to DeltaV13.1 - process values in 12 pelletizers across 3 production cells are very similar in steady-state and premise "the difference in the two processes exacerbates the problem for the V13 case." is IMHO less likely.

    Sorry for the delay - I took a week of holidays in response to Covid; I saw immediately that your suggestion is very likely true but didn't want to reply without hard data.

    Thank you James! Sorry that my problem was not quite challenging for you (:

  • In reply to Mindaugas:

    Mindaugas,
    Great! I'm glad we got to the bottom of the problem.

    In the interest of completeness, I checked on the version when the ARW started to function as stated (as Chris and I recall!) and found that it was actually version 8.x when the ARW function began working consistently (KBA AP-0700-0108)! So, this makes sense that the incorrect ARW_HI_LIMIT did not impact the V7.4 system!

    James