GPIB crashing when running labview

[lowtemp]

I'm running labview 8.6 on windows 7 with a GPIB-USB-HS which is connected to an HP 34401A multimeter. This setup is used to record pressure readings. Lately I've been having a problem where labview will suddenly freeze and stop taking pressure values. This crash happens randomly and without warning. It may be triggered by the pressure values changing very rapidly but I'm not sure. I initially suspected the computer, the drivers, or the multimeter but I have since ruled those sources out. My only conclusion now is that the GPIB is failing in some way. Is there anyway I can diagnosis the GPIB or rectify this problem? 

[SnowMule]

I'd recommend dumping the USB-GPIB adapter and using either a PCI GPIB card, or communicating with the instrument via serial. 

My guess is the drivers you're using for your USB-GPIB adapter aren't playing nice with Win7.  Honestly, I haven't found a USB-GPIB adapter I like yet.... the PCI ones work well ($$), and serial is slow but works a lot more reliably.

[gpibtester]

Hi,

If you installed GPIB at the time you installed LabVIEW 8.6, it would have installed NI-488.2 for Windows, Version 2.6. However, support for Windows 7 was not added until Version 2.7.2. If you have an unsupported version of GPIB on your Windows 7 system, you need to uninstall it first. Here is a snippet from the Readme.txt file that explains how to do that.

Unsupported NI-488.2 Versions on Windows 7

NI-488.2 for Windows, Version 2.7.2, was the first version to support Windows 7. If you installed a version of NI-488.2 lower than Version 2.7.2 on Windows 7, you must uninstall it. To uninstall on Windows 7, go to the Control Panel and select Uninstall a Program.

Once you have uninstalled the previous version and restarted your system, you can then upgrade to the latest driver, which is available here:

NI-488.2 3.0.2

Hope this information helps.

gpibtester

[JasonSmith]

If you can reliably reproduce the issue, you could run the application with NI-I/O Trace (formerly NI-Spy) running. This should let you see whether it is stuck in one of the GPIB calls when LabVIEW hangs. Jason S.

[lowtemp]

So I ran the NI I/O trace as suggested and eventually the following error popped up.

> 2788. GPIB Wait (19, 4294967295, 37236)
> Process ID: 0x0000029C Thread ID: 0x00000238
> Start Time: 09:49:09.947 Call Duration 00:00:00.799
> Status: 28 (0x1C) 

As I suspected this address indicates that my pressure sensor is causing the problem. Does anyone know what status 28 means?

[Albert.Geven]

The status is a byte that is defined by your instrument but probably bit 5 signals a srq and that should make it above 28. so try to find a definition in your instrument.

[JasonSmith]

Actually in this case Status refers to the status value that is returned from the GPIB Wait function.

Do you have the .spy file available that could be posted, so that we could open it in NI I/O Trace for viewing?

-Jason S.

[lowtemp]

So I've attached the .txt file for a similar crash. The default for my version of NI trace was a .nitrace file the posting of which this forum did not support. The program I'm running does not seem to contain GPIB write but rather is utilizing Wait for GPIB RQS. 

[JasonSmith]

I think you forgot to include the attachment. Will the forum let you post the iotrace file if you put it in a zip file first?

[lowtemp · Accepted solution]

It looks like our problem was that we had a bad connection with our gpib cable, causing labview to time out waiting to talk to the instrument it was connected to. We swapped out the bad cable and no more crashing.  Thanks!