Re: [foxboro] client server

Re: BLOBs

The presence or absence of BLOBs used within the IEE is immaterial to
this discussion.

How we store the data internally has not impact on how we present the
data externally - okay, other than the amount of work that we have to
do.


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

I would expect that all data would be exposed if we expose any. Once
again, the presence or absence of a given internal data structure has no
impact on what we can or will expose.


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

What I was trying to explore is not a new reporting mechanism, but a way
to export the data so that if our tools including reporting are
insufficient that the user community could build what they want.

I would expect that all data would be available so that if we don't have
the right report, one could roll ones own.


Re: Reports
I appreciate your thoughtful explanation of the types of queries you do.
A discussion of the reports that people use is a good topic as well.


Regards,
 =

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tjvandew@xxxxxxxxx
Sent: Tuesday, March 27, 2007 8:39 PM
To: foxboro@xxxxxxxxxxxxx
Subject: 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=3DInstrument Room, ER=3DElectrical Room,
CR=3DControl 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=3Djoin
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
 =




Confidentiality Notice:
The information contained in this electronic message and any attachment(s) =
to this message are intended for the exclusive use of the recipient(s) and =
may contain confidential, privileged or proprietary information. If you are=
 not the intended recipient, please notify the sender immediately, delete a=
ll copies of this message and any attachment(s). Any other use of the E-Mai=
l by you is prohibited.


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