VESUVIO: forward left foil & HRPD low temperature sample changer - make homing routine hardier

[FreddieAkeroyd]

After an IBEX restart one of the Vesuvio forward foils failed to work.

From the scientist:

The issue seems to be resolved right now. It required me coming to the lab, power-cycling the Mclennan crate, manually setting the U and L limits on the Mclennan panel, and finally setting the hi and lo limits as well as testing the homing of the forward left and right foils in IBEX. On the whole, my impression is that, for some reason, contrary to the forward right foil, the forward left foil is misbehaving after an IBEX restart or at the beginning of almost each cycle. It took us nearly 3 hours tonight to see what was happening, then I came at ca 10 am and it took me another hour or so to get to the stage at which I could resume running. Taken together, VESUVIO has just lost ca 12 hours worth of beamtime due to these issues.

Acceptance Criteria:

• Axis homes reliably & correctly in IBEX
• There is a system test for this
• Special homing sequence is remove from the wiki
  • https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Vesuvio-homing-sequence
  • link in https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/McLennan-motors
  • https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/HRPD-homing-sequence
• Instrument scientists told

[FreddieAkeroyd]

The homing routine seems to stop early, need to investigate out of cycle. Notes on SNL:

• It should check whether LLS or HLS is set to know it has reached the limit
• The logic sets in order val, dval, offset; it doesn't explicitly choose "frozen" or "variable" mode, check if this can cause any issues

[FreddieAkeroyd]

See #5747

[John-Holt-Tessella]

+1 HRPD

Just transferred the sample changer from MARI to HRPD and I could not home the axis in mode 3. I could also not jog the axis. The problem feels the same in that the jog last for a small amount of time and then it stops without hitting a limit switch.

This may be more amenable to testing than the foil since you can see the sample changer without looking down a hole.

We should also ask MARI if it homes on their setup looks like they have it set to reverse home and set as 0 not constant velocity jog and zero

[DominicOram]

Currently have a hotfix for this on LET, who were using the low temperature sample changer. The issue was as above that a jog was stopping prematurely. Rather than fix the jog I added a new homing routine that retried the jog if it didn't get to the limit, see https://github.com/ISISComputingGroup/EPICS-motor/tree/Ticket5739_mclennan_reverse_homing_routine.

This ticket is now to add this into the pre-existing homing routines (on the hotfix I made it a new homing routine as I was wary of accidentally affecting other components) for both forward and backward home. We should then make a system test for the behaviour.

[DominicOram]

Repointing as I have done some of the work as the above hotfix.

[DominicOram]

In trying to test this I wrote an emulator, which also has the issue. I believe the underlying issue is actually caused by the work done in #2202. This causes the record to process every 10 seconds and when the record processes it stops jogging. This is expected behaviour of the motor record and can be seen in other drivers such as the galil. I believe the correct fix is to modify the underlying mclennan code to do the polling properly, rather than processing the record.

I'm now unsure as to whether I should carry on implementing this fix or move on to the proper fix.

[DominicOram]

If happy with the code I'll:

• Fix the docs
• Tell the scientists
• Remove the soon to be non-existent homing setting on LET