On Oct 17, 2005, at 13:41 , Steve Lewis wrote:
1) EPICS has a narrow interface and ALAMA/ACS has a wide
interface. Narrow means that EPICS just has well defined data
types and wide means that ACS has object to object communication.
This is the key difference. The NIF control system also has an
ALMA_like, wide, object-to-object interface. My opinion is that
this nearly killed it. A wide interface is a very subtle way of
replacing the benefits of encapsulation and data hiding with
(larger) problem of "interface coupling".
You cannot effectively build tools; programmers need to be involved
at every level, forever. Even small changes require rebuilding
everything: it's "make clean; make" every night--hopefully you have
a full suite of regression tests with a lab filled with real
hardware. NIF has about $500K sunk in such a lab, and keeps its
test team staffed at 25% of the level of the developers.
I believe that. On the other hand this talk listed by Marty:
http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/
beyondMiddleware.pdf
.. which gives the example of replacing CORBA with ICE.
Now: hard, requires recompile etc.
Future: easy based on divine framework with interfaces to services in
containers.
Can replace the CORBA plugin with an ICE plugin, at run-time, going
forth and back.
So who's right?
2) The interface to the IOC database is narrow in the sense that
communication is done via data rather than a large set of objects.
This is what allows general purpose tools like display managers
and what makes it easy for other systems to talk to IOCs. In
EPICS facilities it is common for operators to create displays for
MEDM or EDM. I suspect that tools like the the tango gui builder
would be used by programmers rather than operators or hardware
oriented engineers. Thus we must be carefull about how much device
orientation we introduce into IOCs. Perhaps a power supply but not
a high level physics abstraction.
Again, this is what the NIF architecture is like. It is (was)
extremely frustrating under this architecture to bring some
functionality to bear on the hardware and to the operators. What
would have taken 10 minutes with VDCT and 1 minute with MEDM in
EPICS took from 1 hour to 1 day from each of 1) the FEP programmer;
2) the tier 2 programmer; 3) the IDL/SQL/RDB team; 4) the GUI
programmer; 5) the tier 3 team [sequencer-like "scripts"]; 6) the
CM team to "regenerate the IDL", do "make clean; make". And then
you test. Elapsed calendar time: weeks to months.
We called it "IDL hell" and employed the most devious strategies to
avoid items (2)-(6).
By the way, there is an intermediate approach based on SNS
administrative measures.
But back to the technical aspect, did NIF just pick the wrong
interfaces and thus each change requires 2-6?
Is the other OO framework talk mostly by people who
have never actually tried it on the scale of NIF?
-Kay
- Replies:
- Re: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Re: ICALEPCS and EPICS iocCore V4 Benjamin Franksen
- References:
- ICALEPCS and EPICS iocCore V4 Marty Kraimer
- Re: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Navigate by Date:
- Prev:
Re: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Next:
Re: ICALEPCS and EPICS iocCore V4 Claude Saunders
- Index:
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: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Next:
Re: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|