BlueapiClient asks blueapi server for all available devices and then caches them. This makes it so autocomplete now works on the terminal making it very handy when composing plans on command line. However, blueapi cannot handle child devices.
Very often, a device will hold a group of other devices / signals and need to be accessed to run plans. For example Motor stages will have x, y, z motor components. pgm devices have child signals/motors for energy.
So a very basic example would be
plans.set_absolute(pgm.energy, 500)
plans.set_absolute(stage.x, 10)
plans.set_absolute(stage.y, 20)
BlueapiClient has no idea these child devices of energy, x, and y exist so the user has to guess what is available.
How it works is if it doesn't exist from the cache, the device is requested from the server and then if it exists, it is then added to cache and then autocomplete now works. However, when loading devices, BlueapiClient should be aware of all devices on the server, including all child devices of a Device, so that automcomplete will work straight away rather than guessing first for all devices.
This is related to DiamondLightSource/dodal#2208 because DeviceManager only provides the higher level devices to blueapi and not the device children so it has not concept of the child devices unless asked explicitly to check for it.
This would vastly improve the user experience using the client if you could print the device tree or the device __repr__ to show it (similiar to a plan __repr__ displays the plan signature) to know what is available to work with and that auto complete for child devices works from the start.
As we are going to have name clashes with device attributes and what blueapi needs, we should probably reserve in dodal device attributes so that they never have a model signal / sub device. Similar to how ophyd-async reserves bluesky key words. This could be done inside DeviceManager. When it loads in a device, it checks there are no signals / child devices with model as an attribute.
BlueapiClientasks blueapi server for all available devices and then caches them. This makes it so autocomplete now works on the terminal making it very handy when composing plans on command line. However, blueapi cannot handle child devices.Very often, a device will hold a group of other devices / signals and need to be accessed to run plans. For example
Motorstages will have x, y, z motor components. pgm devices have child signals/motors for energy.So a very basic example would be
BlueapiClienthas no idea these child devices of energy, x, and y exist so the user has to guess what is available.How it works is if it doesn't exist from the cache, the device is requested from the server and then if it exists, it is then added to cache and then autocomplete now works. However, when loading devices,
BlueapiClientshould be aware of all devices on the server, including all child devices of aDevice, so that automcomplete will work straight away rather than guessing first for all devices.This is related to DiamondLightSource/dodal#2208 because
DeviceManageronly provides the higher level devices to blueapi and not the device children so it has not concept of the child devices unless asked explicitly to check for it.This would vastly improve the user experience using the client if you could print the device tree or the device
__repr__to show it (similiar to a plan__repr__displays the plan signature) to know what is available to work with and that auto complete for child devices works from the start.As we are going to have name clashes with device attributes and what blueapi needs, we should probably reserve in dodal device attributes so that they never have a
modelsignal / sub device. Similar to how ophyd-async reserves bluesky key words. This could be done insideDeviceManager. When it loads in a device, it checks there are no signals / child devices withmodelas an attribute.