-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New QMI driver for Thorlabs MPC320 #62
Comments
|
The motor control messages (page 61) also fail to mention the MPC320, so now I'm thinking that the MPC320 is a new device and only the contents page of the manual was updated without updating the commands. I'll check with Thorlabs |
Will remain blocked until reply from Thorlabs regarding certain commands |
Description
The Thorlabs USB device(s) use(s) FTDI peripehral chips for PC communication. For these, there are (USB-to-serial) drivers available for Windows and Linux from FTDI. "Before any PC USB communication can be established with an
Thorlabs controller, the client program is required to set up the necessary FTDI chip serial
port settings used to communicate to the Thorlabs controller embedded system. Within the
Thorlabs software itself the following FTDI library calls are made to set up the USB chip serial
port for each Thorlabs USB device enumerated on the bus." Example:
So with a USB-to-serial driver, we set up the comms with baud rate of 115200 and the rest are default (also RTS/CTS Handshake).
USB Device Enumeration
The USB devices connected to the PC are enumerated, and serial numbers are read from the devices. For MPC320 the
serial number appears to start with "38", as seen on hardware manual p5. The number "38" is followed by six digits, which are the actual serial number. "38" is the harwadre type indicator.
APT Communication protocol
The protocol communicates through messages, which have a structure that always starts with a fixed length, 6-byte message header which, in some cases, is followed by a variable length data packet.
The header part of the message always contains information that indicates whether a data
packet follows the header and if so, the number of bytes that the data packet contains.
Values that are longer than a byte follow the Intel little-endian format.
Bytes 0 & 1 are the message ID, describing the action the message requests.
Bytes 2 & 3 give the data packet length if data packet follows or
Byte 2 gives param1 and Byte 3 gives param2. If no parameters are required, these are 0.
Byte 4 gives the destination module, or destination module | 0x80 for data packet. This
gives indication if a data packet follows or not. If the MSB of byte 4 is set, then the message will be followed by a data packet.
Byte 5 gives the source of the message.
As we have a system with 3 sub-modules (paddles), we probably have a communication system that goes through the devices motherboard to these sub-modules. The source bytes therefore likely will be
0x01 Host controller (i.e., control PC)
0x11 Rack controller, motherboard in a card slot system or comms router board
0x21 Bay 0 in a card slot system (paddle 1)
0x22 Bay 1 in a card slot system (paddle 2)
0x23 etc (paddle 3)
"The host sends a message to the motherboard that the sub-modules are plugged into, with the destination field of each message indicating which slot the message must be routed to... In slot-type systems the host can also send messages to the motherboard that the sub-modules are plugged into (destination byte = 0x11). In fact, as a very first step in the communications process, the host must send a message to the motherboard to find out which slots are used in the system... Sub-modules never send SET and REQUEST messages to the host and GET messages are always sent to the host as a destination."
Format Specifiers
For example, decimal 12345 (3039H) is encoded as the byte sequence 39, 30.
For example, decimal -1 is encoded as the byte sequence FF, FF.
For example, decimal 123456789 (75BCD15H) is encoded as the byte sequence 15, CD, 5B, 07
For example, decimal -1 is encoded as the byte sequence FF, FF.
For example, decimal -123456789 (FFFFFFFFF8A432EBH) is encoded as the byte sequence EB, 32, A4, F8,.
Messages Applicable to MPC220 and MPC320
Inputs:
chanID
should be possible to give two channels as input 0x01 or 0x02. But MPC320 probably has only one "channel", 0x01. Not fully clear.destID
is 0x11 for controller and 0x21-0x23 for paddles 1, 2, 3, respectively. Also called as "bays" in documentation.hostID
byte 5 is "always" 0x01, the Host Controller.de0x80
likedestID
but inputted with the logical OR 0x80.ho0x80
likehostID
but inputted with the logical OR 0x80.enabSt
Enable states, 0x01 for enable, 0x02 for disabledir
The direction to Jog. 0x01 to jog forward, or 0x02 to jog in the reverse direction.StopMd
0x01 to stop immediately, or 0x02 to stop in a controller (profiled) manner.reqbuf
A 'ctypes.int' (or so) modifiable buffer value that will be changed during command. Usually the single-byte "get" response.data bits
if the inputted command expects input value(s) more than 1 byte. This will be appended to the command header as data bits (no buffer!).Returns:
data bits
if the inputted command expects a response. This will be appended to the command (6 bits) as a buffer that the device response will fill.The format on the table is ": <start_byte-end_byte description>, <start_byte2-end_byte2 description2>, ..."
returns
is what the Python implementation should returnNote that we do not suggest yet specific names for the Python functions. Also note that query functions can be combinations of two or more commands. E.g.
get_idn() -> QMI_InstrumentIdentification
needs to first send the request (0x0005) and the obtain the respose with another command (0x0006).Note also that the data bits can have specific format specifiers per byte range. Check the manual for those specifiers.
Figure out motor type and which conversions might be needed. As Thorlabs parameters are integer values, the Thorlabs values calculated from the conversion equations need to be rounded to the nearest integer. This is mostly done already in a scientist-made driver for the device, see
instruments.thorlabs.mpc320
in169-ltfiber-experiments-towards-transmission-dip
branch in Diamondos.As the motor types are different and the driver could be applied also to other hardware of Thorlabs, it could be beneficial to directly make the driver the same way as the Newport
single_axis_motion_controller.py
where the actuators (motors) are defined inactuators.py
,where we would now define the conversion constants as part of the actuator (motor) class. Also we can directly implement two classes, the linear and the rotational one.
Modules to be created
qmi.instruments.thorlabs.apt_packets.py
qmi.instruments.thorlabs.apt_protocol.py
qmi.instruments.thorlabs.mpc320.py
Modules to be modified
qmi.instruments.thorlabs.__init__.py
Unit-tests to be created or modified
tests.instruments.thorlabs.test_apt_protocol.py
tests.instruments.thorlabs.test_mpc320.py
Documentation to be updated
CHANGELOG.md
Hardware
Thorlabs MPC320 (this will need to be added to the dialout group if using on Linux)
The text was updated successfully, but these errors were encountered: