Initial Thoughts

• 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

...

rule 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"

Meta Data Example (ued)

psexport01$ xtcreader -d -f /cds/data/psdm/ued/ueddaq02/xtc/ueddaq02-r0028-s000-c000.xtc2 | grep step_docstring
Name: 'step_docstring' Type: 10 Rank: 1
1: 'step_docstring' rank 1, type 10
'step_docstring': "{"detname": "epixquad_0", "scantype": "pedestal", "step": 0}"
1: 'step_docstring' rank 1, type 10
'step_docstring': "{"detname": "epixquad_0", "scantype": "pedestal", "step": 1}"
1: 'step_docstring' rank 1, type 10
'step_docstring': "{"detname": "epixquad_0", "scantype": "pedestal", "step": 2}"
1: 'step_docstring' rank 1, type 10
'step_docstring': "{"detname": "epixquad_0", "scantype": "pedestal", "step": 3}"
1: 'step_docstring' rank 1, type 10
'step_docstring': "{"detname": "epixquad_0", "scantype": "pedestal", "step": 4}"
 
psexport01$ xtcreader -d -f /cds/data/psdm/ued/ueddaq02/xtc/ueddaq02-r0028-s000-c000.xtc2 | grep step_value
Name: 'step_value' Type: 7 Rank: 0
0: 'step_value' rank 0, type 7
'step_value': 0
0: 'step_value' rank 0, type 7
'step_value': 1
0: 'step_value' rank 0, type 7
'step_value': 2
0: 'step_value' rank 0, type 7
'step_value': 3
0: 'step_value' rank 0, type 7
'step_value': 4

Psana Step-Store Approach

The idea here is tomake the bluesky scans look the same as det-config scans.  Mona’s step-store (from “detnames -s”) contains a list of variables, which in both cases includes step_value, step_docstring ("metadata").  In the case of a bluesky scan it also includes the PV values.  In the case of a config scan the configs themselves get updated on each step.

Sample Scan Script

Note that the step_docstring is json as per Mikhail's suggestion above.

from psana import DataSource
import sys
# a config scan for epix                                                          
ds = DataSource(exp='ueddaq02',run=28)
myrun = next(ds.runs())
step_value = myrun.Detector('step_value')
step_docstring = myrun.Detector('step_docstring')
for nstep,step in enumerate(myrun.steps()):
    print('step:',nstep,step_value(step),step_docstring(step))
    for nevt,evt in enumerate(step.events()):
        if nevt==3: print('evt3:',nstep,step_value(evt),step_docstring(evt))