ENGIN-X: Collimators

[kjwoodsISIS]

As an ENGIN-X scientist, I want to control the motors that drive the collimators, so that I can put the collimators in the optimum position for my experiment.

Acceptance Criteria

1. I can view, in a GUI, the current (relative) x-position of each collimator - one North collimator; one South collimator.
2. I can change, in a GUI, the current (relative) x-position of each collimator.
3. I can use buttons on the GUI to jog the collimators backward & forward.
4. If either collimator encounters a limit switch motion of the collimator is halted and I am alerted to the situation.

Notes

1. There is a schematic showing the relation of the collimators to the beam. There is also a drawing of the collimators.
2. Sketch of suggested UI for the OPI.
3. The collimators on ENGIN-X are currently (as of 01-08-2017) manually controlled (by turning a knob). This makes adjusting the collimators very slow and laborious (the collimator has to be moved into position, the blockhouse evacuated, beam switched on, measurements made to see if collimator is in the right position, beam switched off, collimator adjusted, ..., rinse, repeat, ...). Motors will be fitted to the collimators to automate their adjustment.
4. For Cycle 2017/02, motors will be fitted to drive the collimators in the x-direction (i.e. parallel to the beam). Motors to drive the collimators in the y-direction (perpendicular to the beam will be fitted at a later date - a ticket will be created at the appropriate time).
5. The collimator motors are Galil controlled.
6. The collimator motors will be fitted with rotary encoders (so it will only be possible to determine relative position - a linear encoder would be required for absolute position). The scientists understand this point. They are happy to adjust the collimators to suit their experiment. In fact, the collimators are removed for some experiments and then re-attached for others, so they are never quite replaced in exactly the same position, making absolute positioning pointless. It is only the distance that a collimator is moved that is important.
7. The collimators will be fitted with limit switches, to prevent the collimators being driven too far.
8. The collimators will NOT be fitted with a homing switch (therefore, there is no definition of an absolute zero of position).

[kjwoodsISIS]

Additional information from Simon Cooper (Motion Control):

From: Cooper, Simon (STFC,RAL,ISIS) Sent: 02 August 2017 10:56 To: Woods, Kevin (Tessella,RAL,ISIS) Cc: Kelleher, Joe (STFC,RAL,ISIS); Kabra, Saurabh (STFC,RAL,ISIS) Subject: RE: ENGIN-X: Collimators

Hi Kevin, Collimators will be controlled using the existing rack as it currently has enough slots free for us. I will try and find out the switch spacing for you soon but Francesco who designed this part of the system is currently on A/L until next week.

[KathrynBaker]

Just to confirm, is this is the same galil rack as is used for the positioner system?

If it is, then we have a different conversation to have, as that is remaining under LabVIEW control, and so we will need to reconsider the steps and options for the setup.

[kjwoodsISIS]

Yes, it appears that there currently is only one Galil rack on ENGIN-X (this will change as ENGIN-X evolves). The problem that Kathryn alludes to is that having LabVIEW (controlling the positioner - see #2401) and EPICS (controlling the collimators) on a single Galil is not a good mix. A meeting is planned to review possible solutions.

[kjwoodsISIS]

As noted by @KathrynBaker and @GDH-ISIS, there is currently only one Galil rack on ENGIN-X. This rack is currently controlled by a LabVIEW driver (and needs to continue being controlled by a LabVIEW driver, for the time being - see #2401). It is not a good idea to have two separate drivers (LabVIEW & EPICS) controlling a single Galil. Following discussion, it was agreed that the first implementation of controls for the Collimators will use a LabVIEW VI and lvDCOM. This means that the Galil is still controlled exclusively by LabVIEW, but can communicate with IBEX and genie_python (via lvDCOM). In the future, when all 4 collimator axes are motorised, a new Galil rack will be required (the current rack does not have the capacity for to control two more motors). At that time, we can consider using a pure EPICS solution (because all 4 axes can be controlled via the new Galil rack). The implementation of a pure EPICS solution will be managed in a separate ticket.

[kjwoodsISIS]

Estimation of effort:

• create VI: 1 point
• create lvDCOM & OPI: 1 point.

[kjwoodsISIS]

From: Zuddas, Francesco (STFC,RAL,ISIS) Sent: 07 August 2017 10:22 To: Cooper, Simon (STFC,RAL,ISIS); Woods, Kevin (Tessella,RAL,ISIS) Cc: Kelleher, Joe (STFC,RAL,ISIS); Kabra, Saurabh (STFC,RAL,ISIS) Subject: RE: ENGIN-X: Collimators

Hello everyone, answering your questions:

-distance between the limit switches is not critical, as long as it allows for something like +/- 10mm travel. -a bracket will probably be needed in order to trigger the switches (see picture). Design is not critical, just let me know if the travel distance is ok to you and I’ll prepare the drawing. -I’d say that a minimum speed of 1mm/min and a maximum speed of 10mm/min is ok.

Thanks,

Francesco

From: Cooper, Simon (STFC,RAL,ISIS) Sent: 07 August 2017 09:26 To: Woods, Kevin (Tessella,RAL,ISIS) Cc: Kelleher, Joe (STFC,RAL,ISIS); Kabra, Saurabh (STFC,RAL,ISIS); Zuddas, Francesco (STFC,RAL,ISIS) Subject: RE: ENGIN-X: Collimators

Hi Kevin, Very good point on the EPICS control. I will make a note of that. Re. point 2, I unfortunately have no knowledge of the mechanical design of the system as I picked this project up half-way through. Possibly Francesco (cc’d) can help you out more however if he can’t I will try and work something out for you.

Best Regards Simon

From: Woods, Kevin (Tessella,RAL,ISIS) Sent: 04 August 2017 14:00 To: Cooper, Simon (STFC,RAL,ISIS) Cc: Kelleher, Joe (STFC,RAL,ISIS); Kabra, Saurabh (STFC,RAL,ISIS) Subject: RE: ENGIN-X: Collimators

Hi Simon,

A couple more points that came up within the Controls group as we discussed the collimators:

1. We understand that the Galil rack on ENGIN-X also controls the sample positioning
   stack. We currently use a LabVIEW driver to control the positioning stack. Ideally, we’d like to use an EPICS driver to control the collimators but, while they are connected to the same Galil rack as the positioning stack, we can’t (mixing LabVIEW drivers and EPICS drivers on the same device is not good practice). We can, of course, continue using the existing LabVIEW driver to control the collimators – and that is exactly what we will do. However, when it comes time to install the two additional motors (to drive the collimators in the y-direction), you will need an additional Galil rack. We strongly recommend moving all 4 motors to the new Galil rack, so that all the collimators motors can be controlled with an EPICS driver. Can you make a note of that for the future plans to install the additional motors.

2. In our meeting on Tuesday, Saurabh explained he’d like to have a script to perform continuous scans of the collimators. He suggested a motor speed of ~1mm/minute. I assume the motors are quite capable of that sort of speed. What range of speeds would you consider reasonable for moving the motors, so that we can use these as limits in the script (to make sure no-one tries to drive them too fast or unrealistically slowly)? Alternatively, we could just fix the scan speed at 1mm/minute.

Thanks,

Kevin

[davidkeymer]

(I believe) I've created a working VI (as yet untested) and have included all but one of the requested features. I've run out of time before going on leave to include the "nudge" function.

If someone would like to add the nudge function, then there is code in the "Table of Motors" VI in the "Jog Box" tab to work from. Otherwise, the users will just have to slightly alter the setpoints to nudge the collimators into position.

The VI I used as a basis for this one already had a "define arbitrary position" function so I've kept that rather than create a new "set to zero" function as requested. It should allow a bit more flexibility for the users, but could be included if required.

The front panel doesn't exactly replicate the suggestion above (it keeps to the same standard as other equivalent VIs), but the controls and indicators can be rearranged to suit at a late date if needed.

I've added the VI libraries to the following location in SourceSafe: \LabVIEW Modules\Drivers\Motion Control\ENGINX Collimators

[KathrynBaker]

I've added the rest of the buttons and functions which would allow lvDCOM functionality to be written - I have not put in the logic behind them. Those buttons are in source safe, and there is a copy of that version of the code in my scratch area on babylon5

[Tom-Willemsen]

lvDCOM is done and can be reviewed. I think @davidkeymer is just finishing off the labview but as far as I know the front panel won't be changing.

PRs:

• https://github.com/ISISComputingGroup/EPICS-ioc/pull/173
• https://github.com/ISISComputingGroup/EPICS-IOC_Test_Framework/pull/24
• https://github.com/ISISComputingGroup/ibex_gui/pull/548