Skip to content

Ticket8614 mercury ips magnet supply #84

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
+52 −2
Open

Ticket8614 mercury ips magnet supply #84

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b10bb10
Oxford-Instruments-IPS.md: Added state-machine diagram as Mermaid script
iangillingham-stfc Sep 9, 2025
1a8fbcb
Oxford-Instruments-Mercury-IPS.md: Added a new section concerning the…
iangillingham-stfc Sep 9, 2025
29caa99
Merge remote-tracking branch 'origin/master' into Ticket8614_mercury_…
iangillingham-stfc Sep 9, 2025
18e804a
Oxford-Instruments-Mercury-IPS.md: Spelling...
iangillingham-stfc Sep 9, 2025
e25b500
Oxford-Instruments-Mercury-IPS.md: Spelling take 2...
iangillingham-stfc Sep 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions doc/specific_iocs/cryogenics/Oxford-Instruments-IPS.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could: We may wish to put a "see-also" on this page, linking to the Mercury IPS page, if that's what cryogenics will mostly be using.

(Scientists will likely refer to either controller as an "ips" or just "the magnet", so trying to help future developers to realise that they need to disambiguate "IPS" versus "Mercury IPS").

Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,40 @@ The IOC implements the following state machine in SNL:
* Set the IPS activity to "Ramp to Zero" and wait for the supplied current to drop to zero
* At the end of this state, the magnet is set to "persistent" mode.

The SNL state machine is also described in the following diagram:
```{mermaid}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: How much does mermaid let us control the rendering? I think I've seen some options that might prevent it rendering loops like this?

image

---
title: IPS State Machine
---
stateDiagram-v2
direction TB
[*] --> initial
at_field: At Field<br>statemachine_pv=1
set_psu_to_match_magnet: Set PSU to match magnet<br>statemachine_pv=2
wait_for_voltage_to_stabilise: Wait for voltage to stabilise<br>statemachine_pv=3
ensure_switch_heater_warm: Ensure switch heater warm<br>statemachine_pv=4
set_psu_output: Set PSU output<br>statemachine_pv=5
switch_off_heater: Switch off heater<br>statemachine_pv=6
ramp_down_psu: Ramp down PSU<br>statemachine_pv=7
initial --> at_field: field_setpoint_alarm == 0
at_field --> set_psu_to_match_magnet: field_setpoint != field_setpoint_readback<br>&& field_setpoint_alarm == 0<br> && (heater == 0 || heater == 2)
at_field --> set_psu_output: field_setpoint != field_setpoint_readback<br>&& field_setpoint_alarm == 0<br>&& heater == 1
set_psu_to_match_magnet --> wait_for_voltage_to_stabilise: field_setpoint_readback == magnet_field<br>&& psu_field == magnet_field<br>"&& ((sweepmode == SWEEP_MODE)<br> || (sweepmode == SWEEP_MODE_ALT))<br>&& (sweep_active == 0)
set_psu_to_match_magnet --> set_psu_to_match_magnet: timeout 300s
wait_for_voltage_to_stabilise --> ensure_switch_heater_warm: supplyvoltage_stable == 1
wait_for_voltage_to_stabilise --> set_psu_to_match_magnet: field_setpoint_readback != field_setpoint_raw
wait_for_voltage_to_stabilise --> set_psu_to_match_magnet: timeout 300s
ensure_switch_heater_warm --> set_psu_output: activity == ACTIVITY_HOLD<br>&& heater == 1<br> && heater_ontime_ok == 1
ensure_switch_heater_warm --> ensure_switch_heater_warm: timeout heater_wait_time + 30.0s
set_psu_output --> switch_off_heater: field_setpoint_readback == field_setpoint<br>&& (field_setpoint == psu_field<br>&& persistent == 1<br>&& (sweep_active == 0)<br>
set_psu_output --> at_field: field_setpoint_readback == field_setpoint<br>&& field_setpoint == psu_field<br>&& persistent == 0<br>&& (sweep_active == 0)<br>
set_psu_output --> set_psu_output: timeout 300s
switch_off_heater --> ramp_down_psu: heater == 0 || heater == 2<br>
switch_off_heater --> switch_off_heater: timeout 30s
ramp_down_psu --> at_field: psu_field == 0<br>&& (sweep_active == 0) <br>
ramp_down_psu --> ramp_down_psu: timeout 300s
```

## IOC notes

- The IOC does not enter it's state machine until a setpoint is set.
Expand Down
20 changes: 18 additions & 2 deletions doc/specific_iocs/cryogenics/Oxford-Instruments-Mercury-IPS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,25 @@ The Oxford Instruments Mercury IPS is a superconducting magnet power supply. It

Note: although the Mercury IPS is the successor to the "old" IPS, cryogenics prefer to run the older IPS units as they are more reliable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should: With the newer firmwares that you've been testing with, I guess this is no longer true, as OI have done updates to make them more reliable?


## Hardware quirks
## Hardware quirks (Legacy mode)

The following faults can be seen when operating the magnet fully from the front panel, but it is likely that software will also run into the same conditions:
* The firmware will sometimes crash/freeze. To reset it, the whole power supply needs to be power-cycled. This is obviously undesirable for a magnet power supply, and cryogenics are chasing OI about this issue. It's not clear whether this issue is general to all Mercury IPS units or whether we have one faulty unit.
* The switch heater occasionally reports that it's ON when it's actually OFF
* The power supply reports a voltage of ~9000V which is incorrect (a sensible voltage for this power supply would be around ~8V while ramping)
* The power supply reports a voltage of ~9000V which is incorrect (a sensible voltage for this power supply would be around ~8V while ramping)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should: it would be worth mentioning the expected mapping of cards to identifiers somewhere in these docs, in case a new unit turns up that doesn't have that mapping set properly (i.e. the expected strings like DB5.P1 etc)

## SCPI Protocol

The IPS IOC now supports the SCPI protocol, which is more feature rich than Legacy mode.
Effort was made to ensure that the top level EPICS interface was was changed as little as possible.
It was particularly important that the SNL state-machine logic was not altered.
This all required some careful designing of the new interface to provide PV compatibility with the legacy mode.
Comment on lines +16 to +20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could: this paragraph reads more like a running commentary on the progress of a ticket, rather than documentation. Concretely I think the things that make it feel this way are:

  • Comparing "now" to "then" - I think these comparisons may be better framed as "using the SCPI command-set" and "using the legacy command-set"
  • Explaining why certain decisions were made (if only briefly).
  • Maybe active voice vs passive voice?

For an example take:

Effort was made to ensure that the top level EPICS interface was was changed as little as possible.
It was particularly important that the SNL state-machine logic was not altered.

or

SCPI mode keeps the same PV interface used by the older IPS units wherever possible, to minimise the changes required to instrument python scripts when swapping between old & new controllers. The SNL state machine logic is identical between SCPI & legacy mode, except for <explain how/where/why they differ>.

I feel the second would be clearer in this example

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should: It might be worth having a table of features showing exactly what is or isn't available in the two modes?

Legacy SCPI
Field readbacks Yes Yes
Ramp mode reporting (fast/slow) Yes No
Status reporting Basic Detailed
He Level reporting No Yes

I feel this would help future developers see at a glance what is expected to appear in either mode.

There is now significantly more diagnostic information available, along with support for daughter-boards, such as He and N level meters, pressure measurement, etc., all of which have necessitated additions to the user interface in the IBEX client.
The IOC can be configured to run with either legacy or SCPI protocols via a STREAMPROTOCOL macro ("SCPI" | "LEGACY"). The IOC publishes a new PV $(P)PROTOCOL, which reflects the configuration mode, allowing the user interface to hide or show attributes and controls relevant to SCPI or LEGACY modes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: (throughout) use code blocks to format commands/macros/etc a bit nicer?

Suggested change
As already mentioned, SCPI mode provides additional status reporting, much of which is based on the return string from the "READ:SYS:ALRM" command, which is poorly documented in the supplier's documentation. The status strings are assumed to all conform to the "Directory of Alarms" section (17.3) of the Operator's Manual (Issue 20, July 2018).
As already mentioned, SCPI mode provides additional status reporting, much of which is based on the return string from the `READ:SYS:ALRM` command, which is poorly documented in the supplier's documentation. The status strings are assumed to all conform to the "Directory of Alarms" section (17.3) of the Operator's Manual (Issue 20, July 2018).

As already mentioned, SCPI mode provides additional status reporting, much of which is based on the return string from the "READ:SYS:ALRM" command, which is poorly documented in the supplier's documentation. The status strings are assumed to all conform to the "Directory of Alarms" section (17.3) of the Operator's Manual (Issue 20, July 2018).
Whilst many of the system alarms that we could test, mostly conformed, some differences were noticed, along with additional, undocumented status, such as "Magnet Safety".
Comment on lines +24 to +25
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could: Do we have notes on which ones were tested or were different?

It has not been possible to test all alarm scenarios with the IPS unit and as such unable to fully ascertain that all the expected message strings are correct - they may need to be adjusted later on, if/when they arise.

The support module exports an aSub record subroutine to facilitate handling of the responses to READ:SYS:ALRM, which is not feasible with a StreamDevice protocol handler.

Loading