Creating QCodes Driver with existing Python Interface

[Diddleydope]

Hello everyone!

I just finished creating a Python TCP interface for our instruments, which connects directly via TCP and allows users to interact with our instruments trough Python. There is significant demant for a QCodes Driver for our devices, however we do not support VISA, so I thought to use the IPInstrument class instead. Here is where I've run into my first problems. I want to integrate the Python interface into the package, which already has type checking, parsing and everything implemented for all the device's functions. I am unsure of two things: Firstly, should I use Parameters or normal functions to define all of the functions from the Python interface in the QCodeS driver? (see picture, nanonis_specs_specs is my python interface)

Secondly, the way I have the Parameter right now, it's not working. It is unclear to me how i tell the parameter how many parameters my get or set cmd has. I find the documentation to be a bit unclear. The issue I have with just defining a bunch of functions, is that I have to give the connection to the python interface as a parameter (see picture). I would appreciate any help on the matter.

Edit:

For clarification, this is the error I get when trying to call the parameter:

"TimeoutError: ('timed out', "writing '<nanonis_spm_specs.NanonisClass.Nanonis object at 0x120032600>.returnDebugInfo' to <NanonisSPM: NanonisSPM>", 'setting NanonisSPM_returnDebugInfo to 1')"

Kind regards,

Samuel O'Neill, SPECS Zurich

[jenshnielsen]

@Diddleydope Did you get your issue resolved (I can see that you marked this as such)

[Diddleydope]

Dear Mr Nielsen, The issue is not resolved per se, but we've found the root of the problem. Our python interface formats the data sent over TCP fundamentally differently than the IPInstrument class does. Our data is sent and parsed as a bytearray with a set size header, which defines the size of the body, and the data is parsed accordingly in the package. So the problem is, that the parameter in QCodeS is executing our function that I gave it as a set_cmd, but is executing it through the TCP connection in the python interface, which returns a bytearray and not a string, which is what the IPInstrument class needs/expects. Hence the function WAS being executed, but I was getting an Error from the recv function in IPInstrument, because it was getting a bytearray. And since we can't modify the way the IPInstrument class sends/receives data, we've run into a dead end. Perhaps a possibility would be to inherit from Instrument and make a SPECSInstrument Class, where we implement our own instrument specific send/receive methods to properly parse our data or just call our own python interface.

…

On Fri, 23 Feb 2024 at 16:24, Jens Hedegaard Nielsen < ***@***.***> wrote: @Diddleydope <https://github.com/Diddleydope> Did you get your issue resolved (I can see that you marked this as such) — Reply to this email directly, view it on GitHub <#5765 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARLCOTKA4UXS66N6TWDYJODYVCYDVAVCNFSM6AAAAABDWN3K66VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKNRZGYZTI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jenshnielsen]

Ok thanks for the update. You may want to simply not use the IP Instrument class but directly subclass Instrument to implement the logic that you need. The main things that you need are to implement get_raw and set_raw in a way that matches how you would like to communicate with your instrument.