SANS2D: Minimum Baffle/Detector Intervals

[kjwoodsISIS]

As a SANS2D scientist, I want IBEX to respect the minimum permissable distances (intervals) between the detectors and baffles, so that the detectors and baffles do not collide.

Acceptance Criteria

1. Front Detector-Front Baffle Interval: minimum is 1050 mm.
2. Front Baffle-Rear Baffle Interval: minimum is 210 mm.
3. Rear Baffle-Rear Detector Interval: minimum is 350 mm.
4. The IBEX GUI should warn me if I set detector/baffle to positions which violate these limits.
   • the intervals should be calculated from the detector & baffle positions
5. I can use the IBEX GUI to set the detector & baffles positions in any order.
   • Note: in SECI the detector & baffles positions have to be entered in a specific order (which confuses users).
6. The interval limits should be configurable, but this is not an action often required. i.e. having a PV that we can put a new value into, which is autosaved is probably a good solution
7. There should be 6 rules which stop a detector moving if:
   • interval between the object and the next object is less than the minimum
   • AND the direction of travel will make the interval smaller (i.e. we allow movement from a distance which is too small to one which is too large) An important test is put 3 objects closer than the minimum distance I should only be able to move the end ones away from the others. I should not be able to move the middle one.
   • rules are stop 1 if 1<->2 is too small, stop 2 if 1<->2 is too small, stop 2 if 2<->3 is too small, stop 3 if <2-3> is too small etc.
   • See notes below for a suggested algorithm.
8. Using manager mode I can turn off the automatic stopping in case I get into a position that I can't get out of for some reason.
9. CAM should not be used but there is documentation of why it couldn't be used.

Notes

1. For the avoidance of doubt, this ticket is all about preventing clashes between baffles and detector trolleys.
   • the solution described above has been used on SECI for some time and works well, we should reproduce it in IBEX, because it is proven and the scientists are familiar with it.
   • yes, we do have the CAM system, but the solution described above is simpler; a solution based on the CAM system can be considered at a later date.
2. This ticket is a sub-ticket of SANS2D: Control of Vacuum Tank (EPIC) #4576.
3. The distances defined above have been measured on SANS2D. It has been confirmed that they prevent collisions.
   • While it will be useful to define the minimum distances as configurable items, the expectation is that they will not change frequently.
4. Scientists prefer to enter all the detector/baffle positions, check that the intervals are valid (i.e. do not violate the minimum values) and only then press the "Move All" button (see SANS2D: Vacuum Tank OPI #4577).
5. Check the paragraph describing the Clash Prevention in the Beam_line_descriptors document.
   • Note: take special note of the comments about speed, acceleration, deceleration & homing of the detector & baffle trolleys.
6. Here is a suggested algorithm for managing the movement of the baffles & detectors.

[DominicOram]

Given that we decided Move All was not a requirement (#5499) this ticket will need some more thought about how we complete it. Specifically we need to think about the cases where one item is in motion and I try to move another. It may be that the simplest solution for this is still do the Move All functionality. In that case though we will still have to be careful to make sure that the speeds of the items are similar enough that one will not catch up to another and collide.

[DominicOram]

As @Kevin-Woods-Tessella wrote on #5499 the solution may change to be:

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.

This is pretty much exactly how the CAM works so it may be that if we implement this solution we should do it using the CAM.

[kjwoodsISIS]

I would prefer that we implement the simple solution described above (at least initially). IIRC, when we used the CAM system on ZOOM, it took a lot of adjustment to get it right. I don't want to lose time adjusting the CAM system on SANS2D when a simple solution is available.

[kjwoodsISIS]

@JamesKingWork - can you please check the speeds at which the detectors & baffles move and let us know the result. Thanks.

[DominicOram]

I would prefer that we implement the simple solution described above

Which solution are you referring to? The solution in the original ticket requires Move All. The solution that you proposed on #5499 is reproducing the functionality of the CAM.

[JamesKingWork]

According to SECI the speed for both detectors in the Z-axis is 4096 and the acceleration/deceleration are 2048 with a motor resolution of 125 steps per unit and an encoder resolution of 62.5 steps per unit. Both baffle's z axes have a speed of 14305 and an acceleration/deceleration of 5120 with a motor resolution of 436.539 steps per unit and and an encoder resolution of 151.576 steps per unit.

[KathrynBaker]

For reference, speed, acceleration, and deceleration in SECI are not in any form of unit for the Galil, as the Galil itself doesn't consider them as a unit as such. There is maths undertaken on conversion to go from what is used in SECI to the unit/sec, or unit/sec-squared of the motor record. So to make sense of those numbers we need the resolution as well as the numbers in those fields.

[kjwoodsISIS]

We can go a long way on this ticket without implementing Move All. If I set one of the detectors or baffles moving, the intervals will update. If the requested setpoint will produce an invalid interval, then we can display a red box around the interval field. Similarly, if I start one baffle/detector moving and then start another, the interval fields will again update.
Admittedly, this is not the same as having everything remaining stationary until the Move All button is pressed, but does provide clear feedback that the requested interval is invalid.
Once we have a basic mechanism in place to warn users of invalid intervals, we can go back at a later date to implement more desirable solutions (like Move All).

[KathrynBaker]

That update based on interval is what the CAM does, or at least it's what I thought it does, and seems to be what @DominicOram thinks it does too. At the moment I think that simple solution described is all that the CAM does at the moment.