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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

speeding the Keithley 6485 readings with LabView

Hi All,

I'm new with LabView and with current measurements. I'm using a Keithley 6485 Pico-Amp to recored the current changes in microchannels. I downloaded the instrument drivers from the NI website and I tried to control the Pico-Amp current readings with LabView 7.1 but the rate of readings from the Pico Amp was slow ( a reading every 0.5 s). I tried to change a lot of parameters and I found the main problem causing such slow measurements is the read VI for the Pico-Amp was very slow in the while loop.

is there any way to recored fast continuous measurements from the Pico-Amp using the read VI in a while loop with LabView 7.1?.  or if there is another to do fast recordings form the Pico-Amp with LabView? 

I appreciate your help and suggestions.

thanks
0 Kudos
Message 1 of 20
(7,887 Views)
The Read.vi function has a timeout associated with it that you can shorten.  However, your data may not transfer completely.  My guess is the instrument has a fair amount of delay that is causing slow loop rates.  Are you able to control it by other means with faster response time?
0 Kudos
Message 2 of 20
(7,854 Views)
You might also want to look at using the multi-point read functions. I could not find a driver on NI's site, only a link to Keithley's IVI driver. I'm assuming this is the one you are using. There are a couple of shipping examples. There is a Binary Read that uses a Fetch Multi-Point and one called Buffer Read that uses a Read Multi-Point. A fetch operation is usually much faster than a read.
Message 3 of 20
(7,847 Views)
I have no experience with that one, but with other models you could improve speed a lot when you did not send the 'MEASUREMENT' command, but a ´'CONFIGURE' and afterwards (in a loop) the 'READ' commands (measurement is configure+read), having a single instrument connected, the capture-fetch does not improve  much. (You normaly can look into the LV-drivers what command they use).
The other options is the NPLC-setting (number of power lines cycles), that is often used in DMMs, check that value (if NPLC is 20 and PLC is 40Hz = 0.5 sec).
If none of these works, post some code.

Felix
Message 4 of 20
(7,840 Views)
thanks a lot guys for your suggestions and comments.

at the present time I'm using the analog output of the Pico -Amp to recored the readings via a Daq since I couldn't control it form the drivers. So,  I only control the Pico Amp from the
front panel.


Dennis, thanks for your suggestions and it is true that fetch multi-point is faster but it is still not fast enough since I want reading at a rate of 40-50 Hz. if you know of a way to increase the readings rate to the frequency I need it will be helpful.


F. Schubert, thanks for comments. I don't know how to change the NPLC since when I change the value in the VI an error message appears and Labview terminates. the NPLC setting is 1 and PLC 60 Hz.


I attached a sample of VI I'm using to find the readings from the Pico-Amp and I would appreciate any suggestions to improve the readings rate. also how can I change the NPLC value of the device?

Thanks



Message Edited by Zeyad on 09-13-2007 11:51 AM

0 Kudos
Message 5 of 20
(7,811 Views)
What is the LabVIEW error message?
0 Kudos
Message 6 of 20
(7,787 Views)

Hi zeyad,

 

were you able to get a faster reading rate afterwards? I know it's been a long time but I'm encountering the same problem right now with 6485. Could you update with a new vi file? 

0 Kudos
Message 7 of 20
(6,622 Views)

rodmanhust,

 

Did you try any of the other suggestions above?  Did you have problems with those?

Eric B.
National Instruments
0 Kudos
Message 8 of 20
(6,591 Views)

Hi rodmanhust, 

 

I gave up on trying to speed up the picoameter with lab view. I reached the conclusion that there were limitations in the speed of the device and the Labview. Keep in mind that I’m using R232.  Finally I decided to record the analog signal with a BNC concoction and I dumped the idea of automating my experiment.   

 

0 Kudos
Message 9 of 20
(6,583 Views)

Zeyad and Eric,

thanks for your comments.

 

I'm also using a RS232 connection for KE6485, and with the Fetch function I used (as in the attached vi file) I could still only get fastest sampling rate at about 0.5s. With Read function I get ~0.7s, so the fetch is only slightly better (only one device connected, so no need for Multi Point, right?) . However, in the vi file if I place the "Initiate" function ("help" says it has to be used before Fetch function) outside the while loop the sampling rate is much faster, reaching down to ~0.01 sec, the problem is that it only reads a static signal. I think KE6485 is capable of generating fast sampling, because if I switch "rate" to fast on the front panel, it shows a really fast changing current. Maybe RS232 is the bottleneck? I'm not quite sure what's a BNC, but did it help Zeyad? 

 

In my setup, frequency is 60HZ, and NPLC is 1. When I tried to change NPLC and run, program freezes w/o any data reading.  so right now I really don't know how to improve sampling rate. Even ~0.2 sec would be a huge help. I wonder if you guys could take a look at the vi file for me and let me know if there is anything I can do. thanks!

0 Kudos
Message 10 of 20
(6,574 Views)