Products > Test Equipment
UNI-T UTG932/UTG962 200MSa/s Function Arbitrary Waveform Generator
adeuring:
ISTM that it is not a good idea to use the read_raw() method. I'd suggest to call read_bytes() instead. I don't have a UTG932/UTG963, so the following stuff is to a good part based on guesses.
My guesses are:
1. The UTG9x2 uses a simple USB/UART adapter, probably a CH340, not a USBTMC chip.
2. On Linux, you are using PyVisa together with the PyVisa-py backend.
I looked a bit into the source code of PyVisa and PyVisa-py, which turned out to become a sneak into a rabbit hole and I shyed away from following the whole call stack of read functions, beginning at MessageBasedResource.read_raw() (in the package PyVisa), via SerialSession.read() down to Session.read() (the two latter methods are defined in the package PyVisa-py).
SCPI is mostly a text / line based protocol, so it is quite easy for an SCPI library to detect the end of a message sent from an SCPI device by searching for the hex values 0x0A and 0x0D )lone feed / carriage return). When you are reading binary data (like the screenshot), you can't use this check, since the values 0x0A and 0x0D may appear in the binary data. Hence you need another way to figure out if/when the message received from an SCPI device is complete. If you only have the RX/TX lines of a serial interface (or a simple TCP socket...), and if you do not have (or use – see below) any prior information about the length of the data you expect, only one way is left to figure out if the SCPI device has sent all data: A timeout.
Now let's have a quick look at the source code of the method read_raw():
current Github status, i.e., commit 4849311) https://github.com/pyvisa/pyvisa/blob/48493113f2df2106ffc664ab89eb644ebf935354/pyvisa/resources/messagebased.py.
read_raw(self, size: Optional[int] = None) is defined in line 411. The parameter "size" (which even does not need to be specified) is _not_ the number of bytes to read but just the chunk size for read calls of the transport layer. The doc string of the method does not explain how/when the read_raw() call terminates.
Let's look a bit deeper:
read_raw() is basically a "wrapper" for the method _read_raw(), defined in line 430. This method calls self.visalib.read(self.session, size) in a loop; the loop terminates when self.visalib.read() returns a certain status. I don't know what this status is and how
--- Code: ---visalib.read()
--- End code ---
detects that a message is completed – I wasn't sure if I would find the way back if I would go down into this part of the rabbit hole, which is probably PyVisa-py in your case...
I guess that you can somewhere set a timeout value for the visalib.read() calls – but that's hidden somewhere quite deep in the rabbit hole ;)
On the other hand: The data that the UTG9x2 sends back for the ":DISP?" command contains enough information that you don't have to rely on the obviously fragile read_raw() call. The first 10 Bytes or so tell you all you need: The length of the following binary data. The first byte should always be the '#' sign; the second byte is the number of digits of the following length information as an ASCII digit; the next N bytes (N being given in the second byte) contain the length of the binary data, again as ASCII digits. So you could try something like this:
--- Code: ---sgen.write(":DISP?")
l1 = sgen.read_bytes(2)
if l1[0] != b'#':
raise RuntimeError(f'Unexpected response for :DISP? {l1!r}'
l2 = sgen.read_bytes(int(l1[1]))
bitmap = sgen.read_bytes(int(l2))
--- End code ---
For debugging, add print(l1) and print(l2) to check if you got the ":DISP?" command right: As renaatd wrote in comment #428:
--- Quote ---Just tried with "Display:Data?" in combination with read_binary_values, and it returns some data, but different from ":DISP?". Also tried with ":Disp?" and that causes a timeout. So I guess it's better to stick with ":DISP?".
--- End quote ---
So it makes sense to check if you get anything back for the command you sent to the device – it seems that these cheap SCPI devices often do not have the most robust SCPI parsers...
Final rant: It seems that you are not the only one who has problems using the read_raw() method, at least in the combination PyVisa and PyVisa-py. Have a look at https://github.com/pyvisa/pyvisa-py/issues?q=is%3Aopen+read_raw
A real highlight is this bug https://github.com/pyvisa/pyvisa-py/issues/101
--- Quote ---Adding some diagnostics to TCPIPInstrSession.read(), this is what I see:
--- Code: --- wanted 4096 bytes, read 1152057 bytes
want -1131577 more bytes
--- End code ---
--- End quote ---
OK, this bug is a bit older – perhaps the maintainers just forgot to close it.
Having played a bit with PyVisa and PyVisa-py as well as NI-Visa as an electronics hobbyist (with professional software developer background), I came to the conclusions that it is seldom worth the effort to deal with all the Visa-related hassles. It can be easier to simply use a lower-level access to SCPI devices, be it plain TCP sockets for devices with an Ethernet interface, or a library like PySerial for the many devices with USB/UART adapters or real RS232 interfaces.
The situation may be different for people who are juggling with 10 or 20 SCPI devices in a professional application.
aix:
Thanks for such a detailed look into this. I'll need some time to process this and play a bit more, but in the meantime some observations:
* :SYSTem:INfo? locks up in the same way as the screenshot command, even though its output is a single line of text terminated by a newline. My hypothesis is that what makes it lock up is the fact that the output doesn't fit in a single USB packet.
* I played with read(), read_raw(), read_binary_values() and query(). They all lock up in exactly the same way.With regards to UART and Ethernet interfaces, the device sadly offers neither. USBTMC is the only thing that's available.
renaatd:
--- Quote from: aix on October 05, 2024, 05:11:11 pm ---
I just tried this exact code with my device and it also hangs on read.
I've now tried several versions of Linux on two hardware architectures (aarch64 and x86_64) and the behaviour is remarkably consistent across all the configurations. I wonder if it has something to do with my device or with how I'm configuring pyvisa.
If you have a working setup, would you mind sharing the firmware version of your device and the output of pyvisa-info? Thanks!
--- End quote ---
Just tested on x86_64, and it works here.
Device version (Utility | System | About):
Software verson 3.06
Hardware verison 1.01
FPGA verson 3.01
PyVisa: as installed via dpkg on Ubuntu 24.04:
$ pyvisa-info
Machine Details:
Platform ID: Linux-6.8.0-45-generic-x86_64-with-glibc2.39
Processor: x86_64
Python:
Implementation: CPython
Executable: /usr/bin/python3
Version: 3.12.3
Compiler: GCC 13.2.0
Bits: 64bit
Build: Sep 11 2024 14:17:37 (#main)
Unicode: UCS4
PyVISA Version: 1.11.3
Backends:
ivi:
Version: 1.11.3 (bundled with PyVISA)
Binary library: Not found
py:
Version: 0.5.1
ASRL INSTR: Available via PySerial (3.5)
USB INSTR: Available via PyUSB (1.2.1-2). Backend: libusb1
USB RAW: Available via PyUSB (1.2.1-2). Backend: libusb1
TCPIP INSTR: Available
TCPIP SOCKET: Available
GPIB INSTR:
Please install linux-gpib (Linux) or gpib-ctypes (Windows, Linux) to use this resource type. Note that installing gpib-ctypes will give you access to a broader range of funcionality.
No module named 'gpib'
aix:
--- Quote from: renaatd on October 06, 2024, 06:27:40 pm ---Just tested on x86_64, and it works here.
Device version (Utility | System | About):
...
PyVisa: as installed via dpkg on Ubuntu 24.04:
...
--- End quote ---
Thank you, that's very helpful indeed. Perhaps the most glaring difference is that I'm on much newer versions of pyvisa and pyvisa-py (both installed using pip). I'll try the Ubuntu deb packages on my 24.04 box, to try and match this aspect of your config. Thanks again.
aix:
Thanks again renaatd.
I've matched your config and everything now works (on a Raspberry Pi). For posterity, here's a working requirements.txt:
pyvisa == 1.11.3
pyvisa-py == 0.5.1
pyusb == 1.2.1
If I turn on logging, I can see that I'm hitting https://github.com/pyvisa/pyvisa-py/issues/293, but that doesn't seem to cause any issues.
P.S. Upgrading to pyvisa-py 0.5.2 makes the warning go away without causing any ill effects.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version