CDEV provides three major advantages over many native systems:
No, in many cases CDEV supplements capabilities of the
Examples of extended capabilities:
For all useful applications, the additional overhead is negligible, and more than worth the added capabilities. If an application spends 30% of the CPU time of a machine doing control system I/O, and 50% doing calculations or disk I/O, then CDEV will add less than 5% additional overhead.
The current version of CDEV supports all capabilities of channel access for C/C++ clients. For java clients, the channel access security change-of-state callbacks have not yet been finished (if anyone needs this, let us know and we'll raise its priority for completion).
CDEV contains the following components:
No support for CORBA is included with the CDEV release, but there are currently two active efforts to use CDEV over CORBA by writing custom CDEV I/O services (an extensibility feature in CDEV). These efforts include work at CERN/PS to talk to an accelerator control system, and in the Jlab DAQ group to talk to the experimental physics data acquisition system CODA
If one of these systems becomes general enough and mature enough pointers to it will be posted on the cdev home page.
CDEV supports both java applications and java applets. Applets communicate with the control system through the cdevGateway, and applications may use the gateway or native method calls.
Support for EPICS is currently through the cdevGateway. This gateway can support thousands of requests per second, and should not be a performance bottleneck (if it were, multiple gateways could be used). The gateway makes calls into the native control system.
It would be possible to provide an alternate implementation using native methods, possibly also using java wrappers to channel access.
There is a java package (adm) which sits above java CDEV and provides the following types of beans:
JDM is an older java package no longer supported containing a set of graphical components such as meters, strip chart, bar chart, push button, and drawing primitives which connect to the control system using CDEV. It is in the process of being replaced by ADM. (see above)
JDM also contains a parser which can read screen definitions used by the EPICS MEDM display tool, and reproduce those screens in Java (handy for remote applet use). This capability will be added to adm if requested and as time permits.
The Java implementation is in some ways simpler, and in other ways more sophisticated. In the java implementation, full advantage is taken of the java language, including the use of exceptions and threads. Because primitive types cannot be passed by reference in java, those parts of the library had to be changed.
In collaboration with CERN, Jlab has developed version 2 of CDEV for Java which introduces additional features and differences. One notable change is the use of error objects, which encapsulate more useful information about an error.
The biggest difference will be in the introspection capabilities of the java version. CERN has added a new package, cdev.dir, which vastly expands the ability and convenience of exploring the control system, including navigating from one device to another, such as from a named magnet to its (possibly multiple) power supplies.
For additional information, see CDEV for Java