Repository navigation
Mercury iPS with fewer than three axes #6681
Description
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
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
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?
Activity
jenshnielsen commentedon Dec 3, 2024
Tobias Hangleiter (@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 commentedon Dec 3, 2024
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)withself._axes_selector = [1, 0, 1]in my case whenever a user-suppliedfield_vectoris handled.Making the FieldVector optional sounds complicated.
jenshnielsen commentedon Dec 3, 2024
Thanks for the insight Tobias Hangleiter (@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 commentedon Dec 12, 2024
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.