Strategy for BLISS
Matias Guijarro - BLISS team
Beamline Control Unit, Software Group
EDMB
5th April, 2018
Grenoble - France
BLISS
BeamLine Instrumentation Support Software
- Control system for beamline experiments
-
Integrated environment
- Command Line Interface
- Configuration application
- Online data display
-
State-of-the-art beamline control
- continuous scans, trajectories, data management
Ready for new challenges
3-part BLISS development strategy
1. BLISS team: core development
Project responsibility
Enforcing good practices
-
version control, code review, pair-programming, refactoring, tests, CI
Scrum methodology
Training to users and scientists
2. Renewal of packaging & software deployment
3. All-in-one solution
A paradigm shift
after 26 years of Spec
BLISS roadmap to 1.0.0
- Configuration
- Motor control
- controllers, virtual, motion hooks
- trajectories
- Sampling & Integrating counters
- P201, Keithley, Wago, ...
- Eurotherm, Lakeshore, Oxford...
- MCA
- all XIAs
- Lima
- Images, BPM, roi counters
- MUSST, OPIOM, PEPU, Speedgoat
- Scans
- ascan, dscan, etc.
- continuous
- HDF5 file saving
- data publishing
- Metadata (ICAT)
- Online visualisation
- interaction with plots
- HKL
- Documentation
- Stable API
BLISS deployment strategy
The pioneers: SB beamlines
-
BLISS in user operation since 2016
- ID30A-1, ID30A-3, ID30B, ID23-2, ID29, ID23-1 (on going), BM29 (this summer)
-
Specific case
- Spec-free graphical user interface as main application
- no user sequences
- fixed hardware, same experiments
-
Constraints
- reliability, industrial standards
Lessons learned
-
Aim for a complete transition to BLISS
- do not keep Spec at all once BLISS is ready
-
Tests on beamlines are much better than with any simulator
- real conditions, significant results
- helped finding dozens of subtle bugs
-
Human adventure
- motivation & commitment
- mutual understanding
- trust (even faith !)
Other early adopters:
ID31, ID15A, ID11
Many thanks !
BLISS in 2018
-
Objective: release of BLISS 1.0.0
-
Assessing BLISS for various experiments in real conditions
2018 projected timeline
BLISS in 2019
Full Spec replacement on selected beamlines
2019 proposed BLISS beamlines
already started in 2018
Graphical User Interfaces
They did not know it was impossible, so they did it
Mark Twain
Help needed
1. Beamline review
- integration of missing hardware in BLISS
- specificities: special Spec macros, edge corners
- description of experiments after shutdown (what to change ? new ones ?)
2. Having a scientist available during 2019 and 2020 for the beamlines to convert
- help BCU engineer with project planning (milestones, priorities...)
- answer questions
3. Commissioning
Mitigating risk
-
What can be done to help with the workload ?
-
What are the weak points and how to overcome the situation ?
High workload for BCU
Development tasks
Maintenance of BLISS on early-adopters beamlines
Bugs fixing
2018
Installation on target beamlines
Training to users and scientists
Bugs fixing
2019, 2020
Development tasks
Training to BCU members
Be careful with CODs attached to beamlines
It is great help, but it requires (a lot of) management and coordination
18-month contracts are too short
Graphical User Interfaces
There is a lack of UI designers within BCU
Nice graphical user interfaces require specialists
Conclusion
- BLISS team is necessary for the project
- BCU members time will mainly be spent on BLISS transition during shutdown
- Half of the beamlines can be converted to BLISS during shutdown
- Availability of beamline scientists during transition
- Graphical interfaces development needs a push
BLISS from 2018 and beyond
By Matias Guijarro
