Transport String Parsing Error in QMI Framework for USBTMC Devices on Windows

[LoyalTea21]

Describe the bug A clear and concise description of what the bug is.

The QMI framework fails to properly parse the transport string for USBTMC devices, resulting in an invalid transport descriptor error. If I misunderstood the documentation or anything else, let me know.

To Reproduce Steps to reproduce the behavior:

Set up a QMI context in a Python application running on Windows.
Attempt to create an instrument using the make_instrument function with the following transport string format as given in the documentation at qmi.core.transport.py :
   - USBTMC device:     "usbtmc[:vendorid=0xvid][:productid=0xpid]:serialnr=sn"

Example code:

import qmi from qmi.instruments.Thorlabs.pm100d import Thorlabs_PM10x as powermeter

Create QMI context qmi.start("context")

Define transport string transport_string = "usbtmc[:vendorid=0x1313][:productid=0x8075]:serialnr=Pxxxxxxx"

Attempt to create instrument instrument = qmi.make_instrument("PowerMeter", powermeter, transport_string) instrument.open()

Expected behavior A clear and concise description of what you expected to happen.

The transport string should be properly parsed, and the instrument should be successfully created without any errors and be able to measure.

Operating System (please complete the following information):

OS: Windows
Version: [Your Windows version]

Anything else that might be relevant:

The issue seems to originate from the _parse_parts function in qmi.core.transport.py, which uses a regex expression to separate the parts of the transport descriptor. The current regex does not handle the provided transport string format correctly. I locally changed the regex expression as a temporary solution.

[heevasti]

Hi @LoyalTea21 , thank you for your report! I have a question: In the report you give the transport string as "usbtmc[:vendorid=0x1313][:productid=0x8075]:serialnr=Pxxxxxxx". Is this literally including the square brackets [ and ]? If yes, that is the reason for failing with parsing. The idea of the square brackets is to indicate that the entry is optional, and the brackets should not literally be included in the string. In this case, there seems to be a mistake in the documentation as the "vendorid" and "productid" are always required, and also do not have default values (like the serial port that has e.g. baudrate defaulted to 115200 if it is not included in the transport string).

We could also improve the documentation also writing clearly that the parts with square brackets are optional. Our apologies for this confusion.

But if the string did not include the square brackets, that would be strange. The parsing is unit-tested both for Linux and Windows. Then I would like to hear from you what exactly went wrong with the string and how did you temporarily fix it.

[LoyalTea21]

Hi @heevasti,

That does indeed solve my issue. I just wanted to note that this confusion was also caused by the regex expression in the _parse_parts function and documentation:

regex = re.compile(
    r"((?:^([^:]+))|"  # transport interface: i.e. serial:...
    r"(?::\[(.+)[\]$])|"  # enclosed parameter (for example used in ipv6): i.e. ...:[param]:... or ...:[param]
    r"(?::([^:]+)))"  # regular parameter: i.e. ...:param:... or ...:param
)

where it is suggested that the brackets are literal. Maybe I just misunderstood it. This gives an output of ['usbtmc', 'vendorid=0x1313]:[productid=0x8075', 'serialnr=Pxxxxxxx'] Nevertheless, thanks for your quick response!

[heevasti]

This has been solved in another ticket #94 with PR #95 .