Experimental Physics and Industrial Control System

>[email protected] (Bob Dalesio) writes:
>Do the current reports include all of the fields - even if they are the
>default?

No the test I did was with the non-default fields supplied only.  Since
we only use it that way, it seened fair.  The times for the full image
are significantly higher.  Even the file size is 5 times larger...:

Ascii with defaults:
-rw-rw-r--  1 jbk        451111 Apr  5 10:29 bpm.db

Ascii with everything:
-rw-rw-r--  1 jbk       2555391 Apr  5 11:23 bigbpm.db

binary with everything, including the dctsdr info:
-rw-rw-r--  1 jbk       1843338 Apr  5 11:21 bpm.database

I loaded bigbpm.db and it took on the order of 3 times as long as
bpm.db.  So I don't think that loading it is all that reasonable a
thing to do.  (Note that this does not mean that we don't want the
retain the ability to generate the long form versions for other
purposes.)

-------------

>Who is looking at the feasibility of using the EDIF netlist standard?

I am looking at it for use as the GDCT .db file format as well as
for the dctsdr file format.  As I see it, there are three areas that
will have to be addressed in order for the conversion of GDCT into EDIF
to be worth doing:

1) The dctsdr information should be made present in such a form that
capfast, gdct and "dbLoadEdif" can all make use of it to configure
themselves.  A design of this file will require a time investment that
I have not yet made.  I will have to spend a few hours with the EDIF
manuals before attacking this beast.  At the moment, it seems pretty
reasonable that an EDIF based design be used because the only
applications that we do not have 100% control over, that need this
information, are the capfast and other EDIF-speaking design tools.  If
we want to get rid of the binary sdr file format, which I think we do,
EDIF should be just as annoying as any other format we cough up.

2) It would be nice if graphical interconnection information used by
capfast and gdct was interchangable, at least enough to do a
conversion in one direction.  This looks very doubtful due to the
format used by interviews (what gdct uses for its X interface) for the
graphics data files.  The code that manages these files is part of
interviews and is designed using a philosophy that appears compatable
(in that it is heirarchical) but is dependant on the internal
organization of the class heirarchy of the user and library code.  And
the organizational details of the class heirarchy are not necessairly
known to the user/designer of the interviews based application.

3) The record field information should be sharable b/w the capfast and
gdct databases.  This seems possible, but w/o the graphical information
or a back annotation tool, it would probably be annoying enough to be
useless.


I honestly doubt that tools like capfast will be able to blindly
exchange databases with gdct in the forseeable future.  However,
without a large investment of time into this data sharing project, I
think that we could migrate toward a EDIF ascii file format such
that an IOC's database file loader "dbLoadEdif" (or whatever) reads in
EDIF files so that the capfast users wont have to do an annoying file
conversion from EDIF to the custom ascii format that we currently
generate with gdct.  It also seems reasonable that gdct could (some day)
generate its record images using EDIF so that it can be loaded with the
same ascii database file loader used with capfast.  And lastly, the
dctsdr information should probably be saved in EDIF form so that the
dbLoadEdif loader can parse it along with the gramatically
similar record information stuff. This would basically eliminate the
need to design and maintain any conversion utilities for the capfast
users as well as point gdct into the direction of EDIF enough to make a
one-way transfer of data from capfast possible... some day.

--John

Navigate by Date:

Prev: arAccessLib.c performance greene%denali . UUCP

Next: Re: Ascii file formats and the use of EDIF watson

Index: <1994>  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: arAccessLib.c performance greene%denali . UUCP

Next: Re: Ascii file formats and the use of EDIF watson

Index: <1994>  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024