Request to support SRQ

[mojca]

I see that python-vxi11 has some code that says "SRQ", but it's not clear to me how to use it.

According to this thread I suspect that the functionality might not yet be properly implemented.

My use case is that our instrument sends an "SRQ" event when the data is ready, then I guess that I need to read the status byte and run a function that reads the data out.

I think that this library supports SRQ, but it does it via some C++.

[alexforencich]

How should the script receive the SRQ event from python-vxi11? Give me a coherent answer for that, and I'll look in to implementing it.

[mojca]

Please allow me some time to read a bit more about it, do some experiments with two C / C++ libraries for VXI11 to work with our instrument, perhaps take a look at the other python library and then I'll come up with some suggestion. (I'm new to VXI11.) And of course thank you very much for your excellent library.

[mojca]

Here's just a partial answer.

One of the possible uses of SRQ could be as follows:

instr.write(":FOO")
instr.wait_for_srq()
instr.ask(":BAR?")

This would actually work for me in some cases.

But generally one would probably try to avoid waiting forever in case the instrument doesn't send the SRQ back and it would be better to define some callback function. I need to figure out how this can be done in Python though (and do some more testing in C). It might require some multithreading.

[mojca]

The C library I'm using supports two different modes.

Mode 1

The user can manually start a new thread. Suppose that this thread is there just to collect data and let's assume that

instr = vxi11.Instrument(instrument_ip)

The data-collecting thread would then continuously call something like

def data_collecting_thread(instr):
    while True:
        return_value, status_byte = instr.wait_srq(timeout)
        if should_exit_thread():
            return
        elif return_value == 0 and ((status_byte >> 6) & 1):
            # fetch data from device

where return_value equals 0 in case the SRQ event arrived within the specified time frame and 1 in case there was no SRQ. The status_byte returns the value of the Status Byte Register. See http://www.ni.com/white-paper/4629/en/ for some explanation about how Service Requests work (I can also point you to the documentation of a specific manufacturer of VXI11 devices).

(I sometimes get an SRQ with status byte 0 and it's not yet clear to me when exactly that happens. But that's usually not about events that I'm looking for.)

Usually the status byte should have bit 6 set to high together with some other bits that might be interesting to you (depends on the instrument).

Whenever the main thread wants to stop data collection, it just calls

instr.abort_wait_srq()

and joins the data collection thread. The instr.abort_wait_srq() will make instr.wait_srq(timeout) exit immediately (but of course the # fetch data from device part might still be running).

Mode 2

The main thread calls

instr.set_callback(callback_function_name, <some parameters that are passed to function_name>)

And this automatically/transparently creates another thread for the user that takes care of waiting for SRQ and calls the specified function whenever an SRQ event occurs. All the data processing is done in that function.

Whenever one wants to stop the data collection, it's just a matter of calling

instr.reset_callback()

which will ignore any subsequent SRQ events.

The library I'm using has a drawback that callback_function_name might still be running while reset_callback() is called and the main thread might already close and destroy the instr. This is a slightly unfortunate design.

In both cases it's up to the user to take care of proper locking mechanism (mutexes) etc. and to avoid communicating with the device from both threads at the same time. I don't know if it's any easier to automatically take care of this from Python as I never used multithreading in Python.

[tin-]

I can only +1 to desire on SRQ support. Typical use for this is DMM calibration purposes, when instrument running thru internal procedures during calibration steps (which may take minutes) and controller pools status. When SRQ received, DUT ready to accept next commands. Without SRQ support, I have to bodge code and find out delay time for each step to program the calibration sequence. Since each DMM have different timing, resulting hack is not easy to support. I've used linux-gpib library with NI GPIB-USB-HS dongle and SRQ-way worked perfectly there. Now looking the same direction to use with Agilent E5810A and python-vxi11.

[ulda]

I implemented SRQ handling and activation using a simple callback function, see the example in
my current to-upstream branch of vxi11-server
I need someone to test this with a real instrument.

[mojca]

Thank you very much for implementing this.
I was regularly working with one device that required this functionality for best performance (I wrote some non-trivial C++ software to work with it, so I still know that device from inside out) and I had it available for about three years, but I no longer know how to easily get hold of one to be able to test (they cost tens of thousands of euros; I know two companies that owe it, but it's somewhat weird to ask them to come to their labs and disturb their working process to check this).

(The cheap Rigols on my bench don't support SRQ.)

It's quite possible that I could easily get hold of another instrument with SRQ support, but unless there's a list of such devices somewhere, I'm not sure where to start looking (too many brands and models to check).