- 2D (1D) ROI or an hsd threshold
- Go into the configuration database?
- go direct to DRP via ZMQ?
- needs to be stored in xtc on configure (might be tricky)
- config db persists the settings
- users may forget those settings, need a way to look at them?
- DRP would read the parameters from the configuration db (would require a reconfigure) (might be tricky)
- need tool for switching between configurations? BEAM/NOBEAM is not sufficient because it's too global, maybe need something detector specific
- have a time-series of detector configs in db is not good enough: need a way to "name" them, switch between them and view them at a detector level (might be tricky)
- have a general interface to ConfigDB, ami is one example of a client using that interface
- don't want this LCLS-specific feature/dependency to prevent ami from being used world-wide
- try-import and disable the feature if it doesn't exist
- parameters that are presented to the user are set in some sort of config file (not everything in configdb) (might be tricky). could use config dgram as a starting point, but might be too much stuff
- special tag for user-drp parameters in xtc? then ami could figure out automatically.
- for simplicity this approach does not address fast/automated changes (1 second): treat real-time ami feedback (e.g. to control a motor) as a separate issue
- should ami have "apply" button to (1) send to db and (2) generate a daq configure transition?
- AMI writes json to config
- json2xtc
Starting points for Seshu:
- look at caf's "configdb" CLI
- look psdaq/psdaq/configdb/*store.py (opal_config_store.py is simple)
- for drp xtc generation: maybe xtcdata/xtcdata/xtcwriter.cc (C++), or (probably better) is returning json from python (like psdaq/psdaq/configdb/opal_config.py) and converting to XTC like psdaq/drp/BEBDetector.cc:translateJson2Xtc(). a third approach is the cydgram (cython) approach in psdaq/psdaq/control/control.py.
Overview
Content Tools