viOpen fails with 0xBFFF011 (VI_ERROR_RSRC_NFOUND)

[markus kossmann]

Setup:  Teststand 3.1 application with code modules developed with Labwindows 7.1 on Windows XP SP2 german on ACER PC.  Instruments (multimeter  Agilent 34401 on addr 22, powersupply  Agilent 6032 A on addr 5 , load Agilent 6060A on addr 6) attached to the PC with NI GPIB-USB-HS using the drivers from the NI-488.2 V2.5 CD . The application is known to work on a DELL PC with XP SP2 english version. 

Checking the Instruments with MAX shows no errors ( communication with the 6032A works as expected). But when running the program, the viOpen()  on the  6032 A fails returning   VI_ERROR_RSRC_NFOUND.  ( see attached spy log).

The failure shows up with two hardware setups (using other cables, instruments and another  GPIB-USB-HS ). One of these setups is known to work with the DELL PC. So I think, I can exclude hardware problems on the instrument side. And replacing the NI USB-GPIB and NI 488.2 with a CEC USB-GPIB and their 488.2 drivers also makes the programm running.   So there seems to be a subtle problem with the GPIB-USB-HS and/or the NI 488.2 on that PC. But how to debug that futher to decide if that is a hardware problem or a software installation flaw ?

[Ken_Tobler]

Hello

From the NI-SPY document it seams that the multimeter Agilent 34401 can be accessed but not the Agilent 6032A.
Check the configuration of the GPIB communication (EOI, EOS,..) and check if the settings are correct for the 6032A.

Try also to insert in TestStand a Sleep time before opening the communication with the Agilent 6032A.

Best regards
Ken

[markus kossmann]

I've checked the EOI and EOS settings and they are right. The communication in MAX  with the 6032A works with the same settings. Before and after the program fails.

And adding delays probably doesn't  help too. The other PC (from DELL)  ,where the program runs,   is the faster machine.  As you see the delay between the last viWrite on the 34401 an the failing viOpen on the 6032 is 32 ms.  If I check a Spy log from the DELL there are only 15 ms between these two calls and it works. But there is one significant difference between these two calls: The failing viOpen returns after 0 ms, whereas the working viOpen on the DELL claims to have used 16 ms. And using the CEC adapter the program also works without changing the timing.

And were are using the probably well tested Labwindows/CVI driver from IDN to access the 6032A.   

[Steven_T]

Markus, 

I did some quick tests and I found out that using ViOpen on the string "GPIB:: 5::INSTR" (as the spy capture shows) also results in a resource not found error with NI-VISA.  After looking at your string, I found two problems that could potentially break the communication. 

First, if you have multiple GPIB interfaces on your system, you need to specify which one with an interface number (use GPIB0 or GPIB1).  You can find this number in MAX. 

Second, your string shows ":: 5" or "::\s5".  There is a space between the second colon and the primary address 5.  Placing a space in this position also gave me the resource not found error.

Please let us know if this does not help.
Steven T. 

[glp]

I am facing a similar problem in communicatig with my scope.  I could able to query the scope successfully through NI488.2 communicator. But when  I try to open a NI session from Visaic.exe, it is throwing the VI_ERROR_RSRC_NFOUND error. 

How should I debug this?  I will highly appreciate your help.

The previous solutions for similar errors did'nt help me.

[markus kossmann]

Start NI Spy before running Visaic.exe and show us the log from Spy. And for comparison do the same thing when using  the NI488.2 communicator.  In my case it was the space in the ressource ID. Older versions of VISA ignored that but current versions throw an error on that.