Call to viFindRsrc returns invalid addresses

[E. Van Dyke]

We have a system which is running three GPIB busses. Most of the time, a call to viFindRsrc to find all GPIB devices returns the set of installed devices. However, occasionally, it returns the set of all possible devices for GPIB0 only(GPIB cards 1 and 2 appear normal). So we get a set of addresses like:
GPIB0::1::INSTR
GPIB0::2::INSTR
GPIB0::3::INSTR
...
GPIB0::30::INSTR.

It does /NOT/ return a set of instruments with secondary addresses(5::0 through 5::7) however. We have yet to be able to force this behavior to occur, but usually once it has occured, it will continue until the PC has been rebooted. Obviously, the enumeration of devices of GPIB0 is incorrect... but we are at a loss of how to prevent
the error.

[ScottieB]

Hello,

You didn't specify what version of NI-VISA you were using, so I wanted to make sure that you were using the latest from our website 3.0.1 from here: http://digital.ni.com/softlib.nsf/webcategories/85256410006C055586256BBB002C0E91?OpenDocument&node=132060_US

Also, if you are using a National Instruments 488.2 card, please install the latest version of 488.2, version 2.1, from www.ni.com/support/gpib/versions.htm

I'd like to know exactly what your query string is for FindRsrc. What does Measurement and Automation explorer see as valid instruments on GPIB0 when you get this to occur? Are you using any other GPIB/HPIB cards in your system? Do you have any Passports enabled in Measurement and Automation?

Further, it would be helpful if you could
get it to the point where you can force this to occur, but I understand that could be difficult, so we'll work with what we've got.

Thanks,
Scott B.
Applications Engineer
National Instruments

[E. Van Dyke]

My appologies for not specifying those...

We are running:
NI-VISA: 3.0.1
NI488.2: 2.1
MAX: 3.0.1.3005

It would be nice if we could force this... be halfway to fixing it. But as it is. Our query string is:
GPIB?*INSTR

This is actually the third query we run. First we query for all VXI instruments(VXI?*INSTR), then all ASRL instruments(ASRL?*INSTR), then all GPIB(GPIB?*INSTR) we havn't had a problem with anything other than GPIB0.

The passports we are running are the default set:
NiVi488.dll
NiViAsrl.dll
NiViEnet.dll
NiViEnetAsrl.dll
NiViGpvx.dll
NiViPxi.dll
NiViUsb.dll
NiViUsb
NiViVVGL.dll
NiViVxi.dll

all show versions 3.0.1.8 MAX also shows a dependency on NIVisaServer.exe(3.0.0.33).

T
he only thing different about GPIB0 than GPIB1 and GPIB2 for these systems(6 of them) is that GPIB0 has a GPIB-140A fiber GPIB link on it.

--Evan

[ScottieB]

Evan,

Interesting. When you say "6 of them", do you mean that you have 6 independent systems having this same problem?

I would like to eliminate thet GPIB-140A as a possible cause of this problem; would it be possible to temporarily run the program or test without the 140A on the bus?

Next, I'll need an NI-Spy capture, ideally with one viFindRsrc returning proper values and then one giving all values. When you do a Spy capture, be sure to select "Spy...Options...Log to File" and then send me the resulting .SPY file. You'll definitely have to try this a few times until it actually fails.

This information should be pretty helpful. I can't think of anything in the GPIB-140A that would cause this, but since it's the only difference be
tween GPIB0 and your other interfaces, we should start by eliminating it.

Scott B.
Applications Engineer
National Instruments

[E. Van Dyke]

6 independant systems is, indeed correct.

After more investigation it appears that the GPIB-140A is a definate factor in this problem. Cycling power on one of the GPIB-140A boxes seems to be guaranteed to produce this issue, although it has appeared without power cycling as well.

I have attached the .spy file... but not sure if it's very helpful. Just shows the viFindRsrc call returning many GPIB instruments.

After a little playing with the GPIB API, it /APPEARS/ that calling SendIFC() on GPIB0 before the viFindRsrc call releives the symptom. While this does appear to work around the problem, it would be nice to be able to discover(and resolve) the root cause.

[ScottieB]

Hello again.

Could you expound a bit more on your investigation that lead you to the conclusion that the GPIB-140A is definitely the problem?

Also, when you did your Spy capture, did you save it to file after the capture was done, or did you do the "log to file..." setting in the Spy...Options box before starting the log? The reason I ask is that the latter method will give me more debugging information, and I was unable to pull up that information in the capture that you posted.

What about the setting on your GPIB-140A for "buffered" operation? (See the 140A manual for more information, it's basically a dip switch on the side of the boxes) Are you doing buffered or unbuffered operation? Set it to unbuffered and see
if you still have the problem.

Scott B.
Applications Engineer
National Instruments

[E. Van Dyke]

Well, the most reliable means of causing the problem was to cycle power on one(or both) of the GPIB-140As. We have as yet been unable to reliably reproduce the issue in another manner.

Have tried all combinations of the GPIB-140A settings(Buffer on/off, parallel poll On/Off, and whatever the 3rd was). ONly 8 of them, so that wasn't much of a hassle. But the settings seemed not to make a difference.

I'll try the "Log to file" setting as soon as I can get time on one of the systems.