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