[python-vxi11] ask() caught in an infinite loop

296 views
Skip to first unread message

Antony Chan

unread,
Mar 7, 2016, 5:48:05 AM3/7/16
to python-ivi
I was able to connect to the instrument (Agilent 86142B) and issue commands via VXI11 protocol, as long as I send the SCPI commands with vxi11.write(). However, whenever I try to read responses with either ask() or read_raw() functions, the functions seems to be caught in a loop and never returns any value. Is it a bug in the library?

Attached you can find the captured vxi11 stream from Wireshark.

Below is the test script:

import vxi11


d=None

if d is None:

d = vxi11.Instrument('10.42.0.100','hpib7,1')

print d.read_stb()            # returns 0

print d.write("init;*wai;calc:mark1:max") # returns None. Meanwhile, instrument currectly execute single sweep and then measure the peak of the waveform

print d.ask("calc:mark1:y?") # Wait indefinitely, have to abort the program with Ctrl-C


d.close()  # Program never reaches here.

vxi11_debug.pcap

Alex Forencich

unread,
Mar 7, 2016, 2:30:27 PM3/7/16
to pytho...@googlegroups.com
Looks like the instrument is not correctly implementing the VXI11 protocol.  It is responding to the read request immediately with 0 data bytes, no errors, and no reason code indicated.  It should not do this - the instrument should wait until there is some data to send, send an error, or indicate that the read is complete.  In this case, python-vxi11 thinks that the transfer is not yet complete and immediately sends another query to the instrument.  Not sure what the solution is here. 

For reference, see rule B.6.23 in the VXI-11 spec:

To successfully complete a device_read RPC, a network instrument server SHALL:
1. Transfer bytes into the data parameter until one of the following termination conditions are met:
a. An END indicator is read. The END bit in reason SHALL be set.  [no reason bits are set]
b. requestSize bytes are transferred. The REQCNT bit in reason SHALL be set. This
termination condition SHALL be used if requestSize is zero.  [no reason bits are set]
c. termchrset is set in flags and a character which matches termChar is transferred. The
CHR bit in reason SHALL be set.  [no reason bits are set]
d. The buffer used to return the response is full. No bits in reason SHALL BE set.  [no reason bits are set, but no data was transferred]
2. Return with error set to 0, no error, to indicate successful completion.
If more than one termination condition is valid, reason contains the bitwise inclusive OR of all the
reasons.

I'm not sure how to deal with this issue, unfortunately.  You may just need to talk to the instrument over GPIB.  We have one of those in the lab as well, but I couldn't get it working either (though I didn't do too much debugging), so it now sits behind an E5810B along with several other instruments. 

Alex Forencich
--
You received this message because you are subscribed to the Google Groups "python-ivi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-ivi+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Antony Chan

unread,
Mar 7, 2016, 7:52:28 PM3/7/16
to python-ivi
I end up using another source code written in C, provided here:


Although the above project also provides a Python interface, exception handling is a nightmare. I wonder how your source code can be patched to workaround the issue? For your information, attached please find the captured network stream for the following SCPI commands:
*IDN?
INIT;*WAI;CALC:MARK1:MAX
CALC:MARK1:X?
vxi11_working.pcap

Alex Forencich

unread,
Mar 7, 2016, 8:00:58 PM3/7/16
to pytho...@googlegroups.com
Hmm.  That code sends the read call with size 1024.  python-vxi11 sets that to 1 GiB.  Perhaps there is a truncation issue in the instrument firmware (maybe they used a 16 bit int instead of a 32 bit int).  Try python-vxi11 again, but set max_recv_size to 1024 before trying to read and see what happens.  I don't want to set the value to 1024 in the library as that will cause large transfers to slow down, but maybe some intermediate value would work well, like 64 KiB or 1 MiB. 

Alex Forencich

Alex Forencich

unread,
Mar 7, 2016, 8:05:09 PM3/7/16
to pytho...@googlegroups.com
Also, make sure open() gets called before you change max_recv_size.  open() gets called automatically when you perform a read or write, but you can also call it explicitly. 

Something like this:

import vxi11


d=None

if d is None:

d = vxi11.Instrument('10.42.0.100','hpib7,1')

d.open()

d.max_recv_size = 1024

print d.read_stb()

print d.write("init;*wai;calc:mark1:max")

print d.ask("calc:mark1:y?")


d.close()


Alex Forencich

Alex Forencich

unread,
Mar 9, 2016, 5:07:50 PM3/9/16
to pytho...@googlegroups.com
Good news: I managed to duplicate the issue on a similar model OSA that I have access to in the lab.  And I managed to get it to work by setting a smaller max_recv_size.  I just pushed changes to my fork of python-vxi11 to limit max_recv_size to 1 MiB, which seems to work fine.  So please try it out and let me know if it works on your unit. 

Alex Forencich

On 03/07/2016 04:52 PM, Antony Chan wrote:

Antony Chan

unread,
Mar 11, 2016, 12:00:58 AM3/11/16
to python-ivi
The solution works on my Agilent 86142B OSA. Thank you very much!

Antony
Reply all
Reply to author
Forward
0 new messages