Abstract
Several Application Programming Interfaces (APIs) exist that simplifier the task of accessing EPICS-based controls data from higher level applications through Channel Access (CA), the dedicated communication protocol of EPICS. However, a number of these APIs do not necessarily reflect the recent advances in CA functionality (mainly related to multithreading and handling of lost connections) and some are tied to deprecated functions with little likelihood of being brought into compliance with the new CA standard. Applications wishing to benefit from new CA features would be better served through an in-house API that not only keeps in step with latest EPICS releases, but also presents the opportunity to provide an additional abstract layer that addresses specific requirements dictated by scientific applications. CAFE (Channel Access interFacE) is a new C++ library that provides a multifaceted interface to the latest CA functions released with EPICS version 3.14 and onwards. Functionality for both synchronous and asynchronous interactions is provided for both individual channels and groups, or collections, of channels. The basic task of writing and retrieving EPICS data is introduced through simple examples. More intricate interfaces tailored towards the needs of beam dynamics applications are progressively presented. The CAFE library is intended for use in C++ frameworks such as ROOT, and presents itself as a candidate for processing agents that, for example, capture machine physics data for storage or inter-shot analysis at the XFEL.
Reference: "A Taste of CAFE", Internal Note (draft), available on request.
Selected questions and discussion
FLP: How can you stay in step with the evolution?
JC: CAFE uses the latest CA functions; this will keep us in good stead for several years as major changes to CA functionality occur infrequently. CAFE will of course be recompiled with each EPICS release. The older C/C++ libraries (EZCA, CDEV) are tied to deprecated functions, which will continue to be included in future EPICS releases in order to maintain backward compatibility. These APIs are not however "evolving", and risk becoming obsolete.
FLP: I don't understand the need for all of this! In MATLAB it's very simple to access a channel... where is the power, the benefit of this?
JC: The power comes with concepts such as groups and collections, which allow you to efficiently read-out multiple channels, configured with an XML file etc. I am also addressing inter-shot analyses, which will be outside MATLAB's domain.
FLP: What does dynamic mean in the context of these groups?
JC: Well, a group can be created dynamically in the user's code. Since the user has control, he/she may extend the group or diminish it. However a more convenient approach is to pre-define the group in the XML configuration file; in this case the group cannot be changed at run time. However individual members may be withdrawn from any operation by setting the "rule" flag accordingly. This allows the user to adapt to changes in the operating conditions; experience has demonstrated this to be a highy desirable feature.
TS: Other labs must have the same need for such a library, shouldn't this therefore be an interlab effort?
JC: Most other labs are moving on to Java (but they may have to come to C for time-sensitive applications in new accelerators!). I am open for collaboration with other labs.
TG: What do our controls people think of it? Are they even aware of this effort?
JC: Controls group acknowledges that users will have a need to build their own CA clients/applications and even provides examples. Their responsibility however principally lies in providing the low-level libraries; they are not so interested in physics applications running in C++.
TG: What effort would be required to use this at the 250 MeV injector or the PSI-XFEL?
JC: None. A prototype library is available to all interested parties and is already being used within ROOT at OBLA.
YK comments on the current situation in OBLA: we have added MATLAB channel access, because the diagnostics people are most familiar with it, but clearly many beamdynamics people need the equivalent for their C++ applications. It is good that we now have both!
BO: MATLAB may be very fast and efficient, but you tie yourself to a company...
JC: The question is not really whether you want to use MATLAB or C/C++. If you want to get something done in 10 ms, you have no choice, you have to do it in C/C++... Also keep in mind that the MATLAB interface is very basic.
MB: There is also the stability issue: doing an orbit feed back in MATLAB would be crazy!
BB: We did it at FLASH and suffered a lot from it!
FLP: Well, what if Jan leaves?
JC: What we develop is fairly generic, it should be well maintainable.
MB: When you say agents, you mean distributed object, will you support CORBA?
JC: So far it is standalone code. Communication would require further thought. Keep in mind that communication with CORBA takes several milliseconds and here I am addressing agents that execute events within a 10ms window.
MB: But such an interface would allow communication to an online model, as we have it in the SLS...
JC: That is something else, in the domain of applications. I did not want to talk about applications today (since there is a lot to say by many).
MB: But that is the strength of the interface: it makes it easier to build applications in C++!
BP: So you can do stuff in 10 ms, but what happens if we go to 1 kHz?
JC: When we come down to 1 ms, we would enter a completely different regime, requiring a complete redesign, mainly on the hardware side with code running at lower levels
FLP: Can you dump stuff in the archiver?
JC: Of course, you can do anything you like. I guess the easiest thing though would be to dump data of interest into an epics channel, then you have access not just to the archiver, but to all the EPICS tools.
