How do I interface with a Keithley 2000 multimeter using LabVIEW

[djconfused]

I am having trouble getting Labview to communicate with my Keithley 2000 multimeter.  Keep getting error: "Error Hex 0xBFFF0012 Invalid resource reference specified. Parsing error. "  Not quite sure what that means.  Still very new to LabView, so if you can help, assume I dont know anything about it.  Thanks.

[Dennis_Knutson]

Are you using this driver for programming the meter? If so, do you have a serial or GPIB connection. What have you selected for the VISA Resource Name? You need to select the correct resource. If you have a GPIB connection, you should have done a scan for instruments in MAX (Measurement & Automation Explorer) and had it detected. Then, you can right click on the arrow on the right side of the VISA Resource Name control and get a list of available resources. Your GPIB connection should be shown as well as any com ports in your system.

[djconfused]

The driver I am using I downloaded through LabVIEW by going to HELP > FIND INSTRUMENT DRIVERS , selecting Keithley from the drop down box for manufacturers and typing 2000 in the additional keywords box.  I then picked the driver for labview 8.0 rated with 3.03 stars.  I am using a GPIB connection to communicate with the multimeter.  I have not selected a VISA resource name, how is that done?  Is that when you use MAX?

Sorry for the lack of knowledge, when using an agilent power supply in the past, it was just a matter of downloading the instrument driver in the same way as above (from the help menu > find instrument drivers) and then using the vi's that were included.

I downloaded the file your hyperlink pointed to, but am not quite sure where is should go to function properly with labview.  I will work on using the current driver I have for Keithley, going through MAX and assign a VISA resource name.  I will update you as soon as I know more.  Thanks for all your help so far.

[Dennis_Knutson]

In MAX, you right click on the GPIB interface and select Scan for Instruments. This will find all of the GPIB instruments. The VISA resource name is based on the GPIB address. For example, if the instrument is at address 12, the VISA Resource Name is GPIB0::12::INSTR. If you downloaded a driver before and it worked without you doing anything, then you got lucky because the default VISA Resource Name in the driver was the same as the actual instrument's. An instrument will usually have a default address set at the factory and the author of a driver will usually set the resource name to be the same.

[djconfused]

Thanks Dennis, going through MAX helped me to figure out what was wrong with my address call out.  Apparently I did not include a INSTR at the end of GPIB::16::INSTR VISA input.  Now I have another problem, so if you can help me even more, I would appreciate it.

A sub vi that Keithley has provided called ke2000 Data Read Single that is contained in a while loop will run only 5 times before hanging up.  Investigating further, inside this vi, a vi that appears to be the SQL communication vi for the keithley is the culprit.  One layer deeper, and it appears that the VISA Write vi is where the program stops.  I have tried giving the ke2000 Data Read Single a timeout constant of 100ms, but it still pauses on this step indefinitely.  Any ideas?

Once this works, I desire to read data from multiplie channels on the Keithley.  I have not yet seen any way to measure multiplie channels, do you know how that is done?

Thanks again for all the help.

[Dennis_Knutson]

It's not SQL but SRQ. SRQ is a service request. The instrument will issue a service request when a reading is available. Do you have anything else in the loop? How do you have the trigger configured? If you look at the Keithley 2000 Read single Example, if sets the instrument up for bus triggering and then the bus trigger command has to be issued. If you don't want to issue a bus trigger, I believe you can set it up for immediate and then each time you call the read, it will return a value. I don't have the manual to confirm that though.

I don't know of an example for multiple channels. The Configure Scan function will allow you to set the start and stop channels. When the scan is complete, you would call the Data Read Multiple.

[djconfused]

You are right with the SRQ vi.  My mistake.  I have a couple of other things in the loop, mostly taken from the Read Single example Keithley vi.  The program is still pretty rough, and I was just trying to get a feel for what can and cannot be done, but I will attach it to make things a little clearer.  After quite a bit of changes, I am still having the problem with the Read Single vi working for the first few times then pausing indefinitely (I think).  The only way to get the Read Single to work again is to exit LabVIEW completely and open the program again.

Thanks for the help.

Message Edited by djconfused on 08-14-2007 04:15 PM

[Chad B]

There are actually a few different drivers for the Keithley available at our driver site, http://ni.com/idnet .  When I searched for the Keithley 2000, I found a LabVIEW Plug-and-play driver as well as an IVI driver.  Which one are you using, and have you tried the other one?

[djconfused]

Chad,

I am not sure which one was downloaded, I just used the Look for Drivers option in LabVIEW and downloaded the highest rated driver for labview 8.0.  A quick update on my program:  It seems that the problem with the Read Single hanging up the rest of the program is due in some way to the Highlight Execution option in LabVIEW.  I noticed that if the Read Single vi was in a while loop and the Highlight Execution option was turned on, the Read Single would pause after three or four sucessful executions (on first opening LabVIEW.  For Read Single vi to run sucessfully again LabVIEW needed to be closed and re-opened.) would pause.  Turning off the Highlight Execution option and placing an indicator that would display updates everytime the while loop executed showed that the Read Single vi would keep operating hundreds of times without problems.  I am not sure what caused this, do you think it could be something with the Keithley driver?

Thanks.

[Chad B]

That might have to do with the time between your trigger and your read.  Does the device have some sort of timeout for reading data after a trigger?