You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

  • No labels