RE: HLBL REF.
If the operators can interact with the process, I recommend putting GDEV blocks to AUTO (then WAIT 2 seconds for the block to see it) right before you use each one. It is the only way to be sure that the GDEV will be in the correct auto/manual state when you need it to be. If you are going to change state on several GDEVs, then you can put them all to AUTO followed by only one WAIT statement. If you want to call the script that you have already written, then I am going to have flex a few thoughts to remember how to do that. Depending on how you wrote the UNIX script, I believe that it may be a more efficient use of resources to rewrite it in HLBL. Is it a UNIX script, PERL, C code, or --Heaven forbid-- JAVA? (I am assuming UNIX.) Does the script use Object Manager calls or API calls? I'm curious now. Does any one know if HLBL is the most efficient use of resources in this case? Does anyone know how to call an external script from within HLBL? Chuck Jones Refinery Automation Technologist A.E. Staley Mfg. Co. -- Lafayette South Plant 765.477.5324 - Office | 765.420.4431- Pager -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:17 AM To: Foxboro DCS Mail List Subject: RE: HLBL REF. Thanks for the input, I have a script that places all GDEV blocks in auto. How would you use this in HLBL. I would like to place all GDEV's in auto at the beginning of the Sequence Logic. thanks in advance Ken Moore NSCC This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error, and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the TLNA HELPDESK at 800-404-2436 or e-mail [EMAIL PROTECTED] --- 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: OPC client for I/A?
Corey, I believe Matrikon makes an OPC server that will talk to an AW51. Phone 780-448-1010 www.matrikon.com Thanks Tom Lemieux Process Systems Specialist Alabama Pine Pulp Phone334-743-8576 Fax 334-743-8295 Email [EMAIL PROTECTED] -Original Message- From: Corey R Clingo [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 11:05 AM To: Foxboro DCS Mail List Subject:OPC client for I/A? Hello all, I'm looking for a way(s) to get data from 3rd-party OPC servers into points on an I/A system. I'd rather not buy an AW70, as we don't have any now and are looking to do this as cheaply as possible, but I don't have a problem with something running on a generic PC and talking to a 51-series box. I've seen 3rd-party OPC servers for the I/A, but no clients. The only client I've come across is the one from Foxboro, but that requires an AW70, as far as I can tell. The data is monitor-only and extreme robustness of the system is not required (if it were, I wouldn't be using OPC in the first place ;-). Any pointers or, better yet, actual application experience in this area would be most helpful. TIA, Corey Clingo Sr. Engineer BASF Corporation --- 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] --- 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: OPC client for I/A?
Corey, We are have been using the Matrikon OPC server for almost a year to make I/A points (740 points so far) available to our mill info system, and to send a few values back to I/A. The Matrikon OPC server is running on an NT box and communicates via ethernet to an AW51B to open FoxAPI lists. It is working very well. The only slight issue I have is that they are not currently making use of the change delta, so all the values are sent each time period (we are currently using 10 sec, which is the max period). We have been encouraging them to do this, though we have not had any trouble with LAN loading to date. Rich Corey R Clingo wrote: Hello all, I'm looking for a way(s) to get data from 3rd-party OPC servers into points on an I/A system. I'd rather not buy an AW70, as we don't have any now and are looking to do this as cheaply as possible, but I don't have a problem with something running on a generic PC and talking to a 51-series box. I've seen 3rd-party OPC servers for the I/A, but no clients. The only client I've come across is the one from Foxboro, but that requires an AW70, as far as I can tell. The data is monitor-only and extreme robustness of the system is not required (if it were, I wouldn't be using OPC in the first place ;-). Any pointers or, better yet, actual application experience in this area would be most helpful. TIA, Corey Clingo Sr. Engineer BASF Corporation --- 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] --- 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: HLBL REF.
What Alex did NOT mention although I feel he should have, is that using setpars should be avoided period. There are other more graceful (omset class) methods that are not nearly as dangerous. -Original Message- From: Johnson, Alex (Foxboro) [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 12:22 PM To: Foxboro DCS Mail List Subject: RE: HLBL REF. Re: Sequence Block Resources HLBL is slow. Each line of HLBL code is roughly equivalent to the CPU requirements of an AIN block. External references to CBPs in the same CP take even longer. Re: Setting External OM Variables from within HLBL HLBL allows OM variables (C:B.Ps and SVs) to be set directly using the following syntax: :variableName := value; where variableName is a C:B.P name or a Shared Variable Name value is the new value for the variable. The leading colon is required. Two examples are: :TOWER:OVRHD_LEVEL.SPT := 50.0; :WP0001DMCMD := dmcmd applic /opt/prog/myScript $DMNAME ; NAME := SN0001, DMCMD; :'NAME' := dmcmd applic /opt/prog/myScript $DMNAME ; This is documented in the appropriate manuals. There are a couple of gotchas though: 1) If the variable being set is secured or missing, you will get an operational error that will either cause an SBX to be fired or suspend the block. 2) Each external reference suspends the execution of the HLBL code for one block period if the target is outside the CP. If the target is inside the CP, the call does not suspend the code, but it can take quite a long time. The former issue is difficult to handle properly if one has several external references in the code since they will all fire the same SBX and you will probably want different handling for each case. Personally, I do not use this approach. I prefer to use a program like cpShell and send it messages from SENDCONF (see below). The second issue causes subtle problems in the code. I had one customer call because his emergency shutdown logic took 10s to execute and it was only 20 lines of code. The problem was that he did not know about the suspension of execution on an external reference. Since his block ran every 0.5 seconds though, 10s to execute the code was as good as he could expect. There is no workaround for this delay other than to not use external references, i.e., connect the targets to the output of the block. Of course, that can lead to conflicts with the operator if the operator needs to set the same targets. Re: Executing Scripts and Programs from a Sequence Block There was a long discussion on how to run scripts on demand. The options boil down to: * Using the external reference capability of HLBL to set the DMCMD global of a DM/FV instance * Using SENDMSG or SENDCONF to send a message to a program that will execute the command. There are issues with the first approach related to error handling, i.e., what happens and how do you handle it if the DMCMD variable does not exist or someone overrides your command before it can be executed. These are actually quite difficult to handle. The latter approach is much more controllable. The SENDCONF command has a timer. It suspends execution of the sequence block and sets the SUSPND parameter. When the SUSPND parameter is reset or the timer expires, the sequence block awakes. If it awakes because of a timeout, the flow of control goes to a particular part of your logic associated with exactly that failure. If it awakes because the SUSPND parameter is reset, the flow of control moves to the next line. Sadly, we do not ship such an application with the standard system. However, you can get a copy of one by ordering cpShell. This is a VAS-IT item which means that it is sold as reusable application engineering. It is licensed on a per unit basis where we trust you to have a reasonable process unit. To order, tell your account rep that you want: Part No: VAS-IT Description: cpShell for Solaris Order Type: ZZPB or ZZPR Item Tag: cpShell for Solaris Special Shipping Instructions: Contact Ruby Chapman in Houston to fill the cpShell order. Delivery: 4 to 8 weeks ARO. List Price (US): 2,200 USD I'll send you the manual separately. I'm sure that there are others with similar products. Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: Jones, Charles R. (Chuck) [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 8:59 AM To: 'Foxboro DCS Mail List' Subject:RE: HLBL REF. If the operators can interact with the process, I recommend putting GDEV blocks to AUTO (then WAIT 2 seconds for the block to see it) right before you use each one. It is the only way to be sure that the GDEV will be in the correct auto/manual state when you need it to be. If you are going to change state on several
RE: HLBL REF.
Okay, I'll say it. My advice is do not use setpars on a running system. It is intended as an application engineering support tool, e.g., to put CP's in simulation mode. There are some places where its use can be considered to be appropriate, e.g., setting some parameters like Computer Control timers, but they are pretty few and far between. Many of these special cases can be dealt with using the ICC Driver Task which at least checks for other configurators being used on the target station. Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: Stear, Bo [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 10:33 AM To: 'Foxboro DCS Mail List' Subject:RE: HLBL REF. What Alex did NOT mention although I feel he should have, is that using setpars should be avoided period. There are other more graceful (omset class) methods that are not nearly as dangerous. -Original Message- From: Johnson, Alex (Foxboro) [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 12:22 PM To: Foxboro DCS Mail List Subject: RE: HLBL REF. Re: Sequence Block Resources HLBL is slow. Each line of HLBL code is roughly equivalent to the CPU requirements of an AIN block. External references to CBPs in the same CP take even longer. Re: Setting External OM Variables from within HLBL HLBL allows OM variables (C:B.Ps and SVs) to be set directly using the following syntax: :variableName := value; where variableName is a C:B.P name or a Shared Variable Name value is the new value for the variable. The leading colon is required. Two examples are: :TOWER:OVRHD_LEVEL.SPT := 50.0; :WP0001DMCMD := dmcmd applic /opt/prog/myScript $DMNAME ; NAME := SN0001, DMCMD; :'NAME' := dmcmd applic /opt/prog/myScript $DMNAME ; This is documented in the appropriate manuals. There are a couple of gotchas though: 1) If the variable being set is secured or missing, you will get an operational error that will either cause an SBX to be fired or suspend the block. 2) Each external reference suspends the execution of the HLBL code for one block period if the target is outside the CP. If the target is inside the CP, the call does not suspend the code, but it can take quite a long time. The former issue is difficult to handle properly if one has several external references in the code since they will all fire the same SBX and you will probably want different handling for each case. Personally, I do not use this approach. I prefer to use a program like cpShell and send it messages from SENDCONF (see below). The second issue causes subtle problems in the code. I had one customer call because his emergency shutdown logic took 10s to execute and it was only 20 lines of code. The problem was that he did not know about the suspension of execution on an external reference. Since his block ran every 0.5 seconds though, 10s to execute the code was as good as he could expect. There is no workaround for this delay other than to not use external references, i.e., connect the targets to the output of the block. Of course, that can lead to conflicts with the operator if the operator needs to set the same targets. Re: Executing Scripts and Programs from a Sequence Block There was a long discussion on how to run scripts on demand. The options boil down to: * Using the external reference capability of HLBL to set the DMCMD global of a DM/FV instance * Using SENDMSG or SENDCONF to send a message to a program that will execute the command. There are issues with the first approach related to error handling, i.e., what happens and how do you handle it if the DMCMD variable does not exist or someone overrides your command before it can be executed. These are actually quite difficult to handle. The latter approach is much more controllable. The SENDCONF command has a timer. It suspends execution of the sequence block and sets the SUSPND parameter. When the SUSPND parameter is reset or the timer expires, the sequence block awakes. If it awakes because of a timeout, the flow of control goes to a particular part of your logic associated with exactly that failure. If it awakes because the SUSPND parameter is reset, the flow of control moves to the next line. Sadly, we do not ship such an application with the standard system.
RE: HLBL REF
Ken, To efficiently set the appropriate state of a number of blocks at the same time I use a calc or logic block. I trigger the calc block with a boolean input that can be pulsed from a display (momentary contact) or from sequence logic. The calc block uses an appropriate OSP to toggle on and off a boolean output to which the the AUTSW of the target blocks is connected. The same block can also pulse the appropriate REMSW or LOCSW when setting the state of control blocks. This approach is, I feel, more efficient than setting the state of each block from within sequence logic, and easier to maintain and troubleshoot than UNIX level scripts. It is also re-usable. As long as attention is paid to what blocks are connected to which logic, the state change logic can be shared by multiple sequence logic blocks and buttons on operator graphics. The calc block can have multiple triggers for a variety of desired states. Regards, Kevin FitzGerrell --- [EMAIL PROTECTED] wrote: Thanks for the input, I have a script that places all GDEV blocks in auto. How would you use this in HLBL. I would like to place all GDEV's in auto at the beginning of the Sequence Logic. thanks in advance Ken Moore NSCC --- 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: HLBL REF.
After speaking with our former application engineer, I agree that the setpars is not what we want to do. We currently only use the setpars tool after an unusual event, it is not used on a routine basis, the display with the call button is not nomally accessible. Do you recommend running a checkpoint after every use of the setpars tool? Ken Moore NSCC Johnson, Alex (Foxboro) [EMAIL PROTECTED] @lists.TheCassandraProject.org on 07/09/2001 13:23:44 Please respond to Foxboro DCS Mail List [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Foxboro DCS Mail List [EMAIL PROTECTED] cc: Subject: RE: HLBL REF. Setpars is a pretty powerful tool. I hope you are very careful with its use. It will make changes to the CP that are not reflected in the checkpoint file or the workfile. Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 9:52 AM To: Foxboro DCS Mail List Subject: RE: HLBL REF. It is a Unix script, currently called via a foxview button , I would like to include this in the sequence logic if possible. The script utilizes the setpars tool found in /opt/fox/bin/tools. Ken Moore NSCC Jones, Charles R. (Chuck) [EMAIL PROTECTED] @lists.TheCassandraProject.org on 07/09/2001 11:59:08 Please respond to Foxboro DCS Mail List [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: 'Foxboro DCS Mail List' [EMAIL PROTECTED] cc: Subject: RE: HLBL REF. If the operators can interact with the process, I recommend putting GDEV blocks to AUTO (then WAIT 2 seconds for the block to see it) right before you use each one. It is the only way to be sure that the GDEV will be in the correct auto/manual state when you need it to be. If you are going to change state on several GDEVs, then you can put them all to AUTO followed by only one WAIT statement. If you want to call the script that you have already written, then I am going to have flex a few thoughts to remember how to do that. Depending on how you wrote the UNIX script, I believe that it may be a more efficient use of resources to rewrite it in HLBL. Is it a UNIX script, PERL, C code, or --Heaven forbid-- JAVA? (I am assuming UNIX.) Does the script use Object Manager calls or API calls? I'm curious now. Does any one know if HLBL is the most efficient use of resources in this case? Does anyone know how to call an external script from within HLBL? Chuck Jones Refinery Automation Technologist A.E. Staley Mfg. Co. -- Lafayette South Plant 765.477.5324 - Office | 765.420.4431- Pager -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:17 AM To: Foxboro DCS Mail List Subject: RE: HLBL REF. Thanks for the input, I have a script that places all GDEV blocks in auto. How would you use this in HLBL. I would like to place all GDEV's in auto at the beginning of the Sequence Logic. thanks in advance Ken Moore NSCC This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error, and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the TLNA HELPDESK at 800-404-2436 or e-mail [EMAIL PROTECTED] --- 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] IMPORTANT NOTICE: This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to
RE: HLBL REF.
Depends on what you are trying to do. If you want to the change to survive a reboot, it must be reflected in the checkpoint file. What are you doing that requires the use of setpars? Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 4:29 PM To: Foxboro DCS Mail List Subject:RE: HLBL REF. After speaking with our former application engineer, I agree that the setpars is not what we want to do. We currently only use the setpars tool after an unusual event, it is not used on a routine basis, the display with the call button is not nomally accessible. Do you recommend running a checkpoint after every use of the setpars tool? Ken Moore NSCC Johnson, Alex (Foxboro) [EMAIL PROTECTED] @lists.TheCassandraProject.org on 07/09/2001 13:23:44 Please respond to Foxboro DCS Mail List [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Foxboro DCS Mail List [EMAIL PROTECTED] cc: Subject: RE: HLBL REF. Setpars is a pretty powerful tool. I hope you are very careful with its use. It will make changes to the CP that are not reflected in the checkpoint file or the workfile. Regards, Alex Johnson 10707 Haddington Houston, TX 77043 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 9:52 AM To: Foxboro DCS Mail List Subject: RE: HLBL REF. It is a Unix script, currently called via a foxview button , I would like to include this in the sequence logic if possible. The script utilizes the setpars tool found in /opt/fox/bin/tools. Ken Moore NSCC Jones, Charles R. (Chuck) [EMAIL PROTECTED] @lists.TheCassandraProject.org on 07/09/2001 11:59:08 Please respond to Foxboro DCS Mail List [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: 'Foxboro DCS Mail List' [EMAIL PROTECTED] cc: Subject: RE: HLBL REF. If the operators can interact with the process, I recommend putting GDEV blocks to AUTO (then WAIT 2 seconds for the block to see it) right before you use each one. It is the only way to be sure that the GDEV will be in the correct auto/manual state when you need it to be. If you are going to change state on several GDEVs, then you can put them all to AUTO followed by only one WAIT statement. If you want to call the script that you have already written, then I am going to have flex a few thoughts to remember how to do that. Depending on how you wrote the UNIX script, I believe that it may be a more efficient use of resources to rewrite it in HLBL. Is it a UNIX script, PERL, C code, or --Heaven forbid-- JAVA? (I am assuming UNIX.) Does the script use Object Manager calls or API calls? I'm curious now. Does any one know if HLBL is the most efficient use of resources in this case? Does anyone know how to call an external script from within HLBL? Chuck Jones Refinery Automation Technologist A.E. Staley Mfg. Co. -- Lafayette South Plant 765.477.5324 - Office | 765.420.4431- Pager -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:17 AM To: Foxboro DCS Mail List Subject: RE: HLBL REF. Thanks for the input, I have a script that places all GDEV blocks in auto. How would you use this in HLBL. I would like to place all GDEV's in auto at the beginning of the Sequence Logic. thanks in advance Ken Moore NSCC This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person
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 memory that cannot be duplicated on-disk? Corey Clingo Sr. Engineer BASF Corporation Ken, As others have stated, extreme caution should be taken when using setpars. Anytime setpars is used for bulk changes it should be followed by an upload and then a checkpoint (if you want the changes to be there in the event of a reboot), because setpars makes active changes in the CP only, not in the workfile or checkpoint file. setpars -- makes active change in CP upload -- updates settable parameters in CP to station workfile checkpoint -- builds new checkpoint file based on station workfile One of the big dangers in using setpars is that it can change
GC Analyzer Control
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]
