LET: Heliox (3He sorption fridge): part 1 (basic IOC)

[Kevin-Woods-Tessella]

As a LET scientist, I want to use a Heliox 3He sorption Fridge on LET, so that I can perform cryogenics experiments.

Acceptance Criteria

1. I can control the temperature of the Heliox 3He sorption Fridge via IBEX.
2. IBEX provides similar levels of control to the existing SECI VI.

Notes

1. For details see the LET Wiki page.
2. Note (09-11-2018): at the time of writing, LET's Heliox 3He sorption fridge is currently broken and is being repaired at Oxford Instruments. There is no ETA on when it will be fixed. There are, at present, no experiments scheduled to use the Heliox 3He sorption fridge. This ticket will need to be activated when the Heliox is repaired.

[Tom-Willemsen]

This equipment turned up on LET today, as the repairs mentioned above are now complete.

Because we do not yet have support in IBEX for this and it looked too complex to do safely via SDTEST, I set them up with the VI and explained they wouldn't be able to script it/put blocks on it. The scientist (Duc) was happy enough with this solution.

As far as Duc knows, there are no further experiments with the Heliox this cycle, but there will be in the September cycle.

Labview driver I used: LabVIEW Modules\Drivers\Oxford Instruments\MERCURY\Mercury - Heliox.llb

[Tom-Willemsen]

+1 also required on MAPS

[Tom-Willemsen]

I think it would be useful for a labview developer to take a quick look over the existing vi before we assign story points to this.

In particular, it would be useful to know whether the existing vi contains significant cryogenic control logic (c.f. cryomagnets), or whether it sends a setpoint and lets the controller deal with it (c.f. triton fridges).

[Tom-Willemsen]

@davidkeymer and I have had a look through the VI.

• There is some cryogenic control logic relating to "regeneration".
  • This is implemented by ANDing a number of conditions based on the state of the device, including some delays etc
  • I think this should be possible in SNL (or even DB records, but I think SNL may be easier)
  • None of the conditions seem overly complex, but there are ~15 of them to code.
  • The VI looks to achieve a "regeneration" by resending a temperature setpoint. There is commented-out logic to do something more complicated (turning heaters on/off) - we suspect that this may have been needed for an earlier version of the heliox firmware (?) but is no longer needed.
• The rest of the VI amounts to reading ~30 parameters from a device and setting ~10.
• The command syntax is SCPI which would not cause any problem for streamdevice. The transport layer is RS232 (or GPIB or ethernet).

This ticket could be done using a couple of different approaches:

• Full EPICS ioc. In this case, I think it may be best to split this ticket into 2 different tickets to keep them manageable:
  • Basic IOC/emulator/tests implementing all commands but ignoring regeneration logic
  • Regeneration logic
• LvDCOM
  • We are likely to spend more time in the long term supporting this approach - the mercury vis are confusing to configure and are likely to generate support calls. E.g. https://github.com/ISISComputingGroup/IBEX/issues/4502

[Tom-Willemsen]

I have split this ticket into 2 parts: this ticket (3 points) and https://github.com/ISISComputingGroup/IBEX/issues/4549 (2 points)

This ticket is now to implement the full IOC (+emulator/tests/opi), but not any of the logic relating to helium regeneration.

[Tom-Willemsen]

To review:

• https://github.com/ISISComputingGroup/EPICS-DeviceEmulator/pull/40
• https://github.com/ISISComputingGroup/EPICS-heliox/pull/1
• https://github.com/ISISComputingGroup/ibex_gui/pull/924
• https://github.com/ISISComputingGroup/EPICS/pull/178
• https://github.com/ISISComputingGroup/EPICS-ioc/pull/399
• https://github.com/ISISComputingGroup/EPICS-IOC_Test_Framework/pull/203
• https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Mercury-Heliox
• https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Cryogenics

Questions I still need to ask cryogenics (I am meeting with Chris L on Friday to discuss these points):

• Temperature stability only exists for the He3Sorb and He4Pot channels, not the HeHigh or HeLow channels. Why is this?
• Heater auto/manual readback exists on all channels except He4 Pot. Why is this? Percentage heat is available on all channels so I don’t think this is to do with a heater not being present.
• What is the mapping between the top-level HelioxX device and the 4 diagnostic channels which are present? Is this like the tritons where the HelioxX channel is a hardware alias of one of the other channels, or is something else going on?
• We need to test the IOC with a real device. In particular it would be useful to know if we can use the "short" protocol or whether we have to use the protocol which asks for everything each time.
• Go over regeneration logic conditions and check these are sensible (this comes under https://github.com/ISISComputingGroup/IBEX/issues/4549 )

[aaron-long]

Additional question:

• What are the expected set point limits so we can apply DVRH/DRVL constraints.

[Tom-Willemsen]

Answers to questions above (from meeting with Chris L, with some input from Oleg K and Paul F):

• The main heliox temperature is a hardware alias of either HeHigh or HeLow depending which temperature the heliox is at (they have different sensors which are appropriate for different temperature ranges). Therefore, the stability of HeHigh or HeLow is not interesting - only the stability of the main HelioxX temperature channel is interesting.
• The He4 Pot is a weird channel, the way the device is manufactured expects one single mercury to control both the cryostat and the sorb, but cryogenics run them as completely separate systems. There is no valid He4Pot temperature to read from the heliox itself - it will report one temperature forever. Consider removing this from the interface.
• See above - HelioxX is an alias of either HeHigh or HeLow depending on temperature
• The short (preffered) protocol appears to work (tested against a real device via hterm).
• The regeneration logic conditions are sensible, but cryogenics think that most scientists probably regenerate manually as there are trust issues with the current set of conditions. They share concerns about regenerations happening at potentially bad times and ruining data.
  • Talk to scientists that use the Mercury Heliox systems, figure out if auto-regeneration is being used
  • We probably need good user-facing explanations (on the opi?) about what will happen in manual regeneration mode (gradual loss of cooling power over the course of ~12 hours until manually regenerated) and what will happen in automatic regeneration mode (temperature control will be lost while a regeneration is in progress, sample will be warmed up and cooled back down again).
  • Cryogenics share my concern about setpoints being overwritten to zero when an automatic regeneration is triggered. This would potentially ruin experimental data if true. Need to be very careful about this. Cryogenics have offered to keep the heliox on HiFi cold for me next week so that I can test against it.

Further observations:

• The muon heliox and the LET heliox have different channel names, so these should be passed through as macros.