Re: GC Analyzer Control
Rory, I've seen a variety of implementations, all of which worked well enough, although differently. If your process is fast enough that after a controller output change it is likely to come to a new steady state before the next sample, then you can tune a continuous PI controller to produce a deadbeat response. If your process is relatively slow compared to the sample interval + deadtime, filtering (especially filters that give more weight to the most recent sample) can be applied to smooth the step changes in GC output. This increases the phase lag of the sampler but the filtered measurement is easier to use in control. Synchronizing the PID control with the sampler output is easy to implement but can be difficult to tune. Just connect the fresh sample flag to the MA parameter (or HOLD parameter) in the PID controller. This type of control is convenient in that you can have it just ignore any GC output flagged as bad without affecting control. Continuous PID control can be used, however the spikes in manipulated variable due to derivative action on the step change may be unacceptable in many applications. Often very fast stabilization come from using just enough derivative filter to minimize excessive process disturbance. Regards, Kevin FitzGerrell Systems Engineer Foxboro New Zealand Tel: +64 (9) 573 7690 Fax: +64 (9) 573 7691 Loupe, Rory (RJ) [EMAIL PROTECTED]To: 'Foxboro - Cassandra' [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED]Subject: GC Analyzer Control oject.org 07/10/01 07:34 AM Please respond to Foxboro DCS Mail List I am converting some old Foxboro SMS control schemes to run on I/A. There is some code that does validity, rate of change and time-out checking on some GC data. If the GC data is good the code does PID control with this data (in the code itself, not through a PID block). The analyzer has a cycle time of 15 minutes and sets a boolean flag true for 60 seconds on a fresh update. I am trying to determine if I should stick with code from the SMS and convert it to HLBL or use standard I/A blocks to accomplish the same thing. My idea for I/A is to do validity, rate of change and time-out checking via a CALC block. Do the pid control via a PIDA block and on invalid GC data put the block in manual and alarm. Part of the problem with this approach is tuning the PIDA block. I have done an extensive step test and have come up with tuning parameters (with a large reset time). The testing of this PIDA seems to be doing a good job, but the GC update time has me concerned about timing issues. Could someone suggest a solution to GC control on I/A? Thanks, Rory --- 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]
RE: GC Analyzer Control
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]
RE: Synchronization (was RE: HLBL REF.)
Other tools to check synchronization of all the pertinent data files can be obtained and aren't mentioned here. When installed, check_db_sync and ck_multi_cps in the directory check_sync located in /opt/fox/bin/tools will give you a warm and fuzzy feeling when it successfully reports databases are synchronized. These tools are a part of the (now partially defunct) 'bootless upgrade' feature. I run these once a week and have discovered problems long before they cause real trouble. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 7:29 PM To: Foxboro DCS Mail List Subject: Synchronization (was RE: HLBL REF.) Corey, It is critical that the CSA database, the station volume workfile and the checkpoint file stay synchronized. Because parameters are constantly changing on the CP, it is normal that the setable parameters in the CP will not match the other files, although the non-settable parameters must match. There are several things that can cause a problem between CP, CSA, station workfile and checkpoint file. Some of these include: 1) Power failure or system reboot during ICC session 2) Improper exit from ICC 3) Tape restore 4) setpars 5) CSA tools 6) ICC use with severe station overloading Other causes probably exist. Corruption of CSA, work file or checkpoint file is possible too. Of the list above, #1 is the one I have seen most often. Typically, an ICC session is left open and is still open when the computer or xterminal it is running on is rebooted (before checkpoint). Tape restore of an AP or AW is a tricky one. If changes have been made in ICC since the tape you are restoring from was made, and if no current SaveAlls exist, you will probably need to restore from tape, reboot the CP (to checkpoint file from tape) and re-create the changes in ICC made after the tape. A couple of items that may not be obvious: 1) Upload only updates settable parameters from CP to workfile. Assumption probably is that non-settable parameters shouldn't need to be updated from CP. 2) A SaveAll is not made from the CP but from the workfile. If setpars is used to change a non-settable parameter on the CP, a SaveAll won't reflect that change even after an upload. Tools are available for troubleshooting mismatches: Select views parameters in CP. iccprt views parameters in workfile. dbvu views parameters in checkpoint file (-t option, needs checkpoint file, map file and image file). CSA_save exports an ascii copy of the CSA database. Regards, Kevin FitzGerrell Systems Engineer Foxboro New Zealand Tel: +64 (9) 573 7690 Fax: +64 (9) 573 7691 Corey R Clingo [EMAIL PROTECTED] To: Foxboro DCS Mail List [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED]Subject: RE: HLBL REF. oject.org 07/10/01 11:17 AM Please respond to Foxboro DCS Mail List OK, you've gone and confused me now (don't get the big head; it's not that hard to do ;-). I am kind of new to I/A, and this whole checkpoint/workfile/CP's memory thing has me asking a lot of questions, to say the least. I had thought that the checkpoint at least was a direct copy of the CP's memory, but from what you say below this is not the case. (Emotional state on discovering this deleted...) Sois there anything else supplied by Foxvensys that can make changes to the CP's
