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
BLISS + UI meeting
By Matias Guijarro
