Re: [foxboro] client server

Okay!  I'm almost there but have a few more questions about the BLOBS
and examples of what we are doing today with the existing reporting
tools that we also want to be able to do with IEE. Hopefully in a much
easier fashion.

If sequence code, PLB ladders, and the Strategy Objects are stored as
BLOBS, will your reporting mechanism export information that is
contained in the BLOB?

If not, will that kind of information only be viewable using the IEE HMI
as an interface?

        David Johnson's last post asks the precise question I am most
interested in being able to answer.

Will the new mechanism, (SQL,XML,ASCII), be capable of telling me
everywhere a tag/block is referenced?

That would be an excellent design goal.  Today our .asp queries provide
three major functions that we use on a daily basis.  They are:

1. Detail Connection Search - When loop number is supplied as input, all
blocks that contain that loop number and all of their connections are
returned in a Sink_Connection ->> Block Type ->> Source_Connection
tabular listing.  This includes any sequence source code references. The
resulting browser based output table can be copied/cut/pasted to other
applications or printed as desired but we mostly use it as our
definitive gospel to decide if we can modify or delete a block without
causing complications in other blocks.

2. FBM_Point_Search - When the IOM_ID is supplied as input, all IO
blocks that contain that IOM_ID, including the ECB_block are returned in
a CMP ->> Blk Name ->> Blk Type ->> Blk Description ->> FBM ->> Point#
->> Hi_Scale ->> Lo_Scale ->> Units tabular listing.  It is sorted by
Point# with the ECB block info listed first for easy determination of
spare/unused points.  We decided to put physical location and IO rating
info in the ECB block description in a structured format.  Using the 32
characters available in the ECB block description we were able to
describe the FBM location and connected IO as follows:
4 digit bldg number
6 digit enclosure number
2 digit STandard, Non-Incendive, or Intrinsic Safe FBM IO rating
1 digit directional location in bldg N,E,S,W
1 digit floor location
2 digit room information, IR=Instrument Room, ER=Electrical Room,
CR=Control Room.
Each field is separated by a HYPHEN in the description.  As in item 1
above, the table returned to your browser can be copied/cut/pasted to
other applications or printed as desired but we mostly use it as our
definitive gospel as we are assigning new IO or to know what loops will
be affected if we have to replace an FBM because of a failed point.

3. Block_Data_Search - When an exact block name is supplied as input
these block parameters are returned in a tabular format:
CMP ->>
Blk Name ->>        For any installed block on system
Blk Type ->>        For any installed block on system
Blk Description ->> For any installed block on system
FBM ->> Point# ->>  For any I/O block on system
Hi_Scale ->>        For any Analog block on system
Lo_Scale ->>        For any Analog block on system
Units ->>           For any Analog block on system
Hi_Alarm ->>        For any Analog Alarm block on system
Lo_Alarm ->>        For any Analog Alarm block on system
        When there are multiple blocks with identical names in different
Compounds the browser lets you page forward one block at a time to view
each individually.  Output tables from Queries 1 and 2 above have
dynamic links to individual block names that let you click to display
the Block_Data_Search screen.

        Using today's tools we go through the following steps:
1. Dump C:B:P's to ASCII files using ICCPRT
2. Use a custom C program to strip CIN and CO data from PLB files to
ASCII
3. Use script files to awk/grep sequence code .s files to find C:P:B
references and output them to ASCII files.
4. Use more scripts to generate comma delimited files from those ASCII
output files.
5. Export/transfer to an MS environment where we import to an MS ACCESS
database.
6. Publish the database to an intranet website.
7. Created .asp (Active Server Pages), that reside on the intranet
server to provide several of the most common queries we need to do our
jobs.  We can all view them from our desktop browsers over our corporate
network.

   From an HMI (client) perspective we are platform independent as any
modern browser running on any platform is able to view the data returned
from the .asp that runs on the MS Intranet server.
        We have recently individually been dumping graphic files to
ASCII using d_edit and then importing to EXCEL spreadsheets on larger
conversion projects.  We are doing this as we eliminate PLB blocks and
move to CIN/GDEV/COUT's that make our transition from 100 to 200 series
IO an easier task.   We need to find all of the PLB references and
change them to the CIN/GDEV/COUT references on all of our graphics.  We
have talked about including the graphic dump info into our ACCESS
database. We may also incorporate info from the many legacy historians
we have spread throughout our site by using dmpcfg -c to an ASCII file.
        I asked Duc today what his preference was and he said he would be happy 
with the lowest common denominator, ASCII because he already does all of 
the administrative manipulations.  If the UPLOAD is faster we could 
probably get all of or functionality updated once a day but I guess I'd 
rather just run canned SQL queries from a browser against an SQL Server 
database provided as part of the basic Foxboro report function and 
eliminate all of the export, import, publishing to our corporate 
intranet server hassles.  If the graphics and historian connections info 
was also available it would be too simple.  I'm still leaning toward an 
SQL offering.  XML would be my 2nd choice.  These two can inherently 
serve the data to a browser in a relational way.  ASCII and EXCEL 
require additional and unnecessary manipulations to get relational 
information displayed/served to a browser.
        I'm thinking the PLB and sequence stuff that we do for our  Detail 
Connection Search is not likely to be available in the report offering 
from Foxboro because of the BLOBS and we will still be doing some of our 
own customizing to get what we want.

Cheers,
Tom VandeWater
 
 
_______________________________________________________________________
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: