Dependent hardware daemons

[ksunden]

Some hardware, notably OPAs and the (in progress) SDC delay cause underlying daemons to move position.

This issue (following a phone conversation with @untzag) summarizes our strategy for dealing with this:

• Create a yaq trait has-dependent-daemons, which introduces and standardizes a yaq message get_dependent_yaq_params (names flexible), which returns a host:port string for each dependent yaq daemon.

• yaqc_bluesky will surface this info (as yet details of implementation are subject to change.)

  • Ideally the name of the data key does not change between scans which directly interface with the underlying daemon and scans which interface via the controlling daemon... a more ophyd like parent/child approach may involve namespacing these data keys, a more naive approach may involve double defining keys, which would be less than ideal.)
  • Alternative to in yaqc_bluesky would be to do so at the plan level, which may solve the namespacing problems, but may be less transparent/harder to know what is going on.

  This means that with minimal yaq implementation (adding a trait and defining a single method that returns info already available to the daemon) and no additional human written configuration (or happi for that matter) we can describe these relationships and keep data files relatively minimal (only record data at each scan point for motors that move, even if bluesky doesn't know they are moving itself), without missing out on valuable info that may not be what was "intended" to be the useful axes.

  Potential implementation:

  • perhaps in a stage step communicate with the bluesky objects, which will cause them to be in the plan, I think? have to look at this a bit.

[ksunden]

https://github.com/bluesky/ophyd/blob/dd4b3e389a0202ecacce39fc3965d703c616b0d4/ophyd/device.py#L1233

For reference, Ophyd handles this via "Components" which are just tacked on to the read/read_configuration (and describe counterparts) transparently.

I don't think it should be a real problem to double define (they should all be done moving anyway... and this really only makes sense for motors) should be pretty easy, all things considered, though may wish to build in caching to Device (perhaps as simple as @lru_cache on Device) to avoid having many copies of identical clients floating around... though that could lead to problems when you want to regenerate the client...

[ksunden]

Closed by #72