BLISS + UI meeting, 24/03/2021

Daiquiri Recipe

1. White Rum

2. Lima juice

3. Fine sugar

4. a drop of

?

Back in 2015

BLISS design, how to share objects in multiple processes ?

Objects could be independent in each process,

state would be shared via peer-to-peer communication !

 

Objects would be locked via a distributed lock manager, to avoid concurrency issues

All I/O based on gevent

cooperative multi-tasking

Direct hardware control

Distributed

objects state

Persistent

settings cache

 Data publishing,

Transient storage

Scan acquisition chain, represented as a tree

BLISS key principles

Independent objects, p2p state exchange, DLM for locking

Like Hydroxychloroquine against COVID, this approach is appealing in vitro, but it is not the same business in vivo

1. "independent objects" connect themselves to devices, but most devices do not accept multiple connections !

 

2. State exchange has to be made right

(i.e "a la redux" OK ; case-by-case, hand-made BAD)

 

3. Distributed Lock has to be made right

Today in BLISS

  • BLISS channels can do P2P exchange
    • based on Redis PUB/SUB
  • we have an ad-hoc implementation of DLM within Beacon
  • BLISS Proxy, Service or Tango servers to be able to talk with devices that accept only 1 connection (all serial line, GPIB, even TCP controllers) from several clients

Direct hardware control

Distributed

objects state

State of channels usage in BLISS

Axis Object

Beacon Object:

signals property changes

(AutoFilter, Keithley, MCA, Lima parameters)

ESRF Beam Viewer

AMC100 motor controller

Multiple Positions Object

Shutter

Transfocator

New from Stuart: MeasurementGroup

Few objects, and only a few of them are really exposing state changes "properly"

(= coded with this goal in mind)

but still, far from a systematic

implementation

What's next ?

Continue with P2P state sharing,

DLM, servers ?

How to make it complete + robust ?

How much effort it is ?

?

What's next ?

Wait a minute...

Why do we need distributed BLISS objects ?

Use cases for "distributed" BLISS

1) multiple sessions sharing hardware

 

2) executing background activity: regulation, monitoring

 

3) beamline graphical applications

Multiple sessions

Allow users to group devices together under a logical "name" (oh, eh1, microstation, fourc...)

 

or to group by function (alignment, exp)

 

 

Ultimate goal: independent shells

Today: multiple processes, objects need to share state and control

Proposal: single process, different "views", all objects living together

Executing background activity

Regulating a monochromator (ID26)

 

Starting and following an "infinite" move (rotating axis, ID22)

 

Temperature monitoring / diode reading / live BPM

 

Today: different processes     to have independent shells,

to be attached to another CPU, to limit interaction with users

if needed, we can improve BLISS acquisition system to use multiple CPUs

can be done with different "views"

Beamline graphical applications

Based on Daiquiri : web server + front-end application

 

Users have a nice graphical application for some experiments,

and still use the shell for alignment or other things

 

Hence, the use of multiple processes

What if a web shell would become main BLISS entry point ?

Beamline graphical applications

Advantages of a web shell

Rich graphical interface

  • the shell itself is just one component
  • many components could be added around: synoptic, state of shutters and "in/out" devices, counters selection helper in measurement group, ...
  • links to other web apps (for example bpm, electronic logbook, data portal ; in the future: web Flint)

Multi-clients by nature

Well suited to offer multiple views

(multiple tabs ? or SPA ?)

tmux would disappear

Proposal: some BLISS into Daiquiri

BLISS could provide a basic server with a basic BLISS shell web application

  • built on top of ptpython (we do not lose our investment)
  • with known technology like Flask, websockets, xterm.js
  • BLISS Shell React component

This would be the new entry point for BLISS on beamlines (still possible to start BLISS like today, but not recommended anymore)

The BLISS server-side code + React component could be put in any Daiquiri application ; Daiquiri apps would extend this shell