- 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 control level json describing the scan (names, initial values) 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
Overview
Content Tools