200 likes | 309 Views
The Application of CORBA in a Generic Data Acquisition Program. SRCG Team. Geoff Mant Paul Stephenson Mike Miller Steve Kinder Karen Ackroyd N Vasanthi. Motivation. Construction of Data Acquisition program for a combined technique station. Integration of Unix, PC and VME environments.
E N D
The Application of CORBA in a Generic Data Acquisition Program
SRCG Team • Geoff Mant • Paul Stephenson • Mike Miller • Steve Kinder • Karen Ackroyd • N Vasanthi
Motivation • Construction of Data Acquisition program for a combined technique station. • Integration of Unix, PC and VME environments. • Provide software with a common ‘Look and Feel’ across stations to make set up and data collection easy. Integrating all detectors and ancillary equipment into one interface. • Create “plug and play” components with well defined interfaces using object-oriented programming principles to provide flexibility to cope with future changes. • Provide an interpreter for complicated and rapidly changing experiment protocols
Schematic GUI Interpreter Beam-line Components EPICS Devices Devices
Design Decisions • UML (Unified Modelling Language) for analysis and design. • C++ for OS-9 programming. • Java for beam-line components and graphical user interface (easier to program, large number of built in class libraries, garbage collection, threads, portability). • CORBA for middleware (Orbacus) • Jython as an interpreter • Allow multiple client access.
Existing Code Component Overview ABA/App GUI OE Object ADC McLennan:Motor SRS122:Motor McLennan:Motor
Why CORBA • Industry standard supported by the OMG • Provide connectivity between VME, PC and Unix systems • Orbacus CORBA was chosen for its C++ and Java flavours and its was FREE or so we thought! • Robust communication, hiding socket programming and retaining a strongly typed interface. i.e. multiple idl files specifying wide interfaces.
Features • Factories for object creation • Name Server for location of objects • Event Server for asynchronous communication • XML for configuration
Overall Design Client Client Client Naming Service Event Service OE Server Object Server
Application framework Client Naming Service Table Slit ObjectServer
Adapter Pattern - Server side Adapter pattern to provide some independence from the middle-ware and also to allow the components to interact as a monolithic system should the need arise.
Adapter Pattern - Client side The client side adapter contains code to allow the re-connection to the server if this has died and been restarted.
Drawbacks • Cost of Orbacus(Iona) CORBA licence • Now frozen at release 3.1.3 • Old OMG CORBA specification • Can’t pass Java objects, although if you know its only Java to Java serialization is one option. • We have used inheritance based CORBA which is now problematic on the server side. Tie mechansim would be better but not ideal. • numerous idl interfaces (pro or con?) • Java multiple inheritance in our design
Align Beam-line • Aligns beamline for data collection. • OEMove provides a standard tool to allow the control and set up of Optical Elements. • Easily configurable for different stations. • One tool meets needs of many projects.
Xafs • Standard absorption edge scan interface. • Will support multiple modes, Angle, KSpace and Fast. • GUI completely detached from control. • Scans done via JCLAM (scripting language - python extension).
PX Data Collection • Data collection making good progress, tested with Q4 and MAR180 & MAR345 detectors. • Same GUI independent of detector in use. • Detector specific bits provided by Detector implementation.
NCD Configuration • Configuration of the timer frame generator for multiple frames and profiles • Detector set-up with memory usage feedback. • Data output details
Interpreter • Load, save and execute scripts
Future • Another brand of CORBA • Utilise Java offering • RMI over IIOP • Get rid of OS-9 in favour of Linux • SOAP