Re: ICALEPCS and EPICS iocCore V4

[Claude Saunders <saunders@aps.anl.gov>]

Steve Lewis wrote:

> Marty Kraimer wrote:
>
> > 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).
>
> </RANT>
There was at one time a middle ground here, and it was called CDEV. I'm 
not suggesting reviving that particular implementation, but it was a 
interesting idea, and there was a great deal of thought and design that 
went into it. There are quite a few similarities between the old CDEV 
discussions, and what I'm hearing now about the tension between 
channel-based and object-based access.

CDEV provided a device abstraction (sort of like objects with a dynamic 
invocation interface) while being readily re-configured. In short, no 
"make clean; make", or IDL hell.  So...

Is there anything wrong with supporting 2 namespaces for control? One 
would be the channel-based namespace EPICS currently offers, and the 
other would be a device abstraction ala CDEV. Before everyone recoils in 
horror, realize that most places wind up de-facto doing this anyways. 
SNS has EPICS, but yet all their applications are driven via an object 
model realized in a relational database, that in turn has the 
association with the underlying EPICS PVs. Here at APS, our OAG group is 
effectively doing a form of this using SDDS to group PVs into more 
useful abstractions. All this to make higher level operations and 
physics applications easier to understand and work with.

So keep the nimble applications like MEDM, which require a channel-based 
data layer, but explicitly support a device abstraction layer as well. 
Things like feedback loops would be left to the EPICS record level, not 
implemented at the device abstraction layer.

I guess this isn't too far from just dropping the upper levels of Tango 
on top of EPICS, but it is distinct from that approach in that I would 
suggest making it more configurable than the typical IDL based approach 
(which Steve correctly notes can be hell in a dynamic environment). 
These dynamic device abstractions could be presented as CORBA objects in 
an ORB possibly...

<disclaimer>
Just talking out loud here, and please forgive me if I have 
misrepresented CDEV, Tango, or EPICS.
</disclaimer>

 - Claude