Mercury IPS magnet supply: using full capability to control

[GRyall]

Issue Description

As an instrument scientists and as a member of the sample environment group I would like to be able to use the full capabilities of the new Mercury IPS magnet supplies.

How & Where?

AJ/DB in the cryogenics team of the Sample environment group are the best contact. Came via regular interaction between CL & GR.

Additional Information

We already have a controller for an older generation. The newer models are capable of running in an emulator mode, which works with our old controller. (one is currently doing this). However all of the old ones are now being replaced and the emulator mode does not allow for the reading of cryogen levels, which is a requirement of cryo team. It is likely other of the new functionality may be useful, this should be discussed with the SE team. The logic used for the old controller should be sufficient for the new. Further detail should be sought from AJ.

Testing should be possible with the existing one, though it is not currently configured to read cryogen levels. OI will deliver four new ones in ~February at which point more comprehensive testing may be possible, as they won't all be used on magnets straight away.

Developer notes:

Associated PRs:

• IPS support module (EPICS-IPS: (Ticket8614 mercury ips magnet supply EPICS-IPS#9))
• IBEX GUI (ibex_gui: Ticket8614 mercury ips magnet supply ibex_gui#1809)
• IOC Test Framework - moved ips to support module (IocTestFramework: Ticket8614 mercury ips magnet supply EPICS-IOC_Test_Framework#661)
• Ibex Developer's Manual (ibex_developers_manual: Ticket8614 mercury ips magnet supply ibex_developers_manual#84)
• Release notes (IBEX: #8614 Added notes for Oxford Instruments - Mercury IPS controller #8831)
• IOC Ticket8614 mercury ips magnet supply EPICS-ioc#936

General design notes:

The original IOC tests were under the IOC test framework director:
C:\Instrument\Apps\EPICS\support\IocTestFramework\master\tests\ips.py
But have now been moved to the IPS support module, as is the now recommended practice.
(C:\Instrument\Apps\EPICS\support\IPS\master\system_tests)

Instead of just the single ips.py test file, which targeted just the legacy protocol, the tests have been split into:
ips.py (legacy IOC tests - functionally unchanged)
ips_scpi.py (SCPI protocol IOC tests)
ips_common.py (Tests common to both protocols)

The lewis emulator used to reside under: C:\Instrument\Apps\EPICS\support\DeviceEmulator\master\lewis_emulators\ips. This has been removed and relocated under the support module:
C:\Instrument\Apps\EPICS\support\IPS\master\system_tests\lewis_emulators\ips
So the original directory will need to be checked that it no longer contains the ips emulator.

IOC:

The original legacy IOC had just a single ips.db file.
The updated IOC has additional files which are structured to provide some decoupling of functionality and improve clarity. The scpi_system_alarms_discrete.db is generated using a template and substitutions file, as the pattern of all system alarm records is identical.

The original IOC used a single SNL state machine (cryomagnet.st). The state machine for the SCPI implementation, whilst similar, had sufficient differences that it was clearer to create a new SNL file (cryomagnet_SCPI.st) - mainly due to some EPICS records not being present in the new system.

The IOC start-up script, st.cmd, has been significantly re-worked. A new macro: "STREAMPROTOCOL" can be set to either "LEGACY" or "SCPI". There are conditional tests added liberally throughout the file to switch the appropriate configuration (loading database files and applying the appropriate macros).

The IOC build files have been modified to incorporate the new files for SCPI mode.

SUPPORT Module:

The IPS support module has been heavily modified, mainly under the system_tests directory, which was initially migrated from the old IocTestFramework tree.
The emulator StreamDevice interface needed to be split in two variants, one legacy and the other SCPI, whilst every effort was made to maintain 'device.py'. 'modes.py' and 'states.py' as the original files, but significantly augmented to support the additional features and attributes of the SCPI mode of operation.

GUI:

The user interface for the IPS is located at: C:\Instrument\Dev\ibex_gui\base\uk.ac.stfc.isis.ibex.opis\resources
The gui has been extensively augmented with information on temperatures, pressures, levels and detailed system status.

Testing:

IOC:

Go to the directory: C:\Instrument\Apps\EPICS\support\IPS\master\system_tests
There are two test scenarios: Legacy and SCPI
These are tested respectively by running:
1) run_tests.bat -t ips
2) run_tests.bat -t ips_scpi

GUI:

Clone a copy of the IBEX Client into: C:\Instrument\Dev\ibex_gui

FYI: The OPI file that has been modified is: C:\Instrument\Dev\ibex_gui\base\uk.ac.stfc.isis.ibex.opis\resources\ips.opi

Build and run the ibex client.
Edit the configuration to set the IPS IOC parameters to use STREAMPROTOL: SCPI

Run an IPS IOC either on an existing Mercury IPS or one in a lewis emulator.
Check that the GUI elements display the expected values.

Start the IPS IOC from the IBEX client.

Examine the IPS device screen and associated tabs.

With the emulator running, it should be possible to ramp up and down the virtual magnet in both persistent and non-persistent mode.

Acceptance Criteria

• New generation of Mercury IPS Magnet power supply can be controlled out of emulation mode
• cryogen levels can be read
• Has been tested against actual hardware

How to Review

• Checkout EPIC-IPS support module.
• Checkout EPICS-IOC
• Switch both the IOC and support module to branch: Ticket8614_mercury_IPS_magnet_supply
• Build the support module
• Build the IOC

IOC Framework tests:

• cd to C:\Instrument\Apps\EPICS\support\IPS\master\system_tests
• Run: make clean uninstall && make
• Run: run_tests.bat -t ips
• Run: run_tests.bat -t ips_scpi
• Both modes should pass without error.

GUI tests:

• Run a development version of the IBEX client (via Eclipse)
• With the IOC running in simulator mode (as above, but no tests)

...

_{To the reviewer: Make sure to update submodules!}

Planning

10/01/25 - 00:57:05
Should be within existing IOC, not new one

[GRyall]

Delivery of new hardware has been delayed (into April - so still required work!). Testing will need to be against one of the existing Mercury IPS systems taken out of its emulator mode. CL should be contacted to arrange access.

[iangillingham-stfc]

Alex Jones has looked at some of the differences between the SCPI and legacy command set and has summarised some useful information, as quoted below:

For the quench and overheat status, these (and many other issues) are dealt with by “Alarms” for the SCPI protocol. See the Magnet board section on p. 162 in Issue 20. These are read by “READ:DEV::PSU:STAT” in some undefined hex format for just the magnet-related alarms, and READ:SYS:ALRM for a list of everything.

Does the legacy command set allow checking for low helium level? I couldn’t immediately find any reference to this in the old manual. In any case, helium level would be read from the separate helium level meter card. The manual talks about an option for the threshold at which the low level alarm should set, but the alarm index doesn’t mention this alarm, so I’m not sure how this should operate. Getting helium level meter alarms is READ:DEV::LVL:STAT. This could alternatively be done by reading the threshold with READ:DEV::LVL:LOW and comparing it to the actual level.

As far as I can tell, there is no equivalent for the trip current and trip field, so I guess we’ll have to do without that.

Cheers,
Alex

[iangillingham-stfc]

Some further information re UID naming:
The UIDs can be either the nickname for the card (which we can set to anything we want, don’t know at this stage what OI will set them to) or related to the slot number and signal type.

From the spreadsheet, the positional UID for the magnet temperature sensor will be MB1.T1, the UID for the level meter will be DB1.L1 and the UID for the magnet supply will be GRPZ for all 4 of the systems.

The 10T system will have an additional temperature sensor DB8.T1 and a pressure sensor DB5.P1. There may be an additional ‘lambda’ UID associated with this too, I’m not sure how exactly this is implemented at the moment.

Cheers,
Alex