SANS2D (and others): Delayed move

[DominicOram]

As a scientist on SANS2D I would like to be able to set the positions of my waveguides without them moving and then press a Move All button to move them all together. I would also like to do this delayed move with an individual axis. Other instruments have also requested this feature, notably ZOOM. This feature already exists in the reflectometry server but is baked into it and hard to reuse. Therefore the generic case is:

Acceptance Criteria

• I can set an axis up so that when I enter a position it does not move until I press a move button
• I can assign an axis to a group of axes that will all move when a move all button is pressed

Notes:

• This could be done by making use of the SPMG field on the motor record (https://epics.anl.gov/bcda/synApps/motor/motorRecord.html#Fields_command)
• The way the reflectometry server does this is to have a sp_no_action pv from which the set point is copied on action. This would be another way to achieve this.
• Stick to the standard pattern for naming see point 6 of https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/ISIS-PV-Guide

[John-Holt-Tessella]

Is there a reason why they want to do this? Can we persuade then just to move when they set the values. It doesn't feel like it should matter if they move everything now or in 5 minutes unless there are clash conditions or very careful allignment.

[KathrynBaker]

Clash issues certainly, and some alignment ones as well. It gets frustrating if you bump baffles in vacuum tanks into each other...

[DominicOram]

I think we've pushed back on this request numerous times and it continues to be requested, whilst it might be fiddly I see no reason for it to be impossible.

[kjwoodsISIS]

As @DominicOram says, the SANS scientists keep asking for this. I have told them that it is possible to do as they ask, but that it will be a fiddly, time-consuming task and, therefore, it is not a priority. Migrating instruments comes before a delayed move command.

As I understand it, the primary reason for needing a delayed move in SANS experiments is to avoid clashes, especially the moveable detectors & baffles in the vacuum tank. The scientists want to be able to define a new setpoint and then see (or be warned) if it will cause a clash. If it the new setpoint will cause a clash, they can change it before pressing Move.

To mitigate the risk of clashes in the Vacuum Tank (without implementing a delayed Move command), I have specified that the new OPI displays and continuously updates the distance between the detectors and baffles (see #4580). The Instrument Scientist has provided me with the minimum allowable distances between the various detectors & baffles - the system should stop if any of the distances reaches the minimum value. The system can also warn the user if the detectors/baffles are getting too close. In case you are wondering, the minimum distances do allow for the distance required to decelerate and come to a stop. The distances are specified in #4587.

[DominicOram]

Thanks @Kevin-Woods-Tessella, does that mean that the Move All functionality specified in #4577 and #4575 are not required for the migration of SANS2D?

[kjwoodsISIS]

I first wrote the requirements in #4577 and #4575 almost a year ago. Since then, I have been told that it is a difficult thing to do (information which I have passed on to the scientists). I do not want to hold up migrations while we wait for delayed Move functionality to be implemented.
I fully understand the desirability of delayed Move (from the scientists point-of-view), but I don't believe it is an essential pre-requisite for migration. Furthermore, much of the functionality of the SANS2D control panels can be tested without a delayed Move feature, so why delay that testing? Let's get the basic implementation working and tested; the delayed Move feature can be introduced at a later date.

[DominicOram]

Ok, I'll update the tickets

[FreddieAkeroyd]

The galil IOC supports "deferred moves" if that is of any use

[John-Holt-Tessella]

The reason it is hard to use the deferred moves in the galil is if the user wants an immediate scripting interface as well without have to run a command to confirm the move. So they can do:

g.cset("guide1", "Top")
g.cset("guide2", "Mid")

Otherwise you need a move block (which is ok) and do

g.cset("guide1", "Top")
g.cset("guide2", "Mid")
g.cset("Confirm move", "Go")

We should pick which one