VISA Read hangs. Get Resetting VI dialog on abort.

[George_G]

Windows 7 SP1 64-bit

LabVIEW version 2011 SP1 32-bit

VISA version 5.1

NI-488.2 version 2.80

When trying to communicate with a GPIB instrument (currently a Keithley 2400 source meter), occasionally the VISA Read VI will hang and never return.  (Timeout value is set to 10 seconds).  Once this happens the VI calling VISA Read ignores the abort button in the toolbar.  Closing the front panel of this VI results in the Resetting VI: "Calling VI's name" dialog.

Does anyone know what causes this or how to avoid it?

[yytseng]

May the "IO Monitor" log can help to analysis.

[George_G]

Where can I find the IO Monitor log?

[Jeff.St]

Hi George,

Does the VISA Read always hang after the same command?  Does it work sometimes after this command?  What is the command that you send to the Keithley before reading?

[tkott]

I have the same problem with VISA Read (with a 1/2 second timeout) going to different instruments (I've seen it happen with a Keithley 2400 as the OP, but also SRS 830 Lock-in, and an SRS SIM module setup), and hanging both the VISA read and the UI.

EDIT: Added:

Windows 7 SP1 64-bit

LabVIEW version 9.0f3 (2009)

VISA Versions: 5.0

Ni-488.2 Version: 2.73

One thing that might be tripping things up is the inclusion of an IOTech Extender488/F bus extender/isolator, which uses a fiber optic cable to span a distance and provide some separation between computer ground and instrumentation.

Because of some debugging I was doing, I left NI Spy open, and have the following results from the last calls:

1. 19859184.  viParseRsrc (0x0C818D20, "GPIB0::23::INSTR", 1, 0), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.027       Call Duration 00:00:00.001,Status: 0 (VI_SUCCESS)
2. 19859185.  VISA Open ("GPIB0::23::INSTR", True, 0, 0, "GPIB0::23::INSTR"), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.028       Call Duration 00:00:00.038, Status: 0 (VI_SUCCESS)
3. 19859186.  VISA Lock ("GPIB0::23::INSTR", 0, 1), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.066       Call Duration 00:00:00.000, Status: 0 (VI_SUCCESS)
4. 19859187.  VISA Set Attribute ("GPIB0::23::INSTR", 0x3FFF001A, 500), Process ID: 0x00001414         Thread ID: 0x00001600
   Start Time: 10:48:45.066       Call Duration 00:00:00.019, Status: 0 (VI_SUCCESS)
5. 19859188.  VISA Unlock ("GPIB0::23::INSTR"), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.085       Call Duration 00:00:00.010, Status: 0 (VI_SUCCESS)
6. 19859189.  VISA Lock ("GPIB0::23::INSTR", 0, 1), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.095       Call Duration 00:00:00.010, Status: 0 (VI_SUCCESS)
7. 19859190.  VISA Write ("GPIB0::23::INSTR", "*idn?"), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.105       Call Duration 00:00:00.018, Status: 0 (VI_SUCCESS)
8. 19859191.  VISA Read ("GPIB0::23::INSTR", 100), Process ID: 0x00001414         Thread ID: 0x00001600, Start Time: 10:48:45.123

You'll notice that it crashes on "*idn?". I'm pretty sure that in the past, it has crashed on other commands as well, and is not reproducible (for example, I ran visa read/writes to the SRS lockin every 200ms or so for the past 12 hours with no problems, with at least 60+ calls (including *idn?, which is part of a class constructor) to the Keithley. 

I am happy with a solution which kills that read command, and simply issues an error -- I can handle those. But it is frustrating that I cannot trust that the VISA read will either work or throw an error that I can catch.

Any help or guidance in diagnosing this would be appreciated. Please let me know if I have missed reporting on something...

Thanks,

Tomek

[tkott]

I also updated to the latest VISA and GPIB drivers available from National Instruments, and the same problems still occurs. Happened on the Keithley with an "*idn?" call again.

Tomek

[MilanR]

Hi tkott,

So even with a timeout configured for the VISA read command the function locks and does not complete? Does waiting beyond the time of the timeout cause the function to return with an error code? What Serial hardware are you using for the communication?

In addition, when the read occurs and the software is locked, what is the status of the instrument?

[tkott]

Hi Milan,

Yes, I configure the VISA session to have a default 500 ms timeout (you can see it in the trace in my previous post as the SetAttribute call). Even with that set, the VISA read command does not complete. Because I tend to run the programs overnight, there was an instance where the vi was stuck on the read function for over eight hours. There is no error code return, and pressing the manual "abort" button fails to stop the vi. I have to kill labview manually using the program manager to get back to a usable state.

I'm using GPIB hardware (not serial) from national instruments (I don't have the exact model on me at the moment) along with an IOTech 488.2/F extender. Are you looking for anything specific? I'll be able to check tomorrow.

As for the status of the instrument, I don't remember seeing anything odd. The keithley shows a "rem" signal on the front panel, and and locks the display. It was like this when I saw this happen last. Do you have anything in mind to look for?

Thanks,

Tomek

[George_G]

Hi Milan

I haven't had a change to try to get the error to reproduce consistently, although I do still get the resetting VI message intermittently.  I was wondering if we could approach this from the other direction as well.  Are there places inside the VISA (NI488) Read source code that could become infinite loops in the right conditions?  Are there deadlock states where the VISA is waiting for the instrument to set one of the GPIB lines and if it does not the VISA will never return?

---------------------------------------

Hi Tomek

The next time your program hangs (but before you get the resetting dialog) can you try power cycling the 2400.  I am imaging the VISA driver is stuck in a dll waiting for an event that is never going to happen.  So I am trying to find a way to get it "unstuck", figuring that might help the folks at NI know where to look in the VISA (or NI488) driver.

George

[Axlon]

I have a similar problem.
Has two paralle loops, where one makes a VISA connection to COM1 port, and another for an instrument that does not exist on LAN.

Both have an open timeout on 10ms, but the TCPIP loop get both loops to hangs.