Closed ksunden closed 2 years ago
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...
Closed by #72
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:
has-dependent-daemons
, which introduces and standardizes a yaq messageget_dependent_yaq_params
(names flexible), which returns ahost:port
string for each dependent yaq daemon.yaqc_bluesky will surface this info (as yet details of implementation are subject to change.)
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:
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.