Mercury iPS with fewer than three axes

[thangleiter]

The Oxford Mercury iPS driver currently assumes a three-axis vector magnet:

Qcodes/src/qcodes/instrument_drivers/oxford/MercuryiPS_VISA.py

Lines 330 to 334 in 1280f4a

	# TODO: Query instrument to ensure which PSUs are actually present
	for grp in ["GRPX", "GRPY", "GRPZ"]:
	psu_name = grp
	psu = OxfordMercuryWorkerPS(self, psu_name, grp)
	self.add_submodule(psu_name, psu)

For systems with fewer axes than this, the instrument-level parameters like z_ramp do not work / run indefinitely because _ramp_safely() (same for _ramp_simultaneously_blocking()) waits for each axis to return from state "TO SET", which axes that do not exist never do.

Qcodes/src/qcodes/instrument_drivers/oxford/MercuryiPS_VISA.py

Lines 539 to 547 in 1280f4a

	for worker in np.array(list(self.submodules.values()))[order]:
	worker.ramp_to_target()
	# now just wait for the ramp to finish
	# (unless we are testing)
	if self.visabackend == "sim":
	pass
	else:
	while worker.ramp_status() == "TO SET":
	time.sleep(0.1)

The old driver (removed in #4936) allowed users to either specify which axes are present or queried the device itself for this information. I'm not sure how readily the current driver admits this due to the use of FieldVector. Can its components of axes that do not exist simply be set to zero always?

[jenshnielsen]

@thangleiter Thanks for the question. I think that originally the Mercury drivers were only different in underlying communication library, but the visa version later gained support for using FieldVector to better handle circular and spherical coordinates. I am not sure what the best would be but a good place to start would probably indeed be to update the FieldVector to work correctly with 2 dim and error if the third dim is set. Alternatively, perhaps the driver could be refactored to make the use of fieldvector optional

[thangleiter]

My magnet is X/Z with 1 master and 3 slaves. The command that the old driver used to query which axes are present returns ... all three. So automatic detection seems out of the question. Passing the axes as an init arg, I could imagine doing something like itertools.compress(field_vector, self._axes_selector) with self._axes_selector = [1, 0, 1] in my case whenever a user-supplied field_vector is handled.

Making the FieldVector optional sounds complicated.

[jenshnielsen]

Thanks for the insight @thangleiter I have not seen that setup before. It you are open to write a pr that enables that kind of control I am happy to review it. I think we have simulated instruments so it should be possible to write some somewhat robust tests for this

[thangleiter]

I'm open to do that in principle but I'd have to see if and when I get around to it. I'd be happy to test someone else's implementation any time though.