You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Oxford Instruments Mercury IPS is a superconducting magnet power supply. It is the successor to the [IPS](Oxford-Instruments-IPS). Much of the information on the IPS wiki page also applies to the Mercury IPS.
3
+
The Oxford Instruments Mercury IPS is a superconducting magnet power supply. It is the successor to
4
+
the [IPS](Oxford-Instruments-IPS). Much of the information on the IPS wiki page also applies to the Mercury IPS.
4
5
5
-
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.
6
6
7
7
## Hardware quirks (Legacy mode)
8
8
9
-
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:
9
+
The following faults can be seen when operating the magnet fully from the front panel, but it is
10
+
likely that software will also run into the same conditions:
10
11
* 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.
11
12
* The switch heater occasionally reports that it's ON when it's actually OFF
12
13
* The power supply reports a voltage of ~9000V which is incorrect (a sensible voltage for this power supply would be around ~8V while ramping)
13
14
14
15
## SCPI Protocol
15
16
16
17
The IPS IOC now supports the SCPI protocol, which is more feature rich than Legacy mode.
17
-
Effort was made to ensure that the top level EPICS interface was was changed as little as possible.
18
-
It was particularly important that the SNL state-machine logic was not altered.
19
-
This all required some careful designing of the new interface to provide PV compatibility with the legacy mode.
20
-
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.
21
-
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.
22
18
23
-
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).
24
-
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".
25
-
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.
19
+
SCPI mode keeps the same PV interface used by the older IPS units wherever possible, to minimise the
20
+
changes required to instrument python scripts when swapping between old & new controllers.
21
+
The SNL state machine logic is identical between SCPI & legacy mode.
26
22
27
-
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.
23
+
As already mentioned, SCPI mode provides additional status reporting, much of which is based on the
24
+
return string from the `READ:SYS:ALRM` command, which is poorly documented in the supplier's
25
+
documentation. The status strings are assumed to all conform to the "Directory of Alarms" section
26
+
(17.3) of the Operator's Manual (Issue 20, July 2018).
27
+
Whilst many of the system alarms that we could test, mostly conformed, some differences were
28
+
noticed, along with additional, undocumented status, such as "Magnet Safety".
29
+
It has not been possible to test all alarm scenarios with the IPS unit and as such unable to fully
30
+
ascertain that all the expected message strings are correct - they may need to be adjusted later on,
31
+
if/when they arise.
32
+
33
+
The support module exports an aSub record subroutine to facilitate handling of the responses to
34
+
`READ:SYS:ALRM`, which is not feasible with a StreamDevice protocol handler.
28
35
29
36
### CONTROL and CONTROL:SP
30
37
These records have been removed from the SCPI variant database
@@ -34,30 +41,35 @@ the IPS via the front panel.
34
41
35
42
### SYSTEM:HWFAULT status is derived from the status bits via a calc record.
36
43
This collates the various possible hardware faults into a single record,
37
-
which in the legacy protocol is a single value (Xm bit 4).
44
+
which in the legacy protocol is a single value (`Xm` bit 4).
38
45
39
46
### SWEEPMODE:PARAMS and SWEEPMODE:SWEEP
40
47
These records have been removed as they are meaningless and underivable in SCPI protocol.
41
48
42
49
### _SWEEPMODE:SWEEP
43
-
In the legacy version, this used to be the readback from n of Mmn part of Examine command return.
44
-
0 output constant, 1, 2, 3 output changing
45
-
The SCPI protocol doesn't directly offer this, so it has to be derived via the ACTIVITY record (DEV:GRPZ:PSU:ACTN)
46
-
Direction from Alex Jones: "A response of HOLD or CLMP would be equivalent to n=0 in the response of the X command
47
-
in the old protocol. Responses of RTOS or RTOZ would be equivalent to n=1.
48
-
There is no equivalent for the m=0,1 fast/slow ramps, but we do not use this feature anyway."
50
+
In the legacy version, this used to be the readback from `n` of `Mmn` part of Examine command
51
+
return.
52
+
- 0 output constant
53
+
- 1, 2, 3 output changing
54
+
55
+
The SCPI protocol doesn't directly offer this, so it has to be derived via the `ACTIVITY` record
56
+
(`DEV:GRPZ:PSU:ACTN`)\
57
+
Direction from Alex Jones: "A response of `HOLD` or `CLMP` would be equivalent to `n=0` in the
58
+
response of the `X` command in the old protocol. Responses of `RTOS` or `RTOZ` would be equivalent to
59
+
`n=1`.
60
+
There is no equivalent for the `m=0,1` fast/slow ramps, but we do not use this feature anyway."
49
61
50
62
### System Alarms
51
-
System alarms are derived by interrogating the IPS with the "READ:SYS:ALRM?" SCPI command.
63
+
System alarms are derived by interrogating the IPS with the `READ:SYS:ALRM?` SCPI command.
52
64
This returns a comma-separated string of active alarms, or an empty string if no alarms are present.
53
65
The string is parsed by an aSub record, which sets the relevant bits in a binary register.
54
66
The bits are mapped to individual status records, which are then used to set the relevant alarms.
55
67
The precise protocol was determined empirically by sending the command and observing the response
56
68
directly from the instrument.
57
69
Discrete records are generated for each board type and each alarm by the
58
-
scpi_system_alarms_discrete.template and substitutions files.
70
+
`scpi_system_alarms_discrete.template` and substitutions files.
59
71
60
-
The base response is: READ:SYS:ALRM: which may (or may not) be followed by a board identifier,
72
+
The base response is: `READ:SYS:ALRM:` which may (or may not) be followed by a board identifier,
61
73
a tab character (9) an alarm string and a semicolon.
62
74
63
75
In ABNF:<br />
@@ -81,51 +93,69 @@ The board identifiers are provided as macros:
81
93
| BOARDID_LEVEL | DB1.L1 |
82
94
83
95
## Development Notes:
84
-
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:
85
-
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.
86
-
87
-
Some further information re UID naming:
88
-
The UIDs can be either the nickname for the card (which we can set to anything we want) or related to the slot number and signal type.
89
-
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.
90
-
The 10T system will have an additional temperature sensor DB8.T1 and a pressure sensor DB5.P1.
96
+
Alex Jones has looked at some of the differences between the SCPI and legacy command set and has
97
+
summarised some useful information, as quoted below:
98
+
For the quench and overheat status, these (and many other issues) are dealt with by “Alarms” for
99
+
the SCPI protocol. See the Magnet board section on p. 162 in Issue 20. These are read by
100
+
`READ:DEV::PSU:STAT` in some undefined hex format for just the magnet-related alarms, and
101
+
`READ:SYS:ALRM` for a list of everything.
102
+
103
+
### Some further information re UID naming:
104
+
The UIDs can be either the nickname for the card (which we can set to anything we want) or related
105
+
to the slot number and signal type. From the spreadsheet, the positional UID for the magnet
106
+
temperature sensor will be `MB1.T1`, the UID for the level meter will be `DB1.L1` and the UID for
107
+
the magnet supply will be `GRPZ` for all 4 of the systems.
108
+
The 10T system will have an additional temperature sensor `DB8.T1` and a pressure sensor `DB5.P1`.
91
109
92
110
It appears that:
93
-
devices connected to the motherboard are prefixed: MB1\
94
-
devices connected to a daughterboard are prefixed: DB<slot #>
111
+
devices connected to the motherboard are prefixed: `MB1`\
112
+
devices connected to a daughter-board are prefixed: `DB<slot #>`
95
113
96
114
97
-
Conversation between Chris Lawson and Robert Grzyb at Oxford Instruments (18 Feb 2025)
115
+
Conversation between Chris Lawson and Oxford Instruments (18 Feb 2025)
98
116
SCPI Equivalents:
99
-
Yes we are looking for the equivalent between Mercury iPS and iPS-120 control syntax. It may be some things are missing/changed, but wondered if there was a table of all of this somewhere internally.
100
-
I do not think we have a document which succinctly summarises differences between Mercury iPS and the IPS-120 in the context of their remote command sets.
117
+
Yes we are looking for the equivalent between Mercury iPS and iPS-120 control syntax. It may be
118
+
some things are missing/changed, but wondered if there was a table of all of this somewhere
119
+
internally.
120
+
I do not think we have a document which succinctly summarises differences between Mercury iPS and
121
+
the IPS-120 in the context of their remote command sets.
101
122
102
-
Q: What are the new commands to use on the Mercury iPS which are equivalent to the commands from the old iPS-120 below?\
103
-
F17 (Trip Current)\
104
-
F19 (Trip Field)\
105
-
Xmn\
106
-
m = 1 quenched\
107
-
m = 2 overheated
123
+
Q: What are the new commands to use on the Mercury iPS which are equivalent to the commands from
124
+
the old iPS-120 below?\
125
+
`F17` (Trip Current)\
126
+
`F19` (Trip Field)\
127
+
`Xmn`\
128
+
`m = 1` quenched\
129
+
`m = 2` overheated
108
130
109
-
Answer from Robert Grzyb at Oxford Instruments:\
110
-
<em>F17/F19\
111
-
I assume that you mean legacy commands R17 (Trip Current) and R19 (Trip Field).
131
+
Answer from Oxford Instruments:\
132
+
<em>`F17/F19`\
133
+
I assume that you mean legacy commands `R17` (Trip Current) and `R19` (Trip Field).
112
134
This functionality is preserved when Mercury iPS remote interface is set to use legacy command set.
113
-
But when using "SCPI-style" command set, this exact information cannot be retrieved directly from the iPS.
114
-
Under certain (limited) circumstances R17/R19 are equivalent to DEV:<UID>:PSU:SIG:PCUR and DEV:<UID>:PSU:SIG:PFLD (note that UID must be a group, not an individual PSU).
135
+
But when using "SCPI-style" command set, this exact information cannot be retrieved directly from
136
+
the iPS.
137
+
Under certain (limited) circumstances `R17/R19` are equivalent to `DEV:<UID>:PSU:SIG:PCUR` and
138
+
`DEV:<UID>:PSU:SIG:PFLD` (note that UID must be a group, not an individual PSU).
115
139
116
-
Xmn
117
-
There is no equivalent for X (examine status) command in the "SCPI-style" command set.
118
-
As far as the first portion ("mn") of the reply to X command is concerned, certain "m" values correspond loosely to the bits of the status word in Mercury iPS group device (READ:DEV:<UID>:PSU:STAT).
119
-
The "n" part is not applicable to the Mercury iPS at all.
140
+
`Xmn`
141
+
There is no equivalent for `X` (examine status) command in the "SCPI-style" command set.
142
+
As far as the first portion (`mn`) of the reply to `X` command is concerned, certain `m` values
143
+
correspond loosely to the bits of the status word in Mercury iPS group device
144
+
(`READ:DEV:<UID>:PSU:STAT`).
145
+
The `n` part is not applicable to the Mercury iPS at all.
120
146
</em>
121
147
122
-
Q: For Xmn, I note that these may be dealt with by alarms which can be read with READ:DEV:<UID>:PSU:STAT in some hex format which is not defined in the manual (p. 162 in Issue 20). Could this be clarified?\
148
+
Q: For `Xmn`, I note that these may be dealt with by alarms which can be read with
149
+
`READ:DEV:<UID>:PSU:STAT` in some hex format which is not defined in the manual
150
+
(p. 162 in Issue 20). Could this be clarified?\
123
151
124
-
Asnwer from Robert Grzyb at Oxford Instruments:\
152
+
Answer from Oxford Instruments:\
125
153
<em>
126
-
READ:DEV:<UID>:PSU:STAT\
127
-
It is important to note that the STATus word should be examined at the group device level, not the individual PSU level.\
128
-
It is also very important to mask out (ignore) all other bits in this 32-bit word (i.e. ones not defined in the list given below):\
154
+
`READ:DEV:<UID>:PSU:STAT`\
155
+
It is important to note that the STATus word should be examined at the group device level,
156
+
not the individual PSU level.\
157
+
It is also very important to mask out (ignore) all other bits in this 32-bit word (i.e. ones
158
+
not defined in the list given below):\
129
159
</em>
130
160
131
161
| Status | Bit value |
@@ -147,26 +177,30 @@ It is also very important to mask out (ignore) all other bits in this 32-bit wor
147
177
| Voltage ADC error | 00010000 |
148
178
| Current ADC error | 00020000 |
149
179
150
-
Q: Also, is it possible to read if the Mercury iPS has tripped due to a low helium level signal from the level card (something like the X command on the old iLM200 which has a low level flag at bit 5 of S)?
180
+
Q: Also, is it possible to read if the Mercury iPS has tripped due to a low helium level signal
181
+
from the level card (something like the `X` command on the old `iLM200` which has a low level flag at
182
+
bit 5 of S)?
151
183
152
184
Answer:\
153
185
<em>
154
186
Low helium level
155
187
156
-
There is no direct indication of the fact that iPS has run the magnet down as a result of helium level dropping below a set threshold.\
157
-
It is possible to read both the helium level (DEV:<UID>:LVL:SIG:HEL) and the configured threshold for low helium alarm (DEV:<UID>:LVL:HEL:LOW).
188
+
There is no direct indication of the fact that iPS has run the magnet down as a result of helium
189
+
level dropping below a set threshold.\
190
+
It is possible to read both the helium level (`DEV:<UID>:LVL:SIG:HEL`) and the configured threshold
191
+
for low helium alarm (`DEV:<UID>:LVL:HEL:LOW`).
158
192
</em>
159
193
160
194
## Compromises with SCPI command set and EPICS
161
-
STS:SYSTEM:LIMIT\
162
-
Is an mbbi and has has 5 possible values:\
195
+
`STS:SYSTEM:LIMIT`\
196
+
Is an `mbbi` and has has 5 possible values:\
163
197
- 0: "Normal"
164
198
- 1: "On +ve V Limit"
165
199
- 2: "On -ve V Limit"
166
200
- 4: "Current too -ve"
167
201
- 8: "Current too +ve"
168
202
169
-
The limit flags came from the legacy command: Xmn
170
-
with the index denoted by the 'n' value.
203
+
The limit flags came from the legacy command: `Xmn`
0 commit comments