Skip to content
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

Enhancement: Better Resource info #416

Open
ilfirin-ms opened this issue Mar 4, 2024 · 5 comments
Open

Enhancement: Better Resource info #416

ilfirin-ms opened this issue Mar 4, 2024 · 5 comments

Comments

@ilfirin-ms
Copy link

I would like to have better info about resources, without opening them, if the info is available, I know it's not possible for raw tcpip.

Like manufacture, model, serial ...

I see some of it is supported when using pyvisa with visa library, but not with pyvisa-py backend.

Not that I know how to do it properly, there is plenty magic required to work.

At Windows pywin32 is needed unless ctypes magic, what pyserial does.
At linux, wrapping lsusb output or pyudev, or again, pyserial walks through sysfs to get info.

Interesting implementation is pyserial.list_ports https://github.com/pyserial/pyserial/tree/master/serial/tools
which works pretty well, there is description, manufacturer even serial number of FT232 USB UART, which could be used as serial number of USBTMC device, convenient to properly open same device regardless what com_port/tty was assigned.

Same issue with USBTMC, pyvisa gives me usb id and serial, but not manufacturer and product, which is known by OS.

It's not a small task, I am aware.

@arr-ee
Copy link
Contributor

arr-ee commented Mar 4, 2024

I’ve been considering this as well, since it is quite useful.

The issue I stopped at is that getting this info is inconsistent per transport. GPIB and TCP/LXI won’t give us anything without issuing commands, USB might but very much dependent on vendor, ditto for serial.

Trying to connect to each device and *IDN? sounds more useful to me, but then we run into all the communications issues (hi, read_termination!) Still, imo this route would be more useful, even if more complex.

@ilfirin-ms
Copy link
Author

USB should not be dependent on vendor. Device ID, Manufacturer etc. is, afaik, part of USB protocol.

Sending *IDN? blindly should work for USB-TMC devices, where is good level of certainty of response/not breaking things.
But trying to open all serial ports and send *IDN? there sounds horribly - not knowing baudrate and causing multiple access to already accessed ports and potentially confusing not SCPI devices.
I have vivid memories, how Network Manager started sending all the AT commands to my USB-ACM devices, when they appeared.

That's why I would like to know better beforehand, yes this is the device I am looking for, by mainly manufacturer/device/serial_number combo.

@arr-ee
Copy link
Contributor

arr-ee commented Mar 4, 2024

USB should not be dependent on vendor

By “dependent on vendor” I meant quality of data provided — unfortunately, not all give good info.

Agreed that spamming *IDN? to all serial ports is not a great idea. I think I see your point overall, although it feels like it belongs in pyvisa proper, with additional work here.

I’ll try to poke at it later this week to see how bad it is.

@ilfirin-ms
Copy link
Author

ilfirin-ms commented Mar 4, 2024

Bad quality info is better than no info.

As far as I can tell, I had no issue with incorrect vendor/device/serial info on USB, even with Chinese devices.

As I have written, pyvisa with dll have less issues with this. According to bug: pyvisa/pyvisa#597
there is rm.visalib.get_attribute(session = 1, attribute = 0xBFFF0174)[0]
and even rm.visalib.get_debug_info() provides manufacturer data.
Neither is working with pyvisa-py.

@arr-ee
Copy link
Contributor

arr-ee commented Mar 4, 2024

Yup, agreed on something over nothing.

Thank you for pointing out the APIs on VISA side, that’s helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants