MX Software

1. MX Software Darren Spruce, Jose Gabadinho

2. Contents • Dependencies between components • Framework modules • Data collection sequence example • ISPyB remarks • What SPEC does • On call support tools • Work organisation

3. HW: MD/SC/motors BlissFramework DNA server Data Collection ISPyB client JPEG client SPEC (Instrument control sequences) Data collection Realignment Detector Control Energy scans mxCuBE LDAP User Office ISPyB ISPyB Server JPEG Server DNA Taco Servers Tango Servers Hardware

4. BlissFramework Bricks Data collect MiniKappa Sample Camera Sample List Proposal (login) Energy scans MX Software specific components Commands Detector Resolution Attenuators Data Collect Hardware Objects Minidiff Sample Changer ISPyB client DNA server Energy (scan) Camera LDAP

5. Collect Data sequence example User/DNA ISPyB mxCuBE SPEC Taco servers SC Tango server Login Get user Login ref Collect data Load sample (tango) Sample loaded (or error msg) Collect Pars Collect data Shutters, Gonio, Detector control Image collected (or error) Image info Unload sample Sample unloaded (or error) Data collect end Status

6. ISPyB (Information System for Protein crYstallography Beamlines) • Start it by typing ispyb in a web browser http address field • Not necessary for data collection but increasingly relied upon for data tracking • If blocking use blank for login name and generic beamline password to log into mxCuBE to collect data • Absolutely mandatory for pipeline experiments

7. SPEC macros • Standard on all mx beamlines • Basic data collection loop done here • Other functions: • Quick realign, energy scans, calibrated intensities, diagnostics, SC interlocks,take powders, centre beam…. • Events triggered through SPEC variables are obscure in the macro code • Some unit testing available (only used by me)

8. Mx and BLISS Support (from home) • All mx stations have x11vnc on control workstation (type x11vncl logged in as opidxx, then use vncviewer) • http://www.esrf.fr/computing/bliss/guides/mx/02_DiagnosingTips.html • Excellent performance if used with broadband internet connection and nxclient • Problems can be difficult to clarify by phone but easier to see with access to the control workstation screen • Log files in blissadm give clues to recent activity • Future plans to expand remote accessibility include web camera views of hardware and sample environment. Also a master/slave GUI control

9. Work Organisation • Weekly Operations meetings, ATF, ISPyB, DNA Video conferencing • proximity between MX BLISS members (many impromptu meetings discussions are easy) • Mxfeature to help coordinate work between MxGroup and BLISS • Packages built and distributed with blissinstaller with separate area for mx specific stuff. no development platforms

10. Results in 2006 • 2391 scheduled experimental sessions on 8 beamlines • 613 sessions used for testing software • 141444 data collections • 3664532 images collected • Total exposure time of 1077610 seconds.

14. Dependencies • mxCuBE • GUI to control the instrumentation, insert and display ISPyB information, get collection parameters and build oscillation parameters • Python exceptions: check Details tab and mxCuBE log file • bricks & hardware objects • modules (BlissFramework, SpecClient, etc.) • spec (exp.hutch) • controls the instrumentation (duh!) • required for (almost) everything • can be restarted without affecting (much…) mxCuBE • if mxCuBE doesn’t see spec (all motors are red): • probable SpecClient connection problem, restart spec & mxCuBE • sample changer • controls the sample changer (duh!) • required for pipeline • if device server fails mxCuBE must be killed and restarted • check Windows application for dialog boxes • if problem persists, stop the device server, call spec macro SCIsInUse 0, restart mxCuBE • ISPyB server • inserts and retrieves all experiment’s info in the database (sessions, samples, collections, etc.) • not mandatory • can be restarted (or die) at any time: before login, before collection, during collection • if server is down when logging in, mxCuBE will use the local user login • Jpeg server • converts the detector images to jpegs (saved in the long-term storage archive) • not mandatory • one http server per beamline running on the cluster • DNA server • mandatory server for the DNA application (DNA project terminology: mxCuBE is the BCM) • asynchronous sockets (instead of a dedicated thread): server embedded inside mxCuBE • if DNA complains: • first try to restart only DNA • if persisting: restart mxCuBE mxCuBE DNA server sample changer ISPyB server Jpeg server spec

15. Servers’ http server-status page ISPyB server Jpeg server DNA server http://beamline:2224/server-status http://cluster:2223/server-status http://beamline:2222/server-status • is it responding? • configuration • latest request • MySQL python library status • is it responding? • configuration • latest request • status (conversion, error, thread) • is it responding? • configuration • latest request • current login and collection mxCuBE the emerged part of the iceberg

16. Where to get more information? http://www.esrf.fr/computing/bliss/guides/mx/ • mxCuBE: • executable: opid??@beamline% mxCuBE • framework executable: opid??@beamline% startGUI • log file: blissadm@beamline:~/log/mxCuBE.log • DNA server: • log file (same as mxCuBE): blissadm@beamline:~/log/mxCuBE.log • configuration: blissadm@beamline:~/local/HardwareRepository/dnaconnection.xml • ISPyB server: • executable: blissadm@beamline% bliss_dserver restart ISPyBServer • log file: blissadm@beamline:~/log/ISPyBServer.log • configuration: blissadm@beamline:~/local/HardwareRepository/dbconnection.xml • Jpeg server and client: • server executable: you@cluster% sudo /etc/init.d/jpegserver [stop | start] • configuration: blissadm@beamline:~/local/HardwareRepository/jpegconnection.xml

17. Discussion • Any suggestions to improve the support of the mx software?