LabView<->GPIB: device at the address #1

[djadjok]

I'm not sure, but It looks like a bug in LabView or Labview<->GPIB interaction... Don't know if it was reported earlier - anywhere I haven't found it...
Ok, here is the situation:
LabView reports error 26, "window.cpp" line 10028 while placing a standart "Visa resource name" control (or its older versions) on the front panel IF there is a powered on device with address 1 on GPIB bus.


Platform: PC
Windows 2K Prof (French) or 2K ADS (US)
LabView 6.02 (French)
NI PCI GPIB controller

any GPIB device at address 1 in powered on state (I tryed with SRS SR400 and TRIAX monochromater)

Conditions:
Ok, I launch LabView and want to create a new VI. There is a GPIB device (powered on) on address 1 attached to my NI GPIB
conftroller. If in this condition I'll try to place visa control on the front panel of my VI, labview hang for some time and then report error 26 as described above.
If I'll try to open a front panel of any previosly created VI with those controls the situation looks similar - LabView doesn't hangs, but reports somemething like "Labview did not find some... etc".
I both cases GPIB controller trys to interact with device #1 on the bus (hmm.. why? looks like it trys to send something like "*inf" command, but I don't ask for this)
More: If I'll use any of those VI's as subroitines for some higher-level VI (i.e. frot panels with VISA controls remains closed) all works fine...

SOLUTION:
Changing address of GPIB device to any other value except 1 removes this problem...
Very simple solution, but, anywhere, It seems to me that it doesn't look like a "normal operation" of the software...

A.Philippov

[JRA]

This is might strange behavior you're seeing! Unfortunately (or maybe good for me) I haven't been able to reproduce this. I am running Windows 2000 (English). I used an NI Instrument Simulator set to PAD 1 and I'm using an NI PCI-GPIB card. The instrument was turned on and I placed the VISA resource name on the front panel of a new VI and it worked just fine.

I tried this with both LabVIEW 6.0.2 and LabVIEW 6.1 and both worked fine. I also, just to check, place the VISA resource name for my GPIB instrument (at address 1) in the control and still nothing happened out of the oridinary.

You may want to try reinstalling VISA or, if that doesn't work, try reinstalling LabVIEW (though that's not a pretty option). Does anyone else have any ideas for defuflo
?

[crelf]

JRA - whya haven't you applied to become an "Enthusiast" yet? I've always found your posts inciteful, and believe that you well deserve the profile...

[djadjok]

Thanks for your advices!

I've made a little bit deeper investigation of this problem and I must admit, that error repots appear only (and not always) if GPIB device at PAD 1 is not FULLY IEEE488.2 compliant, i.e doesn't support high-level command protocol (such as "?*INSTR" command, etc)...
Anywhere, the problem rests... To make it evident, one can launch GPIB Spy before launching labview, then start labview, create new VI and place a ViSA resource name control on the front panel... In the we'll see that GPIB sends "?*INSTR" command to the device at PAD1. Voila!
If device is compliant with high-level command protocol (I've tested this with Tektrobix TDS220, and I'm sure your NI Instrument simulater is also from that case) all looks fine... If not
- labview hang for approx. 30 seconds (GPIB timeouts) and sometime terminates with an error (I'll attach spy log file as an example to this message)...

BUT, anywere, I must classify this kind of behavior as a bug. May be I'm not right, but, IMHO, here we have the case when software tries to communicate with peripherals without permission (a bit unpredictable, eh? ok, I'm not plan to use it in conjunction with nuclear reactor, but... 😃 ), and thats isn't normal as I think.
(As a remark: I'm using now about 10 different GPIB devices in my work, and none of them are compatible with high-level command protocol)

[Les Hammer]

crelf wrote in message news:<50650000000500000061A80000-1031838699000@exchange.ni.com>...
> JRA - whya haven't you applied to become an "Enthusiast" yet? I've
> always found your posts inciteful, and believe that you well deserve
> the profile...

I hope you mean insightful. If JRA is really inciteful he would be
causing trouble.

Les

[crelf]

Ha - absolutely! Thanks for picking that up! 🙂

[Dan_Mondrik]

There are really 2 different things going on here, and only 1 of them is a bug.

When you drop the VISA refnum, LabVIEW calls the VISA driver and asks it to find all resources it knows about (viFindRsrc), so that it can populate the control contents. NI-VISA tries to detect GPIB-VXI controllers, which by default we ship at primary address 1. The string with which LabVIEW calls VISA is "?*INSTR", but the GPIB command sent to primary address 1 is "*IDN?". This is intended behavior.

The bug in NI-VISA 2.x is that your instrument probably did respond, but with a response greater than 100 characters. This overwrote an internal buffer. This has been fixed for the next version.

Workarounds? Well, you figured out the first one, which is to change the pri
mary address. Another workaround is to use the VISA configuration utility (MAX on Win32) to either disable the GPIB-VXI Passport, or to disable auto-finding of GPIB-VXI controllers by automatically probing primary address 1. I think you will find the last option the most to your liking.

Good luck,
Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

[djadjok]

Thanks a lot for the information,
Finaly I have the answer from NI.
I'll try your advices.
I was really upset when I first discover such a strange behavior of my program after 4 years of development - as this was the first time I use a device with default settings to PAD#1....