RE: Contact Information
Contact Info: I am Rick Rys at R2Controls. I worked at Foxboro for 20 years and have been an independent contractor for the past 5 years. I live nearby Foxboro, MA. I continue to work for Foxboro in both development and applications areas and I also work for some end users. Occationally, I do have the chance to offer my opinion on product directions and I have pushed for reliable/powerful APXX/WPXX (i.e. Unix/Solaris seems best) platform (and many other useful features) especially for their Chemical, Oil, and Gas customers. Rick Rys P.E. Principal - R2 Controls Process Control Technology 1 Cherry Street Mansfield, MA 02048 508-339-6633 Phone/Fax 508-846-7195 Cellular www.R2controls.com --- 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: Constraint Control - OutSel Block
Satish, The OUTSEL block is set up to handle reset windup block initialization handling. It can be used where you have a normal PID loop that should be bumplessly interupted when a second controlled variable reaches a constraint target. Let's say you were normally operating with a fixed and steady gas flow to a vessel. In case the vessel pressure was getting close to the relief valve setting you decide that the normal feedrate must be cut. You set the SELOPT parameter to 2 for Low selection and add a second PID Pressure control loop with a setpoint somewhat below the relief valve setting. Properly configured: at the moment the pressure rises to the setpoint of the pressure controller the flow control valve will just start to close (from it's current position) and the loop will become a pressure controller with a minimum flow constraint. When the vapor removal rate from the vessel is increased the pressure controller will open the flow control valve until the flow setpoint is achieved and the flow controller will now bumplessly resume control of the valve. The SIGSEL block is possible but the OUTSEL block was built for this specific application. Many implementations are possible. Hope this answered your question. Rick Rys R2Controls --- 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: Open-loop detection on analog output cards
Let's assume you have an FBM 04 with ECB type 2, and a simple AIN, PID(A), AOUT analog control loop. Next you remove the wiring at the FBM terminal for the 4-20ma output for this channel. The CP is good, the fieldbus is good, and the FBM is good. ECB Failsafe is not enabled. The field wiring is bad (open), however, and the valve is getting 0ma and thus going to it's failure state. You will likely be getting some alarms soon enough, but I understand why you might want to get an alarm immediately. This might be possible with intelligent transmitters, but it is my understanding that the FBM04 is not smart enough to identify a single open loop output. Inputs would be caught by out of range, but I don't think there is any way to detect a bad output short of a valve position transmitter with some type of deviation alarming scheme. In the AOUT block the BAO when set to 1 has alarming looking at BAD (BO193AX Block Book). BAD is set from the OPSTAT of the ECB block (with some logic I could not find), but the ECB is only setting the BAD based on communication related errors (see ECB Block description) and not disconnected output wires. You can look at BAD, OPSTAT, or ECBSTA to verify that nothing is showing as bad. Maybe someone else could verify this behavior as I didn't check it on real hardware. Rick Rys R2 Controls --- 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: Daylight Savings
Bo, As a consultant, I have seen many customer systems and it seems most do synch with the local time. One FDA regulated site in the US did set their I/A system to true GMT time, (i.e. timezone and DST did not match local time). In this way timestamped data and files had the correct times when transferred to other machines in local time. This avoided confusing timestamp conversions. Generally, they adapted to this quite well and were able to make this work without incident. Rick Rys R2 Controls --- 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: Accumulator Block
Loyd, One item to be aware of is: TIM in the CALC block gets the time from the CP operating system (VRTX). As the CP (operating system) is a slave timekeeper that is updated about every 10 minutes it is possible to skip a particular second if time is adjusted forward or if the time were set back, to pass through the same seconds from midnight twice within a few seconds. This would rarely happen as there are 600 seconds in 10 minutes and it would depend on the CP clock drift relative to the Master timekeeper clock drift and unknown details of how the time is actually updated. Some engineers have had trouble with this i.e. when CALC blocks looked for a particular point in time. It's not clear how much a CP clock can drift in 10 minutes, but unlike your PC motherboard the CP must keep time with the relatively poor clock of the Intel CPU as it has no battery backed real time clock. Ray Chouinard gives a pretty good example CALC. If the clock update were a few seconds backwards it would appear possible to get 2 resets within a few seconds. Presumably this is tolerable. Also upon a power-off CP reboot the CP time is unlikely to be correct initially (I think it comes up Jan 1, 1986) until the master timekeeper sets the time - a few minutes later. CALC blocks using TIM will likely undergo an abrupt change during this first time adjustment. This may present problems if you have one master accum block reset function used for multiple CP's. Rick Rys R2Controls --- 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: Rolling average
Alex suggests averaging 8 buckets from the DEADTIME block and this is very practical. Some other suggestions are: First DTOPT is set to 0 (DEADTIME block) so that the input is averaged over the duration of bucket transfers (the so called rolling average feature). If the DEADTIME block period is at least as fast as the variable to be averaged, then every single available sample will be considered in the rolling average (this precision may not be required). If DT is set to 60 minutes then the 10 buckets will transfer every 6 minutes. If the average must be updated every 1 minute then 6 DEADTIME blocks could be ganged together, but now several CALC, SELECTOR, or SEQUENCE blocks (60 sec period) would be needed to average 60 buckets. As required precision is not specified, heck maybe a simple lag block would do. 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]
