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

I've been watching this thread with some curiosity.  I offered such a tool
over two years ago which as apparently rejected off-hand as everyone
appeared to be more interested in the more open source offerings floating
around.  A tool very similar to those requested (BCT Visualizer) was offered
over two years ago and almost no one was interested.  Possibly because it
had a price tag.  With no interest shown, I withdrew the application and put
it in my archives.  That tool supplied complete UNIX scripting and a desktop
application with network access designed around the ability to use the ICC
API to produce current CP listings.  It was completely user independent
since it used the I/A system files to configure itself to fit each node.
The tool provided spreadsheet-ready files containing alarm information, FBM
point utilization and tuning parameters as well as 'Tree View' connectivity
from the perspective of COMPOUND:BLOCK and ECBs not to mention a 'Roll Your
Own' parameter access.  These things were difficult enough since all current
FBM styles need be considered when doing point references to ECB's.  The
application stopped at this point to 'test the waters' and see if users were
interested.  Under development were additions to include sequence code
references, script references, and display connectivity.

It was my objective to continue to expand the capabilities of the BCT
Visualizer to include sequence code, script references, trends and displays
but those things went by the wayside particularly because of the statement
below which quotes: " 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' ".  However, this statement is untrue.

Sequence code is attainable in several levels as mentioned by many
previously on this list (Alex included).  The real difficulty falls on
trying to 'generalize' the application for all I/A users where scripting,
trends, and displays are involved.  The tools included in the BCT Visualizer
needed no customization since system definition files (.IIF) could be used
to self customize tree views.  In order to be able to locate and parse
trends, scripts, and displays, the application needs to know exactly where
all these things are and as you well know, each user has their own opinion
about where these things will live on their system.  These are the things
that require forethought and would more likely succeed if done by a
professional programmer with lots and lots of experience with I/A.

Therefore, to remove the 'impracticable' from the above statement, all one
needs do is provide a user friendly tool to assist them in defining the
locations of these items.  It can be done.

----- Original Message ----- 
From: "Pat Martens" <foxpat@xxxxxxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Thursday, August 25, 2005 3:57 PM
Subject: 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
> 


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