-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(#391) Create an ophyd-async ApertureScatterguard device #419
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #419 +/- ##
==========================================
- Coverage 93.28% 92.82% -0.46%
==========================================
Files 92 90 -2
Lines 3441 3332 -109
==========================================
- Hits 3210 3093 -117
- Misses 231 239 +8 ☔ View full report in Codecov by Sentry. |
0ebe4ae
to
b7dc905
Compare
…_desired_transmission Move transmission to the experiment param base class
7cbcadd
to
2de7fa1
Compare
|
||
|
||
class ExtendedEpicsMotor(EpicsMotor): | ||
motor_resolution: Component[EpicsSignalRO] = Component(EpicsSignalRO, ".MRES") | ||
max_velocity: Component[EpicsSignalRO] = Component(EpicsSignalRO, ".VMAX") | ||
|
||
|
||
class ExtendedMotor(Motor): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot that I had done some work to get these into ophy-async
ages ago. I've revived it at bluesky/ophyd-async#174. Let's not wait for that to be merged though, we can merge this in here and remove later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still trying to get this into ophyd-async
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there, just one more thing really - I put some comments in the code to explain. We should make sure that the set
method conforms to what bluesky expects by making the device Movable
and not only Readable
This change should be really small but please add one more test which checks that we can use the device in a plan in the RunEngine. If you write this test first it should fail because the RunEngine expects set()
to return a Status
of some kind
It will look something roughly like:
import bluesky.plan_stubs as bps
def test_ap_sg_in_runengine(aperture_in_medium_pos: ApertureScatterguard, RE: RunEngine):
test_position = ... # I'll leave this to you
RE(bps.abs_set(aperture_in_medium_pos, test_position, wait=True)
# assert that positions afterwards are equal to specified in the test position
@@ -1,7 +1,6 @@ | |||
import asyncio | |||
from collections import namedtuple | |||
from dataclasses import dataclass | |||
from typing import List, Optional | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you will want to from bluesky.protocols import Movable
@@ -85,7 +84,7 @@ class ApertureScatterguard(StandardReadable): | |||
def __init__(self, prefix: str = "", name: str = "") -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ApertureScatterguard
should inherit from both StandardReadable
but also Moveable
, which defines what the signature for set()
should look like
return reduce( | ||
operator.and_, [motor.set(pos) for motor, pos in zip(motors, positions)] | ||
async def _set_raw_unsafe(self, positions: ApertureFiveDimensionalLocation): | ||
"""Accept the risks and move in an unsafe way. Collisions possible.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love this docstring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
@dperl-dls thanks for all your help - hopefully we're on the home stretch! I've merged the main branch into this one now and your test works great :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! @DominicOram might want to take a quick look since I have had so much involvement in writing this, but as far as I can see this is good to merge. Let's squash the commits into one before merging it since there are a lot of WIPs and merges in there; you can do that directly from the github interface (I'll leave that for you to do so you get the well-deserved credit for it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, thank you @katesmith280! Couple of comments in code. More importantly (and annoyingly) this has broken Hyperion. You can test this if you run the tests on Hyperion main against this branch. I think most of the failures seem to be around the renaming of user_setpoint
/user_readback
in ophyd-async
. This should be fixed in bluesky/ophyd-async#174. Maybe we wait on this to be merged first :/
# extendedepicsmotor class has tolerance fields added | ||
# ophyd-async epics motor may need to do the same thing - epics motor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should: I think we now have these fields on the ophyd-async
equivalent, so this comment is redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment is now removed
|
||
|
||
class ExtendedEpicsMotor(EpicsMotor): | ||
motor_resolution: Component[EpicsSignalRO] = Component(EpicsSignalRO, ".MRES") | ||
max_velocity: Component[EpicsSignalRO] = Component(EpicsSignalRO, ".VMAX") | ||
|
||
|
||
class ExtendedMotor(Motor): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still trying to get this into ophyd-async
return reduce( | ||
operator.and_, [motor.set(pos) for motor, pos in zip(motors, positions)] | ||
async def _set_raw_unsafe(self, positions: ApertureFiveDimensionalLocation): | ||
"""Accept the risks and move in an unsafe way. Collisions possible.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
Thanks for the review @DominicOram! I agree waiting so it doesn't break Hyperion is a good idea :-) |
Ok, new motor is merged into |
@DominicOram tested now against hyperion and it passes - hooray! Should be good to merge if you think it's all good :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I got the wrong idea about what happened here. We don't need the ExtendedMotor
at all anymore thanks to the recent change to the ophyd-async motor, they can all just be replaced with Motor
, and the motor_resolution
is now called deadband
@dperl-dls good catch - my bad! The ExtendedMotor is now removed and replaced with Motor, motor_readback is now also set to deadband, tests updated and have been run against dodal and hyperion repos - all tests for aperture scatterguard pass :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this has taken so long, thanks for all your hard work on this @katesmith280 !
Fixes #391
Instructions to reviewer on how to test:
Checks for reviewer