ibonl(0,0) close ALL devices in ALL processes

[GAINZT]

Our test system have a "monitoring" process programmed to monitor SRQ from GPIB intruments during test program execution.
From our experience, it seems that any test program calling the ibonl(0,0) function will corrupt our "monitoring" process. In fact, it seems that if any process close the GPIB0 board in the GPIB library then this board will also be closed in other processes. It our case, the SRQ callback (installed with ibconfig) will be called repeatedly until we deactivate it.
This a bit annoying for our test system, and we would like to now if this is the intended behavior or if it's a bug in the GPIB library ?

Furthermore, is this problem specific to the GPIB library or could it happen in another library (mainly
VXI and VISA) ?

[Dan_Mondrik]

This is an issue with NI-488 versions prior to 2.0. If you have a PCI-GPIB, USB-GPIB, or ENET-GPIB controller, then I suggest you go to ni.com/downloads and get the latest NI-488 driver.

The newer versions have a better definition for how multiple processes affect (or do not affect) each other. Specifically in your case, taking a board offline in one process will not affect board-level functionality in other processes. (Prior to 2.0, it took the board offline globally, which is what you are seeing.)

The problem you are seeing is specific to NI-488. If you mix and match NI-488 and NI-VISA programs, you may see the same symptom, since NI-VISA uses NI-488 for its GPIB functionality. However, if you are using just NI-VISA, you would probably not see thi
s symptom, since we have worked around this issue by ensuring that we never take a GPIB board offline if any other VISA module or process is using that same GPIB board.

Also note that each driver potentially has its own set of bugs. So while I would not expect it anywhere else in NI-VXI or NI-VISA, I cannot guarantee that.

Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments