EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: VDCT expand and template constructs
From: "Rees, NP \(Nick\)" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "Benjamin Franksen" <[email protected]>
Cc: <[email protected]>
Date: Fri, 23 Dec 2005 01:51:11 -0000
Dear All,

Sorry for the delay in replying - I have been out of circulation for a
few days. As I see it, I think the argument falls into two camps - the
schematic capture and the traditional EPICS camp. The former is
epitomized by Kay's message using the IC analogy, and the latter by
Andrews comment that "Comparing EPICS databases with circuit diagrams
doesn't work too well in this case, because in EPICS the wires are being
used purely for text substitution....". The overload of the meanings of
the word "port" has just aided the confusion. In schematic capture a
port is any external connection to an underlying component, but in the
current EPICS definition it has a much narrower meaning. I tried to blur
the latter definition but this caused confusion.

I am not sure how to resolve the difference in approach. I want to have
a set of fairly integrated developer tools that allow you to develop
complex systems more easily. Having a hierarchical schematic capture
database development tool is part of this puzzle. Having ways of
attaching other metadata is also part of it (hence the XML email of a
few months ago) is another. It all requires much more than what the
traditional .db file format provides. The file becomes more than it is
at the moment - which is defined by the philosophy that any information
that is not required by the IOC for instantiation of the template
hierarchy is regarded as un-necesssary complications. However, in doing 
this I am willing to sacrifice the ease of editing on the basis that the
filed formats are designed to make the tools work better, and with good
tools, the need for editing is reduced. Hence, having a defined interface
allows for inconsistencies to creep in - but is really a method to allow
tools to detect when you change the interface in one file and so force you
to change the interface in the other. A bit like a header file.

I am currently on vacation and have just suffered the ignominy of having
a reasonably long considered response being eaten by the vagaries of the
system I'm using. When I get back (after the 9th January) I will get back
to it.

Cheers,

Nick



References:
VDCT expand and template constructs Rees, NP (Nick)
Re: VDCT expand and template constructs Andrew Johnson
Re: VDCT expand and template constructs Benjamin Franksen
Re: VDCT expand and template constructs Andrew Johnson

Navigate by Date:
Prev: Re: VDCT expand and template constructs Andrew Johnson
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: VDCT expand and template constructs Andrew Johnson
Next: Re: VDCT expand and template constructs Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·