Thorlabs APT `APTMotorController` issues

[trappitsch]

Documenting the issue with the APTMotorController here, which I will attempt to fix in PR #334. Mostly intended for documentation (the APT class seems to be a constant work in progress thing) so we know in the future what the thinking behind the fix was. Glad for any comments :)

First off: Thorlabs allows the user to set a backlash correction for stage movements. This is currently not exposed to the user in the IK routine but should be fixed.

Second: This is tested with a KDC101 controller cube connected to a PRM1-Z8 rotation stage. Initializing an instrument, i.e., via

baud = 115200
port = "/dev/ttyUSB3"

apt = ik.thorlabs.APTMotorController.open_serial(port, baud=baud)

works great. I can also move the stage without any issues using:

ch.move(u.Quantity(5, u.deg))

However, if I do another move, i.e.,

ch.move(u.Quantity(10, u.deg))

an OSError is raised:

Traceback (most recent call last):
  File "/home/reto/.pyenv/versions/3.9.9/lib/python3.9/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<input>", line 1, in <module>
  File "/home/reto/opt/pycharm-2021.3/plugins/python/helpers/pydev/_pydev_bundle/pydev_umd.py", line 198, in runfile
    pydev_imports.execfile(filename, global_vars, local_vars)  # execute the script
  File "/home/reto/opt/pycharm-2021.3/plugins/python/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "/home/reto/Documents/code/InstrumentKit/var/reto_temp.py", line 23, in <module>
    ch.move(u.Quantity(10, u.deg))
  File "/home/reto/Documents/code/InstrumentKit/instruments/thorlabs/thorlabsapt.py", line 1484, in move
    _ = self._apt.querypacket(
  File "/home/reto/Documents/code/InstrumentKit/instruments/thorlabs/_abstract.py", line 100, in querypacket
    raise OSError(
OSError: APT returned message ID 1, expected 1124

Obviously, the APT controller sends back the wrong package.

This error is always showing up after the first movement, as if the buffer were not cleared. In fact, If I run a homing routine after the first movement (which takes several seconds to complete), the OSError shows up way before the motion is completed and an appropriate the-stage-has-finished-moving package is even sent from the APT controller.

Rewriting the package queries shows that several "bad" packages, including something that doesn't represent a package at all (wrong length) arrives. Then empty packages (no response) show up (so the buffer is clear now). Afterwards, the correct package shows up AFTER the motion has stopped (as expected). This further points to: (1) the package expected is longer than expected or (2) the buffer is not cleared...

[trappitsch]

After a move, the MGMSG_MOT_MOVE_COMPLETED is expected, which has a data length of 14 bytes. However, the expect_data_len in the _apt.querypacket() call is not set, therefore ik is not expecting any data and the buffer contains 14 more bytes, which results in an error when doing the second move.

Now going to look through the rest of the routines that are possible for a KDC101...

[trappitsch]

Checked the whole manual: MSMSG_MOT_MOVE_COMPLETED should return the same expected data length for all instruments.