1 / 23

Generic Data Acquisition (GDA)

Generic Data Acquisition (GDA). Fajin Yuan, Geoff Mant, Richard Woolliscroft, Stuart Campbell, and Bill Pulford NOBUGS 2006 (3/10/2006). Overview. What GDA is GDA architecture and components User Interfaces Scripting tools XML configuration EPICS Interfaces Extension mechanism

vaughan-moody
Download Presentation

Generic Data Acquisition (GDA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Generic Data Acquisition (GDA) Fajin Yuan, Geoff Mant, Richard Woolliscroft, Stuart Campbell, and Bill Pulford NOBUGS 2006 (3/10/2006)

  2. Overview • What GDA is • GDA architecture and components • User Interfaces • Scripting tools • XML configuration • EPICS Interfaces • Extension mechanism • Data management and visualisation • Built-in Editors • GDA deployment tools

  3. What GDA is • a software suite for synchrotron experiment control and data collection • jointly developed by staff/developers from • SRCG (Synchrotron Radiation Computing Group) at Daresbury Lab, Warrington, UK • DAG (Data Acquisition Group) at Diamond Light Source Ltd, Rutherford Appleton Lab, Chilton, UK • Our aim is to develop an Integrated Science Experiment Environment for synchrotron users at Diamond and SRS

  4. Design considerations • A single software framework to all beamlines • Similar look and feel across all beamlines • Reduce users’ learning requirement • Flexible, adaptable, configurable, and “plug-play” • Support both EPICS and non-EPICS hardware • Single integrated science experiment environment • Customisable GUIs and configuration • An open framework that is easy to extend • A system that is simpler and easier to maintain

  5. GDA fundamentals • Java as the main programming language • Java 1.5 or JDK 5.0, platform independent • Jython as the scripting language • Jython 2.1 or later, very close relationship to Java • XML configuration • Beamline configuration: device objects • Software integration: EPICS etc • Distributed system • ‘thin’ clients with multiple servers • Reusable & configurable components • Use many open source tools, components • Castor, CAJ, Jacorb, Apache software, etc

  6. GDA Architecture • The Core of GDA • structured in a 3-layer architect • with CORBA backbone for control and update • Top: GUI, OE representation & data visualisation • Middle: Command server, Control request & logics • Bottom: Device server, drivers and controllers • Many other services • Messages, logging, data curation, etc

  7. Components

  8. Motion Control interface

  9. Detector Interface

  10. Status interface

  11. Scripting Tools • Embedded Jython Interpreter in the Java Application • Give direct access to java objects • Terminal window for command line interface • Script Editor • Scripts are processed in the Command Server • Scanning Framework • Manage and monitor scan processes • Multi-dimensional • Extensible syntax

  12. Scripting Interface

  13. XML configuration • Server.xml • specify server objects and their initialisation states • Client.xml • Specify GUI objects and their configuration • Schema validation • During development • At GDA startup • CASTOR Java Objects to XML binding • object creation and initialisation

  14. EPICS Interface • XML Interfaces • XML files describing the interface specification • Generated from EPICS databases • BLxxI-gda-configs.xml : Specify beamline operation modes • BLxxI-gda-devices.xml:device instance available and its type • BLxxI-gda-types.xml: interface and subsystem definitions • XML schema (epicsgda.xsd) • Define the XML file structures and interface types • generate object marshall/unmarshall codes • Minimise change impacts between GDA and EPICS

  15. Extension mechanism • Support 3rd party software as plugins to GDA • Simple to use by copy/drag-drop and configure • Currently only GUI Panel based • motion control OE plugin • Data reduction and analysis plugins • Standard location for the extension jars • Enable auto class load at start • Configuration - XML <Plugin> <name>PanelName</name> <pluginName>package.Classname</pluginName> </Plugin>

  16. Data management • Data handler demon/windows service – DDH • High throughput • Transfer of data off beamlines to backup & Storage Resource Broker. • Remote access to data via SRB • Virtual File System (vfs) • Authenticated and authorized access • Support NeXus, ImageCIF or SRS files • In processing of adding metadata handling

  17. Data Visualisation • Integrated Data Visualisation Tools • 1D, 2D, 3D • In processing of integration • Data fitting • Integration with IDL • Direct access to IDL objects to display data

  18. Built-in Editors • Script Editor • Syntax highlight • Scripts queue • OE Editor • Create new OE representation for devices • Save in XML format file • XML Editor (to be developed) • Dynamic editing of configuration data • Graphic tree viewer/editor for non-expert

  19. Message Services • Event Passing System (EPS) • messages from devices are broadcast to clients • a log kept of all messages to help data analysis after the experiment • Messages also displayed on the GDA GUI • Customisable: Levels, Types, Colour Coded • Message Category • Alarm, Warning, Info, and Debug • Message Viewer • Support message filter

  20. GDA deployment tools • Multi-Machine Client/Server deployment • RPM via Red Hat Network Satellite Server • Single Machine Standalone deployment • Java based installer • GDA Launcher • Script launchers • Python launchers • Support quick configuration changes

  21. Future Development • Implement Role-based Access Control • Integration with Diamond user liaison office (ULO) • Integration with Single sign on (SSO) system • Integration with Science-specific programs • Integration with eScience facilities • Simplify configuration processing • Improving usability – GUI, Help, messages, exception

  22. SRS Staff Greg Diakun (Head) Geoff Mant Paul Stephenson Karen Ackroyd Glenys McBain Steve Kinder Christine Ramsdale Mike Miller DLS Staff Bill Pulford (Head) Stuart Campbell Adrian Mirea Vasanthi Nagalingam Matt Pearson Paul Quinn Eric Ren Stuart Robinson Richard Woolliscroft Fajin Yuan Alan Ashton Karl Levik Acknowledgement

  23. Thank you for your attention

More Related