EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  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  Index <19941995  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 
<== Date ==> <== Thread ==>

Subject: Re: Ascii file formats and the use of EDIF
From: [email protected]
Date: Fri, 08 Apr 94 15:01:47 -0500
I don't want to get into circles on this topic.  Last month we
had a 1 hour talk about file conversions at the LANL meeting.  The
issues and current answers are:


Q) Will we continue supporting DCT.
A) No, Phase it out.  Let gdct replace it.

Q) Will we support the use of EDIF based design tools.
A) Yes

Q) How will we support these EDIF based design tools.
A) Use conversion programs between EDIF and our database format.

Q) How should we convert between EDIF and loadable binary.
---> I opened my big mouth asked...

   Q) Can't we loose the binary format and just load an ascii file(s)?
   A) If it does not take more than 25% longer than the binary to load.
      (Earlier this week, some timing tests showed this to be the case
      when using the currect gdct ascii format.  Loading straight EDIF
      could fail this speed requirement since it is much more verbose.)

   Q) Could the ascii format be EDIF?
   A) Yes if we could convert gdct to use EDIF.  We would also have to
      make sure it loads at a reasonable speed.

   Q) What would it take to convert gdct to EDIF?
   A) 1) Convert the current ascii data to EDIF format.
      2) Add the graphic line plotting data.
      3) Insert the proper references to the component/symbol dictionary
         for the record instances.

   Q) Is it possible to convert gdct to EDIF?
   A) I am now finding out that it looks OK except for the graphic
      info.  Probably not in a bidirectional way unless the loss of the
      graphic info is acceptable (I assume not.)

   Q) Should we convert dctsdr from binary to ascii (to go along
      with the rest of the ascii stuff)? And what format should we use?
   A) Ascii would be better for the same reasons as for the record
      descriptions.  EDIF should be possible.  I am looking into it now.

   Q) Would such an EDIF version of dctsdr be useful to capfast users?
   A) Unknown.  Looking into it.  Need comments.

Q) Is it possible for something like capfast to load and edit an EDIF
   file that has no graphic information in it.
A) I thought that Chip Watson said the answer is no, but would try it
   to see what would happen.  *I* am supposed to look into the EDIF
   specs to find out what is specified about this situation, and have
   not done so yet.

=======================================================

Time passed, I did the gdct ascii load test and it looked OK.  I talked
with Jim Kowalkowski about GDCT and using EDIF for the files.  He said
it looks OK, except for the graphic stuff since it is part of the
graphics library and is not too close to EDIF.  It would take a fair
amount of work to do and would require imposing on the paradigm (my one
for the day) used by the interviews package to save its graphic info.

=======================================================

Here are the current questions going thru my head and my gut feelings
about the answers:

Q) If GDCT can't share databases with capfast, is using EDIF
   as the gdct file format reasonable?

--> I don't think so.  It would only waste time to rewrite the code and
    for no gain.  Capfast's database files would still be editable by
    gdct (since a converter would need to be written), but not vice
    versa.

Q) If EDIF is slower than the current ascii format is it worth loading
   on the IOC?

--> Maybe.  I have always hated keeping two copies of data in sync with
    eachother.  And was 1/2 the reason to get rid of the binary
    databases.  (The other 1/2 was to eliminate the required internal 
    representation of the binary data and structure field alignment crud
    that goes on in makesdr.)  So for that reason I would like to say
    yes.  But if noone wants to use it, the point is mute.

Q) If EDIF is too slow, should we continue to think about using it for
   dctsdr?

--> Only if it is some use to the EDIF users.  If they still have to
    generate some kind of graphic library and insert the descriptor info
    into that somehow, then who cares?  It would be better to use a more
    effecient format for loading and the flat file lovers.  This awaits
    comments from the capfast klan and some reading of the EDIF manuals.

Q) If EDIF is too ugly for the oracle report generator users, what
   format should be supported, since a conversion would have to be
   written for them?

--> Why create more formats.  The current gdct format seems pretty
    reasonable, and loads fast enough.  Any other sugestions?

Q) Will the EDIF schematic tools be able to edit anything that
originates from our non-EDIF based tools?

--> I don't think so, unless they are happy with the lack of graphic
    info.  Because that info is currently not part of the gdct format,
    and never will be present in the oracle-generated databases.  This
    awaits info from the EDIF specs and some tests by the users.

    Anyone want to try to load up that file from Matt Needs into capfast
    as is and see what happens?

===================================================================

What am I leaving out?  Am I lieing about anything?  Has anyone ever
taken a DCT database and (somehow) imported it into a usable EDIF file
for capfast editing?

--John

Navigate by Date:
Prev: EPICS drivers for CAN and RS232 / TCP/IP Matthias Clausen DESY -MKV2/KRYK-
Next: Re: Ascii file formats and the use of EDIF watson
Index: <19941995  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: Re: Ascii file formats and the use of EDIF winans
Next: Re: Ascii file formats and the use of EDIF watson
Index: <19941995  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·