ENH: Positioners need a concept of limits about ophyd HOT 6 CLOSED

On Sat, Dec 6, 2014 at 6:56 PM, Stuart Wilkins [email protected]
wrote:

I suggest that all positioners have the concept of limit. This could be
the limits of a Motor Record or the DRVH/DRVL fields of an ao for example.
Then when setting the tradj. this should raise an exception that we can
catch in the scanning API. This stops starting a scan which will go outside
positioner limits.

Personally, i would prefer doing this in the positioner and throwing an
exception than checking in the scan. This way we can catch it on moves etc.
also.

Thoughts?

I had been holding out on polluting(?) Positioners with these types of
attributes (velocity being another), or rather making a very deliberate
effort to keep their interface as narrow as possible. The range of
permissible setpoints is something that applies equally well to Signals
(EpicsSignals) too, so perhaps it is time to revisit this.

EpicsSignals could check their setpoints via DRVH/L, EpicsMotors against
HLM/LLM, and Positioners could check on set_trajectory( ) for violations
against those limits.
Any of these could raise a ValueError("Out of permissible range"), or
similar, on violation...

I may have to cave on this one... :-)

from ophyd.

I had a feeling we'd get to this point. I agree, limits should be checked by the signals.

from ophyd.

Though this is basically fixed for moves, it doesn't work quite so well for trajectories.

Due the usage of iterables in set_trajectory, you can't check all the points of a trajectory prior to going through it. Scans that know the full trajectory ahead of time (certainly the vast majority) could perhaps call something like check_trajectory.

Something else to think about: assume you have a set of coordinated axes, whose limits depend on the current position of the other axes. In this case, something like a scan "simulation" mode that's run prior to the real scan, where all positioners know the simulated position of the others could be used.

from ophyd.

Hi Ken,

I was thinking about this, and I don't see a problem. I see it as the job of the scan to check limits before it starts if you can compute the path (because the scan is determining the path).

The scan class has a check_paths() which I had considered to do this, basically looping over all axes and checking the limits on all motors.

So I think this is your simulation mode. No?

What I like about this is that when we do HKL or pseudo motors we can check the actual paths and even forbidden combinations. Making the correct check_paths() is an exercise for the reader!

S

from ophyd.

Wrong account, oops. That works for me, in any case. Should we consider this closed, then?

from ophyd.

Let me test it today ok?

Best wishes,
Stuart

On Dec 10, 2014, at 06:54, K Lauer <[email protected]mailto:[email protected]> wrote:

Wrong account, oops. That works for me, in any case. Should we consider this closed, then?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-66441210.

from ophyd.