Re: [foxboro] Tool development (was Spare I/O points)

Hi,

For the ones really interested (there's a lot of reading):

As I mentioned in an earlier posting we also develop our own tools.

However, IMHO, to design these tools in a 'generalized way' so any Fox. I/A 
user could use them would make the creation of these tools 'impracticable' 
as it is not my 'core job' (and I'm not a professional programmer). I 
consider it to be a 'hobby project' having no problems with bad-programming 
practices (up to a certain extend!) like hard-coding things in a simple way 
which would otherwise take a lot more coding!

Exchanging code is not that simple as often a lot of site specific code is 
used, however:
I would indeed like to encourage everybody to exchange ideas and maybe even 
code 'snapshots'.

I also should mention that my level of knowledge stops at the standard CIO 
configurator/FoxCAE/ICC drivertask, Foxdraw. (IA version 6.3)

To start the exchange of ideas, here is what I thought what an automated 
documentation system should be able to do:

What we've done so far (I think it, more or less, covers all 5 steps as 
mention in the Andreas Weiss posting):

Creation of scripts running on several AW's (any control station hosting 
AW).

These scripts output a number of files:

* complete control database (currently over 42000 blocks, over 2.5 million 
parameters).

* block references for all graphics (created by calling d_edit).

* block references for all sequence blocks (created by calling the sequence 
block pre-processor (when compiling a sequence block a temporary file with a 
.e extension is created which holds all external block references).

* block references to trend scripts.

* block references to WASP configuration files.

* other site specific block reference files like Aspentechs DMCplus 
configuration files'

* small status files which keep track of the script progress (they should 
all read 'finished' if all is done)

There is 1 master script which call's a number of sub-scripts and 
distributes itself to all AW's and runs them locally on those AW's (speeds 
up things dramatically).

This 1 master script is started from the PC ms-access server application, 
either on demand or scheduled.

Any other PC on the IT network could have a 'client' application installed, 
which is almost an exact copy of the server application without the 
possibility to start the I/A scripts. Also FTP to/from the I/A system is 
limited to a few users. Clients are free to write their own 
queries/forms/vba code in these client applications.

The server applic. reads the status files and when 'finished' will FTP, the 
resulting output files (ciocfg file is about 35 Mbytes!) to the server PC 
local drive (script running time: a few minutes)

It will then start importing these files (this is the largest piece of code 
and takes about 20 minutes to complete).

During the import it will create a block table, parameter table (by far the 
largest), assemble the FBM usage table, IO table, linking table (a table 
which holds only parameters which have a link).

It will also compare ALL parameters with the ones from the previous session 
and store changes in a ConfigChanges table (date/time stamp, block:parameter 
changed from xxx to yyy).

Other tables created are: display/block ref. table, sequence/block ref. 
table, hist rtp def/block ref. table (with ODBC link to fetch hist rtp 
definition), trend script/block ref. table, WASP/block ref. table, and 
other, more site specific block ref. tables.

All these tables have one common field which is the blockref field which is 
a unique long integer per block.

If, during import, a blockref can not be found it stores a zero and writes a 
message to a log file as something is addressing a block which does not 
exist. Finding unresolved linkages in cio database, graphics, sequences, 
etc.. is now a piece of cake !

Duplicate I/O definations will be noted in the log file.

The main application form is the block/parameter browser with on the left 
site the block table (fields, CP letterbug, Compound, Block, BlockType and 
(of less importance) the designated long integer block reference number 
which is needed the create the relational link with the parameters tables 
which is displayed in the middle of the form and shows all parameters for 
the block selected in the block table.

Pressing the 'T' key on the keyboard after selection of a block will call up 
a tree-view of this block which shows all references to the block, like 
linking, display usage, sequence usage, historian usage etc.

For complex loops the tree view can have hundreds of nodes!

This gives the most complete overview of block references (very handy if 
you're planning to delete a block).

If the block is a sequence block press the 'view code' button and the source 
file will be copied from the I/A system and displayed with notepad. Included 
files will be shown in seperate windows (in our case for some sequences this 
will pop-up op to 6 windows, although most often only 1)

Having such easy access to the ciocfg allows for the simple creation of icc 
driver task scripts, like bulk changing of links and/or parameters.

The trendscript table is used to find out if there are any tags which are 
part of a trend but are not configured in the historian. With the press of a 
button it will create historian rtp definition import files with a standard 
set of rules for deadband and scan-frequence on a loop-type base 
(temperatures are scanned less frequently then flows etc).

Blocks (or complete compounds) can be assigned to a hyperlink which in our 
case is a reference to a 'control narrative'. This is used for complex loops 
which need proper documentation.

I can not think of a better index to our control database documentation!

Although the application was far from where it is now, it was a great help 
during the FAT: one's we've found one mistake we could run queries to find 
out which other parts had the same mistake etc.

This is roughly the main functionality of the application as it currently 
is, some being of less value, others being (IMHO) indispensable (I do not 
really know if I use the right word here as English is not my native 
language).

I hope I might have brought up some ideas.

Regards,

Patrick Martens

Total Raff. Nederland N.V.

----- Original Message ----- 
From: "Weiss, Andreas" <andreas.weiss@xxxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Wednesday, August 24, 2005 9:08 AM
Subject: [foxboro] Tool development (was Spare I/O points)


Hi,
 <cut


 
 
_______________________________________________________________________
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: