1. TXO
freelance mxCuBE & more

2. About Worked at ESRF for roughly 20 years
Worked at basically all BLs and particularly MX beamlines
Pushed for automation projects from 2002
Funded TXO ( TXOlutions.com ) in September 2011
Personal and professional project
Freelance and more
Combined with exotic destinations (NGO work)

3. Domain of expertise Consulting , Development , Training in
Software for experiment control in synchrotrons and small x-ray sources

4. Assets Proven experience in experiment control
Programming: Python, C/C++, Graphical interfaces
SPEC

5. Portfolio Regular customer - CSS / Certified Scientific Software
spec projects with Bessy, Pohang Acc., Indus2
mx software with MaxLab (I911-3) and Alba (Xaloc)
Industrial - Xenocs

6. mxCuBE and more Do you remember? It was back in 2003
It was already a big improvement
We also thought it was already quite complex :

7. Components (2003)

8. mxCuBE seen from ESRF Automation key-stone
Integrated in the general ESRF strategy for software and instrumentation developments (and I mean, not only for MX beamlines)

9. mxCuBE and ... mxCuBE (at ESRF) is :
a graphical Python/Qt application based on BLISS framework
Underlying control of hardware done with spec and Tango
Collection routines (partly) done with spec macros

10. If you want mxCuBE You need: A synchrotron, a beamline, a computer
Select and install all the hardware you will use
Install a number of pieces of software
Configure everything
And.... glue them all together with some dose of expertise !!
Test, validate, adapt
and then upgrade from time to time

11. ... and more Complexity #1 - Features / Integration Autocentring EDNA
ISPyB
MD2
Kappa and STAC
User login
Sample changer
Tango servers
Detector software
Remote access
Beamline alignment
SPEC
Taco
Crystal ranking
ADXV
Spiral collection
Energy scan
PyMCA
Tango
Screening of crystals
CCP4
Collection queue
Powder
Annealing
XRF analysis
Thumbnails
Beam centering
Transmission
Workflow
Barcodes
SR Machine info
Cryo
Resolution
Radiation damage
Submit feedback
User office
Holder length
....

12. Complexity #2 - Software internals
Bricks
Hardware Repository Server
Hardware Objects
Socket communication
Events
xmlrpc
LDAP
Qwt
Khoros
zmq
xml configuration
Jive
....

13. Complexity #3 - Hardware
Icepap
Pilatus
Attenuators
Slits
i0 monitors
..... (alright... you got the idea... )....

14. Complexity #4 - Collaboration
Collaboration required at least at three levels:
Internal: MX group, BLISS, ISG, SciSoft, SEG
On site: EMBL / ESRF
Between partner institutes: MaxLab, Bessy, Alba, ESRF, Soleil

15. ESRF

16. Some notes out of this afternoon presentation
High degree of stardisation for users (same collect GUI) through mxCuBE
Little automation (centring, EDNA, ISPyB)
Not clear to me how much queues are used outside ESRF
Common needs mentioned (at least at two sites)
CATS irelec sample changer in mxCuBE
Centring in mxCuBE (autocentring)
Upgrade mxCuBE without overwriting local changes
ISPyB

17. REAL STORIES FROM THE FIELD / LESSONS LEARNT
Case Study 1: MaxLab
Following ESRF choices. Perspective after some years.
Case Study 2: Alba
Integrating mxCuBE technology within a different technical context

18. Partners ESRF had (and has) always a commitment to share developments
Initial strategy (MaxLab, Bessy)
Copy faithfully the choices made at ESRF
ESRF staff helped and trained MaxLab and Bessy staff
Conclusion: Good benefit for scientists and users. Standard cannot be stronger
Weakness of the model:
Local choices and constraints
Local expertise is limited (“alien” technology)
Evolution of the software / Local changes (overwritten) redesign rather than configure
ESRF staff availability

19. CASE STUDY 1 - MAXLAB
I911-3
Initially copied all ESRF choices (everything ! including the rackable PC model)
It has been running experiments with mxCuBE for years
First version needed adapting mxCuBE:
No sample changer, no ISPyB, no control of attenuators...
Some software developments were made locally, integrated. Proved the modularity of mxCuBE is good.

20. C.S. 1 - MAXLAB (2) But... Software got frozen. No upgrades
ESRF kept adding features that did not get to Lund
New instruments (like sample changer arm) different from ESRF need to be integrated
Changes in staff made that the limited local expertise in mxCuBE became even more scarce

21. C.S.1 - MAXLAB (3) Situation after a first intervention:
Assessment of needs done
Number of bugs solved from very first version installation
Latest mxCuBE version v2.0 is now functioning and able to do collections but... many of the features (remember complex. slide no 1) are not yet available (they never were)
Still needs work (quite)
Good help from ESRF, EMBL, Maatel

22. C.S. 1 - MAXLAB (4) After the intervention is finished:
Evolution/Upgrade will require effort
Local expertise still missing
Future upgrades will still be painful
MaxLab has chosen Sardana for Max-IV ( see next C.S.)

23. CASE STUDY 2 - ALBA Xaloc beamline Freshly and successfully started
Local control system, software choices different from ESRF
(Sardana, no SPEC, Qt4...)
The core of mxCuBE needs to be rewritten
Basic Data collection is already running with new system
Clear, committed goal to share and to profit the most of the collaboration

24. C.S. 2 - ALBA (2) ALBA will use, as such, software blocks like: EDNA
PyMCA
C3D
....
Willing to profit of experience in collection sequences... but... how?
Working now on multicollect, autocentring....

25. Thoughts for discussion
Thought #1: How to make software Upgradable and Customizable?
Implementation (encapsulation, abstraction)
Interface between componentd (clear, stable, documented) - the train interoperability case
Configuration! Beyond the design mode (it would have ease the move from v1 to v2)
Multiple integration options always better than one (example of EMBL software)
Thought #2: How to make expertise to develop or to make it available?
Networking, communication, training
Thought #3: How to share developments?
Delegation, specialization, Or even.. why not...subcontracting (ahem)
Thought #4: The case of ISPyB ?

26. TXO This presentation was brought to you by: