Re: [foxboro] Sequence code (MON, DEP, IND) opinions

  • From: "Pat Martens" <fox@xxxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Fri, 18 May 2007 22:38:18 +0200


We use the SFC configurator for our demin unit regeneration sequences.
Works very nice. The code is easy to read and modify.
Creating trip routines and exception handlers (very important) makes it a
bit more difficult.
I think it's worth checking out though!

Other sequences are used as 'one-shot' routines which are mainly started
from our trip systems. We used to have a WAIT UNTIL waiting for the trip
event but changed this concept; we now ACTIVATE the sequence which runs ones
(no loops), so normally these sequences are not active. This way you don't
have to take precautions for block initialisation (after compiling for
instance). 


Like others have noted; there is no standard Foxboro tool to get C:B.P
references in sequences but there are lots of ways to get these.

I get the C:B references out of the .e file which is created during
compilation of the sequence. This file seems to hold all C:B references in
the total compiled output, so also all included files.
I found this out by experimenting so I'm not 100% sure if everything is in
there but I have not yet seen any missing references.
(used strings BLOCKNAME.e to get every C:B on a separate line)

Anybody has more details about the .e file ?


Imho, some sort of C:B reference tools is essential for proper maintenance
of any DCS. Fortunately the I/A system has lots of ways which allows you to
create such a tool.

Our self made tool makes the following data available in an access database
and is refreshed every day:

(I am kind of curious if something is missing, suggestions welcome!)

* complete control configuration (compares all data with that of the last
transfer and stores the changes)
* C:B references lists of graphics (include paths defined in a .cfg file)
* C:B references in historian (rtp configuration fetched with AIM* ODBC)
* C:B references in trend scripts (we've have hundreds of these)
* C:B references in AAtab files (annunciator keyboard config)
* C:B references in FoxAPI and AIMApi (I'm not happy with the way I get this
data, any suggestion?)
* C:B references in WASP application (WASP directly uses OM call's, so not
in FoxApi or AIMApi)
* C:B references in sequences (derived from the .e files)
* C:B references in DMCplus aod and ccf files
* C:B references in some other special application files

These references are all stored in separate tables and are checked with the
control database automatically: if ANYWHERE a block is used which is not
part of the control database it will be reported!
All references are viewable with a tree-view which gives a very good idea of
the block usage. Gives good insight when you want to delete a block!

Lot's of other things are done with this data like:
* creates history of CIO changes (parm x changed from y to z on may 18,
2007, or block added on may 04, 2006 or block deleted on jan 01, 2003)
* the creation of IO allocation reports (including spares)
* verification of C:B.P linking (although not up to parameter level)
* create reports of all CP - CP links
* show me which parameters are different from the block default parameters

Etc.



 
 
_______________________________________________________________________
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:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts:

  1. Home
  2. foxboro
  3. Archive
  4. 05-2007