Request to support SRQ #20

Activity

1. alexforencich commented on Jan 11, 2017

   

   alexforencich

   on Jan 11, 2017

   Contributor

   More actions

   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.
2. mojca commented on Jan 11, 2017

   

   mojca

   on Jan 11, 2017

   Author

   More actions

   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.
3. mojca commented on Jan 13, 2017

   

   mojca

   on Jan 13, 2017

   Author

   More actions

   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.
4. mojca commented on Feb 22, 2017

   

   mojca

   on Feb 22, 2017

   Author

   More actions

   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.
5. tin- commented on Jul 22, 2018

   

   tin-

   on Jul 22, 2018

   More actions

   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.
6. ulda commented on Apr 5, 2021

   

   ulda

   on Apr 5, 2021

   More actions

   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.
7. mojca commented on Apr 5, 2021

   

   mojca

   on Apr 5, 2021

   Author

   More actions

   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).