Make Undulator gap writeable - i18

[stan-dot]

This is for beamline alignment lookup tables at i18 https://github.com/DiamondLightSource/i18-bluesky/issues/12

At the moment it only implements the StandardReadable interface

Acceptance Criteria

• can be run in a plan

[stan-dot]

i03, i04 and i22 +p38 use this device. @DominicOram do you have any tips/requirements for this issue?

[DominicOram]

We already do set it in https://github.com/DiamondLightSource/dodal/blob/main/src/dodal/devices/undulator_dcm.py. We just wrap it in a composite device with the DCM as we want to always move both at the same time. Presumably you want to do that too? Or are you just moving the undulator? Does this just boil down to adding a set method that calls gap_motor.set?

[stan-dot]

I am not sure, will investigate with @iain-hall

[stan-dot]

yes, ordinarily for scans they move syncrhonously, but this use case is for adjusting them, setting up the desired gap between the elements.

in this instance, we do need to move those independently from one another, therefore we need to have a movable undulator.

Either we make an update to the existing Undulator. This sounds more DRY but might disrupt existing workflows. An alternative would be to make a new, lookup-tables specific undulator, used only for those times and discarded afterwards. This could be beamline specific or not.

The latter should be fairly simple, as in GDA it's just a simple EpicsMotor at the moment.

[stan-dot]

will also need a new device that uses redis-cached lookup tables instead of the filesystem text files.

[DominicOram]

An alternative would be to make a new, lookup-tables specific undulator, used only for those times and discarded afterwards. This could be beamline specific or not.

The undulator_dcm I linked already does this. You can just move that behaviour into the undulator instead and we can use it in both cases.

will also need a new device that uses redis-cached lookup tables instead of the filesystem text files.

Do you have an existing redis-cache for this? Have you discussed with the scientists how they want to update it?

[stan-dot]

this will be exposed as a task in the i18_bluesky, and would be updated from there. perhaps another endpoint would display what the current values are? redis-cache needs deployment from scratch.

Ok thanks, I'll move that behavior into the undulator (make it have the motor)

[stan-dot]

redis deployment is tracked here https://github.com/DiamondLightSource/i18-bluesky/issues/4#issuecomment-2249796166