• 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) 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)

http://nsls-ii.github.io/bluesky/hardware

bluesky devices:
readableDevice (go take a reading and tell us result, read is synchronous)
flyableDevice (start the device, then leave it to do it's own thing asynchronously)

we don't use settableDevice (like a motor)

ophyd is a collection of specific devices that implement the bluesky xface
(e.g. epicsmotor)

following https://github.com/pcdshub/pcdsdaq/blob/master/pcdsdaq/daq.py to be a bluesky device, need: (documentation site has a more complete list)

• stop
• trigger
• read
• describe
• kickoff (optional?)
• complete (if we have kickoff)
• collect (if we have kickoff)
• describe_collect ("")
• configure (was used for number-of-events to record, or duration)
• read_configuration
• describe_configuration
• stage
• unstage
• pause
• resume

Be aware:

• 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