• all controlled by bluesky
• multiple scan variables can be controlled either by controls and/or daq
  • variables could be drp parameters
• option 1 (preferred for uniformity): all scan variables made visible in epics where possible
  • issue: feels like this could be awkward for daq: need another thread/process watching epics.  maybe device doesn't permit separate configure/data processes (e.g. if they share same pgp virtual channel)
• option 2: scan variable not epics and is a daq var controlled by a daq executable participating in transitions:
  • transmit configUpdate json on zmq phase of transition
  • json specifies which detector is responsible (e.g. xpphsd) for updating scan var, and an epics variable to set when complete
  • that daq executable must understand that json and record it to xtc configUpdate transition
• at configure time: bluesky hands json describing the scan (names, initial values) to the scanning node(s) which are translated to xtc by json2xtc
• at configUpdate time: get similar json just with updated values
• this json is distributed on first phase of configUpdate transition
• who receives this scan info?
• how does the daq tell bluesky if its scan var is ready to go?
• configUpdate transition goes through the timing system with usual two phase pattern
• ami only moves forward in time.  for arrays only have to update dgram (since python-config points to arrays) while for numbers/charstr/enum have to update both dgram and python-config
  • issue: dgrams are read-only

BlueSky Conversation with Teddy/Zach/Clemens/Chris

conda install bluesky ophyd (comes from conda-forge)

...

• make sure to return correct "status" objects from appropriate methods
• try not to block: start a start a subprocess, and return a "future" status
• if we return correct status, then don't have to do future stuff: gets handled by bluesky
• obscure: not clear exactly what configure should do

Interaction with DAQ

See page from Chris Ford here: DAQ Scans

...

All 4 mechanisms will indicate completion via EPICS variables.  We will try to get the EPICS variables to behave in the same fashion to make it more uniform for the BlueSky script.

Config Scans

Discussion with Matt on Aug. 24, 2020

• DAQ will code config object "deltas" on begin step transition
• deltas will be sent to segment level as json and use mcbrowne's JsonToXtc2 translator (unlike epics scans which use Eliseo's translation in BlueSky script)
• deltas will have a special "alg" field ("configDelta"?) that mona can use to detect them (the "drpClassName" on this page: Raw Data Python Interface)
• deltas will be associated with the original config dgram by the detector name (plus other info?)
• mona will apply deltas using the python "dot" interface, and hopefully the reference counting is done correctly in dgram.cc so that works (not 100% confident of this)
• we would ideally support jumping backward and forward in time across calibcycles, as we do for the epics variables

Meta Data Discussion

Discussion on Dec. 3, 2020 with Matt/Mikhail/Dan/Chris

• Currently the Step object has two pieces of metadata that represent the scan step:  "docstring" and "value"
• The actual "complex" changes on a step are updated in the epics store (epics scans) or the appropriate configuration objects (configuration scans)
• We should support scanning multiple detectors at the same time
• Feels like that requires some known structure in the meta data, e.g. if we are scanning 3 epix detectors:

formula for the docstring: "detname_scanname_step"
scanname "chargeinj7" means every 7th pixel
scanname "chargeinj3" means every 3rd pixel

step_value = 0
step_docstring = "epix0_chargeinj_0; epix3_chargeinj_0; epix7_chargeinj_0"

step_value = 1
step_docstring = "epix0_chargeinj_1; epix3_chargeinj_1; epix7_chargeinj_1"