-
Notifications
You must be signed in to change notification settings - Fork 320
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
driver / add block_during_ramp parameter to AMI430_3D #1228
driver / add block_during_ramp parameter to AMI430_3D #1228
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1228 +/- ##
=========================================
+ Coverage 80.48% 80.5% +0.02%
=========================================
Files 49 49
Lines 6804 6807 +3
=========================================
+ Hits 5476 5480 +4
+ Misses 1328 1327 -1 |
@emartinez wrote:
Not True! This assumes that the safe region is convex. We know that this is not always the case. |
@sohailc how was it again..? The sequential ramping keeps you safe only if the safe region is star-shaped around the origin, right? This is more general than convex, but can also in principle be false. But then I guess all bets are off. [EDIT: no, wait, star-shaped is too weak... is it convex also for sequential ramping?] In any case, before we merge, let me extend the tests to cover this new parameter. |
@sohailc wrote:
All the BlueFors AMI magnet specifications in Copenhagen state:
I.e. the safe region is a right rectangular prism, which is convex. We know from the magnet acceptance test that the corners of this prism have been explored and are safe. If this is not always the case, then I would suggest to subclass the driver so that users of less exotic magnets (at least 5 fridges here) can benefit from reasonable safety assumptions. |
@sohailc @emartinez I guess what I am trying to ask is: are there realistic use cases where a linear ramp is not safe but a first-down-then-up approach is? I can think of a few examples, but they are quite contrived. Unless the first-down-then-up actually goes all the way to the origin and then out to the target field value, I guess there generally isn't. |
Merge: b68979e b27f36c Author: William H.P. Nielsen <[email protected]> Merge pull request #1228 from emartinez/driver/AMI340_non_blocking
@WilliamHPNielsen
The AMI430_3D magnet does not currently support non-blocking field ramps. A linear field ramp between two safe points is always safe if the ramp rates are safe, so this should be possible.
The new block_during_ramp parameter (default True), if set to False, will call the set_field methods of the children with the argument block=False, so that they get ramped in a non-blocking way.