DiamondLightSource / DiamondLightSource/mx-bluesky
Support for setting stub offsets
- Dominant language
- Python
- Stars
- 4
- Forks
- 5
- Avg merge
- 1d 30m
- Merged PRs (30d)
- 2
Description
The addition of multipin to the experiment plans will result in changes to stub offset handling. Namely
* Centring will now be performed by the top-level plans calling a new `change_aperture_then_centre` subplan, not as part of the flyscan plan
The existing code for setting stub offsets is effectively unused as `ThreeDGridScan` contains the `set_stub_offsets` parameter but this is not inherited by top-level params and is only constructed after grid detection (although I don't think this is currently set in any case).
In order to effectively use stub offsets as part of multipin we will need to be able to restore the stub offsets after applying them at each rotation, in order to move to the next centre without loss of precision.
See following discussion:
> Robert Tuck
Question about stub-offsets:
Currently when we do centring, we reset stub offsets to the found centre before doing the rotation. If I understand correctly this resets the coordinate system of the motors so that the origin is at the current motor position.
In the case of multipin, presumably we need to do this prior to starting rotation(s) at each centre.
This gives the option of a) computing for the next centre the motor position relative to the current offset and moving to that. However will this introduce significant cumulative error from reading + applying motor positions?
b) restoring the stub offsets back to their previous values and then we don't have to compute relative positions. But I don't see any way to do that with the current smargon stub offset device in dodal?
> Dominic Oram
1 hour ago
Stub offsets are currently basically unused in Hyperion and GDA on i03. In theory applying them will shift the center of rotation to the current beam position. This isn't needed for omega rotations because the center of rotation is always along the current x axis but we do need it for chi rotations. However, in practice the accuracy of the smargon on i03 has never been good enough, even with stub offsets, to correctly do a chi rotation around the beam centre so we always end up just re-centring after the chi change. This is annoying because i04 believe their smargon can do this. We also found that applying stub offsets were causing issues on i03 with confusion over the co-ordinate system changing on the smargon between GDA and hyperion and it not being expected hence switching them off for now.
[9:53](https://diamondlightsource.slack.com/archives/GJPB00679/p1728032007932409?thread_ts=1728031099.989009&cid=GJPB00679)
All this to say we will never need to apply stub offsets for a multipin and in the short/medium term we're not applying stub offsets for other pins either. So the answer for the time being is do nothing with stub offsets and write up a new issue
Contributor guide
Assessment
This issue has not been assessed yet.