Experimental Physics and
Industrial Control System

[email protected] · Thu, 07 Apr 94 15:43:16 -0500

>> 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
>
>I think the more useful conversion is to take a flat gdct file and convert
>it to become part of a capfast hierarchy.

I agree, but the conversion facility may not be possible.
Did you ever run that test on capfast to see what it does when it gets
a file that contains nothing more than the field values?  That is, with
none of the line connection graphic info or symbol dictionary stuff?  I
am assuming that it will not work without it.  And that graphic stuff
is not going to be easy to generate from the gdct output.

I will find out more about what SHOULD work in this area as I get into
the 8" think EDIF manuals.

As I recall, the point of this discussion was to try to eliminate as
much of the conversion utilities and the dbLoadXxxxx dialects as
possible.  So we don't have to support so much code.  The idea that we
could share files b/w gdct and capfast would be nice, but I am not
feeling too good about converting the graphics to and from gdct format
and EDIF... when it even exists!  Remember that gdct does not require
any graphical interconnection at all.  And some of our databases are
generated by users of PCs via relational database report generators. 
Those databases will also not have any graphical information in them.

I am not tossing in any towels on this yet, I am just having a REALLY
hard time figuring out where all the pieces of information are going to
come from. Building a capfast understandable EDIF file from the kind of
database configuration methods that are in use today just might not be
a reasonable thing to do.

--John

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System