- 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)
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
Interaction with DAQ
Results of a conversation with Chris F. and Matt on
4 ways for scans to interact with the daq:
- tell the daq to take, e.g., 1000 events with readout group 4 (not counting events with dead time)
- Controlled via two PVs
- $(BASE):XPM:$(MASTER):PART:$(GROUP):ScanEnd - Event number to stop at
- $(BASE):XPM:$(MASTER):PART:$(GROUP):ScanGroups - Readout groups to stop
- End monitored via PV $(BASE):XPM:$(MASTER):PART:$(GROUP):ScanDone
- resets to 0 when Event number set
- raises to 1 when Event number reached
- Controlled via two PVs
- launch a sequence (more complex than the above but, in some sense, a special case)
- Controlled via several PVs or seqprogram.py <sequence.py> <PVBase> (PVBase is $(BASE):XPM:$(MASTER):SEQENG:0, for example)
- End monitored via PV $(PVBase):RUNNING
- raises to 1 when sequence starts
- resets to 0 when sequence completes (assuming CheckPoint instruction is in <sequence.py> - see psdaq/psdaq/sequence/finite.py for an example)
- free-run until a user-defined drp trigger count (from the teb) is met
- free-run until a user-defined ami condition is met. only suitable for low-rate expts where all events can be monitored, but easier and more flexible than the drp-trigger-count method above
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.