search

APS-4ID-POLAR / ipython-polar

4-ID-Polar ipython configuration for bluesky (and other)
1 stars 3 forks source link

Improve magnet staging #66

Closed gfabbris closed 3 years ago

gfabbris commented 3 years ago

Replace the while True: blocks in https://github.com/APS-4ID-POLAR/ipython-polar/blob/307bbcfcfb5004d6b3d4db7397d6db70973b4ab3/profile_bluesky/startup/instrument/plans/local_preprocessors.py#L10 with status objects.

gfabbris commented 3 years ago

Or we could turn some of the magnet components that have lengthy actions into PVPositioner, like the current, voltage, and the PS heater. Checking the magnet status could happen with a SubscriptionStatus.

gfabbris commented 3 years ago

Can I move the magnet staging to the mag6t.field.stage() .unstage()?

gfabbris commented 3 years ago

The use of .stage()/.unstage() is not the right way to go, from the ophyd.Device.stage() docstring: "This method should be as fast as is feasible as it does not return a status object."

But it is still desirable to replace the while statements in stage_ami_wrapper for status objects that the RunEngine can manage. It turns out, this seems to be complicated. Ideally we would have a Msg that waits for a condition to be True, but I didn't find it. The one that seems to be the closest is the wait_for, but I couldn't make it work, it gives out the error:

ValueError: The future belongs to a different loop than the one specified as the loop argument

I tried to get around this by creating a dummy Signal with a modified .trigger() that can be used with the trigger Msg (see 565c7c3). I have not tested this at the beamline (the whole thing can only be tested only in March, when the magnet is available). But I think it will work (probably with some tweaks), and it is better than the current solution. However, it is still a work around, it'd be nice to have a straightforward way to do this.