From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Keithley 2601 - VISA READ 0xBFFF0015 (VI_ERROR_TMO)

Solved!
Go to solution

Dear people,

 

I hope you can help me with this problem that have been haunting me for days. Please excuse me if it is some rookie mistake, as I have zero experience with LabVIEW.

 

I'm trying to control a Keithley 2601 using the LabVIEW drivers provided by the manufacturer (http://www.tek.com/source-measure-units/2635-software/keithley-series-2600-2600a-2600b-native-labvie...).

The connector I'm using is a NI GPIB/USB and the communication seems to work fine with the NI-VISA Interactive Control, writing and reading the output of "*IDN?\n" flawlessly:

 

1: Write Operation (*IDN?\n)

Return Count: 6 bytes

2: Read Operation
Return Count: 54 bytes
Keithley\sInstruments\sInc.,\sModel\s2601,\s1078308,\s1.1.1\n

When trying to run the provided example "KE26XX Factory Pulse Usage.vi"  however, after succesfully initializing the device and writing a series of parameters, it always shows error 0xBFFF0015 (VI_ERROR_TMO) at the VISA READ in "Config Pulse V Measure I.vi":

 

error.jpg

 

I had that previously with a serial cable, so I changed to the GPIB/USB thinking it would overcome an eventual TermChar problem. Didn't work, the error is still the same. I've tried adding a Wait function with up to 5s after the VISA WRITE, no success. Tried increasing the byte count for the VISA READ, no success. Tried manually adding "\n" to the write string, no success.

 

Using Windows 7 Enterprise, LabVIEW 2014 SP1 f3, NI-VISA 15.5, NI-488.2 15.5.

Thanks in advance for any kind of help!

 

Diego

 

0 Kudos
Message 1 of 4
(5,035 Views)

Two common causes for such issues are VISA timeouts and also when you send the commands that are not available in a certain mode of operation for an instrument. Assuming this is a mere VISA timeout, let’s increase the timeout value before looking for other possibilities. In order to do that, wire the VISA reference into a Property Node and set the timeout to write. Then wire in a timeout value that based on your knowledge of the operations is longer than the time needed to carry it. For example if the operation should normally take 5 seconds, you can wire in 10,000ms. I have attached a sample VI to do this.

Certified LabVIEW Architect (CLA), LabVIEW 2015.
0 Kudos
Message 2 of 4
(5,024 Views)

Thanks Andreas,

But still, I have set it up to 60 seconds (much more than it should take) and still get the same error.

0 Kudos
Message 3 of 4
(5,008 Views)
Solution
Accepted by dgrbsgms

So it looks like, this is caused by something else. The other cause of VISA timeout for test equipment is usuaully when you call a VI to do certain things that need more steps to be taken before calling them. For example, you might need to call another Keithly VI to initialize the device, then put it into a certain mode, configure something using another VI and then call this subVI. If you don't follow such a sequence, you may request something that the instrument is not able to do and therefore it wont reply back and will trigger a timeout. For that you'll need to visit the instrument manual, Keithly's examples or try contacting their support.  

Certified LabVIEW Architect (CLA), LabVIEW 2015.
Message 4 of 4
(5,005 Views)