Re: [foxboro] Control Blocks missing in ICC Configuration


I guess I'm missing something here.  Is this to handle the problem of
compuunds/blocks missing in CSA, but not in ICC?  Otherwise, how can you
find the block in ICC to do the delete/undelete?  What exactly does ICC
need to access/delete/undelete a compound/block?

Having said that, delete/undelete is a handy thing that has fixed a myriad
of weird problems around here.

This whole multiple-database thing has been a source of concern to me since
I found about it, because 1) it's a poor design, and 2) there was much fear
from the Foxboro faithful here about doing automatic checkpoints and
save-alls because of it.  I finally bit the bullet and implemented the
excellent save_all.sh script from Cassandra because I couldn't take
watching our techs sticking a floppy in the AW for every one of our CPs,
and haven't had a problem with it in 2 years (dang, no wood in this
PC....).  Maybe I was naive, and living dangerously, and I also recall
using my trusty yardstick, i.e., "I can automate control database backups
on Honeywell, so Foxboro ought to be capable of it, right? ***".  Since
then, at least one of our other sites as followed suit (I didn't have any
arrows in by back :)

Subsequently I found out about the check_db_sync utility, and was
considering integrating that into the save_all script, so that
uploads/save_alls would not be attempted on CPs with corrupt databases.
After browsing through its code, I discovered that it really only compares
that the block names match between CSA, the ICC, and the checkpoints.
While that certainly helps, I don't feel that that is complete protection
against corruption (maybe someone more knowledgeable can enlighten me
here).

So I go on with my fingers crossed, and I'm always curious to hear what the
consequences of the different problem scenarios are, and what it takes to
fix them.

Corey Clingo
BASF Corp

*** As a side note, Honeywell TDC3000 uses only one primary control
database -- the controller's memory.  Checkpoints are typically made of
this, in order to load the controller after a reboot, but they are
otherwise not used or referenced.  The configurator loads from the
controller's memory the block you are working on, edits it on the
workstation's memory (it does not lock the controller or even that block
during this time), and uploads the block when you are done.
Auto-checkpointing is not done on upload, but rather independently on a
time interval or on-demand basis.  There are other database formats,
similar to save-alls, ICC workfiles  and ICC dumps, but these are used only
to transport configuration data between systems or to temporarily save it
(like an I/A work volume).  This avoids all the real and potential database
sync issues we see on I/A.




|---------+---------------------------->
|         |           "Jones, Charles  |
|         |           R. (Chuck)"      |
|         |           <CRJones@xxxxxxxx|
|         |           >                |
|         |           Sent by:         |
|         |           foxboro-bounce@fr|
|         |           eelists.org      |
|         |                            |
|         |                            |
|         |           04/10/2003 06:35 |
|         |           PM               |
|         |           Please respond to|
|         |           foxboro          |
|         |                            |
|---------+---------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |              To:  "'foxboro@xxxxxxxxxxxxx'"                                 
                                                 |
  |              cc:                                                            
                                                 |
  |       Subject:  Re: [foxboro] Control Blocks missing in ICC Configuration   
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|





This is the way I understand it:
Since the CP has no hard drive, when the compounds (or blocks) are deleted,
they are gone.  When they are then undeleted, in both the CP and the ICC,
they are pulled from storage on the server (whether AW or AP).  In this
particular case, it was whatever was in place at the time of the last
back-up.  But, hey, the CP and ICC are synchronized.  It's a little spooky
when you can see blocks running on the Select page (we run Display Manager)
and you can't delete them because they don't exist when you open the ICC.

It happened to me while I was making live edits to the system.  Actually,
it
was a full-scale reconfiguration of the control paradigm--which now
included
twelve sequence blocks per compound.  (I know, I know...   now.)  The WP
rebooted while I had the ICC open.  I saved the compounds to a work volume,
deleted the corrupt compounds, then restored them from the work volume.  I
suppose I could have tried the delete/undelete method, it didn't occur to
me
then.  I remember feeling a little pressured at the time....


Chuck Jones
Refinery Automation Technologist
Tate & Lyle North America -- Lafayette South Plant
765.477.5324 - Office  | 877.536.9219 - Pager






 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: