Experimental Physics and
Industrial Control System

Claude Saunders <[email protected]> · Mon, 17 Oct 2005 13:35:46 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System