Time limit error on Alpao mirror

[NickHallPhysics]

There appears to be a problem communicating with the Alpao mirror in hardware trigger mode. The first pattern sent using the function "apply_pattern" in mirror/alpao.py (lines 129-134) seems to be applied fine, but any subsequent patterns applied yield:

"Time limit exceeded during the transfer.(error 258)"

As an error message from self._raise_if_error(status) (line 134).

This only happens in hardware trigger mode. I'm unsure of how to rectify this as we need the Alpao in hardware trigger mode for experiments, but we also (currently) send it ad hoc, one off patterns from time to time. Potentially we could have a check in "apply_patterns" to see if the DM is in hardware trigger mode, if so, turn it back to software trigger mode, apply the sent single pattern and then swap back to the previous trigger mode, but that seems inelegant.

This also might be related to Issue #50, but that error occurred under Python 2 and we are now running Python 3.7. Additionally, whilst we have been running Python 3.7 for a number of weeks now, this problem only occurred in the last few days which makes me suspect something more is happening behind the scenes that I don't know enough to ascertain.

Finally, re-initialising a Pyro connection (as happens with Cockpit's startup) but not re-initialising the device serve on the remote and trying to send another pattern after getting the above error means one obtains a different error:

"Exception: Send failled. PCIS-DASK::ERR-201: The configuration API failed.(error 260)"

However, I have a strong suspicion that whatever causes the error 258 is also causing this error 260 and so addressing the underlying issue should solve both.

[mickp]

Nick and I discussed this yesterday. It's not clear why this has recently started to timeout. Things to check:

• cables
• that patterns are created with or converted to the correct data type (the DLL expects a pointer to an array of c_doubles; it may be being passed a pointer to an array of c_longdoubles, depending on the default dtype used by numpy on the client machine)

[mickp]

Issue #61 suggests this may be by design or a limitation of the device: it states

apply pattern in the alpao mirror only works in software trigger mode

[carandraug]

I think Mick is right and this is duplicated of issue #61. You can't apply a pattern with software if you are set to hardware trigger mode. You could queue a new pattern and then send a hardware trigger or change to software trigger if that's what you want to use. Just to be sure this is indeed the same bug, the issue is that the following code fails with that error?

dm = microscope.mirror.alpao.AlpaoDeformableMirror(serial_number)
dm.set_trigger(microscope.devices.TriggerType.RISING_EDGE,
               microscope.devices.TriggerMode.ONCE)
dm.apply_pattern(numpy.zeros((69,))

[carandraug]

@NickHallONBI what did you about this in the end? It's been a year and half.

[NickHallPhysics]

@carandraug when the DM was added as an element of the AO composite device for Microscope-AOtools sending single patterns to the DM was incorporated into the "send" function. In that function in Microscope-AOtools, the current trigger type of the DM is queried. If it isn't "SOFTWARE", then the current trigger type and trigger mode are recorded, the trigger type and mode are set to "SOFTWARE" and "ONCE" respectively, the single pattern is sent and then the trigger type and mode are set back to what they were before.

I'm not sure this constitutes a 'fix' though, just a work around.

See Microscope-AOtools, aoDev.py file, lines 284-302 for more details on the "send" function.