How do I interface with a Keithley 2000 multimeter using LabVIEW

[djconfused]

Thats what I figured was the problem, but there is no time out component of the Read Single vi.  Is there anything else you think could be causing the hang up?

[Chad B]

Performance of external hardware during Highlight Execution mode is unpredictable at best.  The delays between VI calls often cause timeouts and other erratic behavior.  Is your application working as you'd like it to when it's run normally?

[djconfused]

After doing some experimentation with the program lately, I think I have made some discoveries that may help figure out what is wrong.  I have created a sub vi for measuring a channel of the Keithley 2000 multimeter once.  This vi is based off of the example Single Read vi that Keithley provided with the driver for the multi-meter.  When this vi has a Initialize.vi and a Close.vi at the begining and end of the program (respectively) it runs fine, without any problems.  Without these two vi's (or maybe just one of the two?) the program will hang, and following the hanging portions of the vi, I found that the apparent culprit is the VISA Write step.

Now since my overall program will take a number of measurements, I have noticed that the first measurement with my Single Read vi goes off without a problem.  It is the second one that always hangs.  To get the program to take a single measurement again, LabVIEW has to be closed and reopened.  What do you think?  Is this a problem with Initializing the vi?  Maybe closing?

Either way, I would like a solution because the faster the program runs the better.  If I need to use the Initalize and Close for every single measurement I take, I imagine it will bog down the program and make it quite a bit slower.  Also, I have heard that Initalizing a piece of hardware over and over in a program can cause the program to crash.  Know anything about that?

Thanks for your help.

[Chad B · Accepted solution]

Think of a "VISA Session" as a phone call.  The "initialize" part is where you "dial the number" of the instrument you want to talk to by configuring the port with a baud rate, termination character, and so on.  The "Write" and "Read" functions are where you talk and listen, respectively.  The "close" function hangs up the phone.

So if you are initializing and closing the VISA session every time you call a SubVI, it's like picking up the phone, dialing your friend, saying "Hello," then hanging up the phone.  You then pick up the phone again, dial your friend again, say "How's it going?", and hang up the phone, and so on, and so on.  You'll see much slower performance if you do it this way.

On the other hand, if you don't close the VISA session when your program is done, it's like saying "Goodbye" to your friend but not hanging up the phone.  When you run your program again and try to open another VISA session to the port, you'll get the same result as trying to dial that phone again--it won't work.

That might explain why the communication works once but not twice--if your VISA session isn't being closed properly, you won't be able to open another one.  So just make sure that you're closing your VISA session somewhere at the end of your program.

If you think that might be the cause of the problem, here's a way to test that: After your program crashes such that you can't communicate with your instrument again, open a blank VI.  Drop a "VISA Close" VI on it and wire a VISA Resource Constant to the input with the port you're using.  Run that VI, then try your original program again.  If you get data then, it's a VISA session problem.

[djconfused]

Chad,

You are totally right.  A co-worker and I just found out the same thing.  After agreeing that it would be better to have a single initialize and close, we worked pretty much through a trial and error method to find out what would work and what would not.  We found out that if the keithley program is aborted in the middle of a program without undergoing the close function, it will pause on the the single data read vi until LabVIEW is closed and reopened.  Strangely, the keithley DMM did not need to be power cycled.

We eventually decided that the best way to get around this error was to have the close vi at the beginning of the program prior to the initialize vi.  This way, if the program was aborted it could still be run later because the first thing the program will do is close the keithley DMM.  Now, while watching this program run with a close vi at the beginning I noticed that if the program runs uninterrupted, the second time through an error will crop up.  Nothing fatal, it does not shut down the program or even show up with a simple error handler, but I think it comes from trying to close a device that was closed in the first place.  Not really sure though.

Once this program is finished and packaged as an executable, the close vi at the beginning will be removed, but it is pretty necessary presently for debugging and testing purposes.

I think thats it, thanks for the help.

[Chris_R.]

Hi djconfused,

Thanks for the detailed update. We are glad things are working for you! 

Best of luck with the rest of the application development!

[leandrodzc]

Good morning everybody

I am new in this forum and in Lab view and my task is to do an interface with this port.

After read lots of messages here, I remember that I installed NI 488,2 driver and It didnt work. So,  I uninstall-ed NI488,2 and then Installed keithley driver(It is not possible to have both because they are conflictant) and installed another drive That a I have found in this forum(keithley 2000).

I made the device communicate with the Labview but I dont know what happened that in the next day that anything was working!

I am afraid that some actualization was installed when I restart the computer.

so, I will put in order every thing:

-installed all Lab view and drivers (including ni488,2)

-uninstalled ni driver and installed keithey interface to test the port comunication(that send me an asnwer of the device that can communicate with the port)

-installed labview-keithley driver for keithley 2000 multimeter, found on the forum´s topics.

-opened the single measure Vi example and it worked!

Next day:

-I installed other drivers for the other device I  need to comunicate, the keithley 7002,and my programm stopped to comunicate or find gpib 11( the address of gpib)

-so, Unistalled these programs and It Worked again.

-I turned on my computer next day and It wasn't working again! it was unable to find the gpib correct address. I notice that in the max, the gpib changed automatically the address of the device to 10 (but the day earlier, was 11, the correct one and working) 

-things tried: reinstall all drivers, delete all new programs I installed, turn firewall off.

I tried to configure another gpib but are so much addresses and I don´t know what to put in the fields.There isn't other way to detect automatically?

(F5 only dosnt work).  I didnt need to configure in the first time.

thank you very much

Leandro V. Zaccarias

[EricS.]

Hi Leandro,

If you are using an NI GPIB card in your computer, you will need the NI-488.2 drivers installed.

In addition, to communicate with the Keithley 2000 multimeter, it is easiest to use the drivers that Dennis linked here.  You will install NI-488.2 first, and then the Keithley driver.

After doing so, there should be examples in the Keithley driver folder on your computer, and an additional LabVIEW Pallet for the Keithley 2000.

You should also be able to have drivers for the 7002 installed at the same time without a problem, but know that that driver is not supported or certified by NI.