02-24-2010 01:38 PM
I'm not quite sure how to change the 'MEASUREMENT' command into ´'CONFIGURE' and 'READ' commands but I assume that's what I had in the attached program, right?
Also, if I lower the 'Max time' there is no improvement on reading rate. Too low value of 'max time' simply results in fast rate but no readings at all.
02-25-2010 11:30 AM
I found another severe problem in the .vi program: it's not reading the actual current signal from the KE6485 picoameter. It connects with the instrument (I can hear the click) and then read some randomly low current signals (a few nA), even when actual current is as high as 3 mA.
I tried to change Fetch function to Read, and still same problem. What could have been wrong?
thanks for any help!
02-25-2010 01:12 PM
this problem was solved.
turns out the 'zero check' needs to be disabled in the vi file.
06-14-2010 04:56 AM
Hi Rodmanhurst,
Did you manage to find a way of speeding up the readings at all? I'm facing the same problem! I guess all the previous suggestions didn't speed up the reading enough? I've also noticed that by using just the front panel with no remote control the readings speed up significantly. So yes, it would be good to know where the bottleneck is!
06-14-2010 02:53 PM
JKLH:
no I didn't find a way. max frequency I managed was only 2HZ and I sorta had to live with it.
but post it here if you can find a solution, that'll be a great help to many others!
07-26-2010 11:15 AM
Hi all, I'm doing some automated low-current measurements and I may have some useful information for people in this thread. I don't have 6485, but higher model 6487 picoammeter, though.
At any rate, 6487 has internal buffer, which can store several hundreds measured values. It can be programed to do repeated measurements at certain time intervals and store the results in this buffer. Needless to say, access to the buffer is much faster than RS232 or GPIB. In the 6487 LabView driver, there are "multipoint" functions, which can set up these repeated measurements and then read the entire buffer at once.
And now about measurement speed: according to the 6487 manual, the instrument can take up to 1000 readings/second. However, such acquisition speed is possible only with low accuracy (resolution), with line filters turned off etc. In the default state, the 6487 has almost all these features turned on and set to achiveve high accuracy. But by turning them down, you can beef up acquisition speed. These things can be changed remotely, too. Of course, you will have to find some compromise between speed and accuracy, as needed in your applications.
Hope this helps.
05-16-2011 08:19 AM
Hello,
I´m also new in the use of LabVIEW and I´ve got the same problems as the previous speakers. Besides I had already called Keithley and told them the problem. They already have advised me to use the internal buffer to get faster measurements. But I´m not sure how to use the special "buffer VI´s" (see the attached files below) to get a accurate measurement. In my file the "Fetch Buffer Data.vi" throws an error message "invalid value for parameter or property" and the circuit broke down. Is it possible to post an example, in which the measurement with the internal buffer is shown?
Thanks in advance
SeBaK
05-18-2011 10:11 PM
I have been trying to find some documentation for you. As you may know this driver is not actually built or supported by NI. The Keithley 6485 Labview driver is actually developed by Keithley. I found some example programs, and manuals here. Hopefully, you find them helpful, I don't have the hardware to test anything out.
11-16-2011 11:38 AM
Hello,
I hope these help.
The first is a 2000 buffer read of 1000 Current Read and 1000 Time stamp.
The second vi is just a 1000 Current Read buffer.
Did these help?
Y.
03-01-2012 12:54 PM
Hello, I have same problem, readinsfg rate is about 1 reading per 0.4-0.5 sec. I thought the problem lies in the speed of the rsr-232 interface. But when I'm trying change rate from 9600b to greater values, ammeter always freezes. Anyone encountered this problem? Maybe some special combination of parity, stop-bits, flow control? And, in general, will increasing interface speed cause increasing reading rate?