Darren Spruce, Jose Gabadinho

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
• Practical Advice for support of servers
• Discussion

3
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
Hardware Objects
Data Collect
Minidiff
Sample Changer
ISPyB client
DNA server
Energy (scan)
Camera
LDAP
5
Collect Data sequence example
mxCuBE
SPEC
SC Tango server
User/DNA
Taco servers
ISPyB
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_Di
  agnosingTips.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.

11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
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 doesnt 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 experiments 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
spec
sample changer
ISPyB server
Jpeg server
15
Servers http server-status page
ISPyB server
Jpeg server
DNA server

http//beamline2224/server-status
http//beamline2222/server-status
http//cluster2223/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??_at_beamline mxCuBE
• framework executable opid??_at_beamline startGUI
• log file blissadm_at_beamline/log/mxCuBE.log

• DNA server
• log file (same as mxCuBE) blissadm_at_beamline/log
  /mxCuBE.log
• configuration blissadm_at_beamline/local/HardwareR
  epository/dnaconnection.xml

• ISPyB server
• executable blissadm_at_beamline bliss_dserver
  restart ISPyBServer
• log file blissadm_at_beamline/log/ISPyBServer.log
• configuration blissadm_at_beamline/local/HardwareR
  epository/dbconnection.xml

• Jpeg server and client
• server executable you_at_cluster sudo
  /etc/init.d/jpegserver stop start
• configuration blissadm_at_beamline/local/HardwareR
  epository/jpegconnection.xml

17
Discussion

• Any suggestions to improve the support of the mx
  software?