Sometimes uploading isn't a good thing. Think twice before doing an upload
before a saveall.
When you create your control configuration it's a good idea to put initial
values in for most of the settable parameters. If you are always doing
uploads you are going to be uploading parameters that have been set to keep
the plant in steady state, hopefully, but not necessarily where you want
them to be at initialization. You might also be doing an upload when things
are really out-of-control.
Another approach is to configure your blocks with what you want as an
initial value, when the blocks are initialized after a load-all.
Modify your backup script to look the checkpoint file timestamps. Only do a
backup when the timestamp changes from the last saveall backup. The end
result is that you only do a backup after you've made a change to the CP.
Then, write yourself a script using "getpars" to grab all the block
parameters that are of interest to you, e.g. all of the PID block .SPT
parameters or all of the CALC block RIxx's. Have the data gathering script
put things into a file in a designated directory. Label the file names in a
way that includes time and date for easy reference. Use those values to
update your initial values in FoxCAE or the integrated control configurator.
You can also update you SOP's that the operations folks use to bring the
plant up.
You could use the operator action journal to track changes, or even the
historian. But a script like this can be tied to a button you can hit when
you've got things in the right state. Or you can kick it off at a
prescribed time.
This is a little more work than doing those uploads, but you won't need to
worry about doing a load-all with controllers wound-up and outputs max'd
out. You also won't be doing nearly as many uploads and ICCAPI save-alls,
reducing network and processor load.
Of course you don't need any of this if you have a nice little start-up
sequence to bring things up nice and orderly.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Corey R
Clingo
Sent: Monday, August 13, 2001 10:14 AM
To: Foxboro DCS Mail List
Subject: RE: Save All Script
Man, you guys are scaring me. If upload is potentially unreliable, how does
one
capture operator changes in the savealls? I want to be able to
automatically
generate savealls at night. Do I have to do it once without uploads, and
again
with uploads, then run that check_db_sync or whatever it's called to make
sure
the databases are consistent, and if it fails, restore the one I did without
uploads (to save the work I did that day)? This issue is getting more
ridiculous by the moment.
I agree with Bo; the other system I have experience with (Honeywell TDC)
allows
you to rebuild the configuration database from the controller's memory.
Actually, there is no separate configuration database. There is a
"workfile"
(the IDF) and an ASCII representation of the configuration database (the
exception build file) but these are not essential to the configurator's
operation; they only exist as a temporary storage facility, a means to
transfer
configuration between two systems, and as a bulk configuration mechanism.
The
configurator also does not "lock" the entire controller, so you don't have
the
issue of CP memory corruption when multiple users try to work in the same
CP.
This is not rocket surgery, Invensys. Help us out a little, eh?
Corey Clingo
Sr. Engineer
BASF Corporation
Alan J Schaff <[EMAIL PROTECTED]> on 08/10/2001 12:31:51 PM
Please respond to Foxboro DCS Mail List
<[EMAIL PROTECTED]>
To: Foxboro DCS Mail List <Foxboro
cc:
Subject: RE: Save All Script
We did the upload but to no avail, the work file is still corrupted. Our
next
course of action is to load a backup tape on an off-line system get the work
file and load it onto the on-line system. Then we plan on taking the upload
function out of the saveall script since we believe this was the culprit.
Thanks,
Alan Schaff
-----------------------------------------------------------------------
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]
