DiamondLightSource / DiamondLightSource/mx-bluesky
Parameter Model: LoadCentreCollect shouldn't need a valid multi_rotation_scan on instantiation
- Dominant language
- Python
- Stars
- 4
- Forks
- 5
- Avg merge
- 1d 30m
- Merged PRs (30d)
- 2
Description
Currently `LoadCentreCollect` creates a `RotationScan` as part of validation. This leads to some oddities:
* We have to check that the rotation x/y/z isn't specified. Also means that x/y/z not being specified now sort of means two things, in the `LoadCentreCollect` case it means "fill in with things from zocalo", in the standalone rotation case it means "Take data at your current location".
* We have to check specified energy isn't different between grid and rotations
* It's not clear how specifying multiple rotations at the `LoadCentreCollect` interacts with zocalo providing multiple centres
* Following https://github.com/DiamondLightSource/mx-bluesky/issues/1038 we fill in a sample id in each sweep even though it will get overwritten
* It sort of implies that you can use the `multi_rotation_scan` to do a rotation whenever, in fact we should only use it after an XRC
A better solution would be to decouple these. `LoadCentreCollect` should take a more stripped down object that contains some of the parameters for `RotationScan` and then provide a method like `def create_rotation_parameters(zocalo_results) -> RotationScan:` that we can call once we have some XRC results.
## Acceptance Criteria
- The above refactor is discussed
- It is implemented if people think it's a good idea
- Behaviour is unchanged
Contributor guide
Assessment
This issue has not been assessed yet.