Technically, you should get superior performance by using a "Sampled Data
PID Controller" rather than a fixed scan PID. i.e. enabling the PID
execution only upon receipt of a new analyzer (maybe a GC) update. This is
the SPLCOP option in the PIDA. One item you did not mention that has a big
impact on the control effectiveness is the analyzer delay time. I.e. when
the analyzer is giving a new update, how old is this data? In a GC this
would be the time to transport the sample from the process to the analyzer
plus the time for the analyzer to complete it's result and set the sample
ready timer to on (elution time of the applicable component peaks for a GC).
Also the use of inferred property control (like analyzer to temperature
cascade for distillation for example) can be effective to catch upsets that
are fast relative to the analysis frequency mitigating the need for
improving the analyzer PID loop. In this case the temperature PID loop
essentially handles the upset. The PIDTAU option (deadtime compensation)
might be considered in conjunction with the SPLCOP option to better handle
the sample delay. Prior to the PIDA feature we would typically just run a
fixed scan PID but filter the measurement with 2 lags in series (set for
about .2 and .5 times the sample interval in minutes). This, in conjuntion
with signal validity logic, was typically satisfactory, but not technically
optimal. Some multivariable controllers (I think that PCL Connoisseur does
this, and I know that BOSS blending can do this) can make a similar
synchronization and PCL control technology inherently compensates for the
sample delays. Few of these tricks would substitute for a well designed
fast sample loop, and a fast responding analyzer technology. My vote is to
implement this in the PIDA rather than sequence blocks or programs as it
will be simpler and easy to maintain. The validity logic for holding the
PID and alamring might include "frozen" signal and provisions to
automatically detect analyzer maintenance like calibration in case the
operator did not take the precaution of putting the loop into manual first.
Rick Rys
-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.
To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]
