LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to encrease operation speed when measure with Keithley 6430

I need to use a Keithley 6430 as current source and voltage measurement device. 

It is connected by RS232 with

  • 9600 baud rate,
  • 8 data bits,
  • 1 stop bits,
  • none parity

I need to continuously change the DC current and measure voltage by 4 point method. The picture below shows Keithley 6430 code. I send command to wait 5 ms before after changing current value. I  measure voltage several time for each current value (small loop on the second picture) and out put arithmetic mean.

 

For 2 current values and 10 voltage measuments the program spend about 30 s. I think it is too long.In future I should do measure voltega for 100 current values at least.

 

Could you please help me to understand how encrease operation speed of the program?

 

11.png2.png3.png

 

 

Download All
0 Kudos
Message 1 of 24
(4,323 Views)

A couple of tips to start.

 

First,  use block diagram cleanup.  You've have a lot of wires running in numerous directions including backwards with many bends.  That makes it much more difficult to read.  Some wires disappear off the edges of the structures.

 

Second, put a wait function in that loop where you are continually polling the start button.  That loop is running as fast as it can constantly sending out data to that resource.  That could be clogging the device with commands that take longer for it to process than LabVIEW is sending them.

 

Third, use your error wires between the VISA functions.

 

Fourth, "Step" which from the code seems to mean "number of steps" should be an integer, not a double.

 

I don't see any 4 point averaging that you talk about.  I don't see where you are reading 10 voltages.  If you do have 2 currents and 10 voltages, I take that to mean you have 20 different steps going on.  For 30 seconds, that is 1.5 seconds per step.  Have you checked the timing of the VISA functions?  Perhaps it takes the device that long to return a response.  I don't see anything else in your LabVIEW code that would cause it to take longer than you think it should.

0 Kudos
Message 2 of 24
(4,304 Views)

You should definitely follow the coding comments RavensFan made! 

 

Note that the time it takes to send commands to and from the instrument can be >> measurement time.   So you might consider doing all the averaging on the meter and just reading back the average and SD rather than trying to read back a lot of data quickly and averaging in code.  See the section of the manual about using the Data Store features (Section 8-6 and 8-7 - https://mm.ece.ubc.ca/mediawiki/images/0/07/K6430Manual.pdf

 

The K6430 isn't a high speed instrument, its a high accuracy instrument, though it does have a lot of flexibility.  Look at how you've configured the meter.  Are you are using the default INIT settings?  Auto-ranging?  If yo, auto-zero, auto-source scaling, auto-delay and all those nice features for high accuracy measurements are enabled.  If  are dealing in very small i or V then it will take longer than a few ms to resolve the measurement accurately and then the measurement aperture might be several powerline cycles long.   I suggest you read up a bit about how long the measurement should realistically require given whatever the default settings you are using dictate and see what you can afford to turn off without sacrificing accuracy. 

 

Finally there's a LabVIEW pre-made driver the the 6430 that might help you - http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=86521DB39F5238CDE04400144F1EF8...

 

At the least the included examples will show you haw the people who built the instrument handle things like reading data storage, setting up resistance measurements, etc..  Its worth a look since its free.

Message 3 of 24
(4,252 Views)

At 9600 baud serial with ascii coded double precision floating point numbers.  Nope, can't help.

 

Get a physical layer that can keep up.


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 24
(4,238 Views)

Thank for all comments. 


@RavensFan wrote:

A couple of tips to start.

 

First,  use block diagram cleanup.  You've have a lot of wires running in numerous directions including backwards with many bends.  That makes it much more difficult to read.  Some wires disappear off the edges of the structures.

 

 


I do not understand about  "block diagram cleanup".  All wire in VI I need. I make them all visibale. But how can it be better prepared for reading?

 


@RavensFan wrote:

 

Second, put a wait function in that loop where you are continually polling the start button.  That loop is running as fast as it can constantly sending out data to that resource.  That could be clogging the device with commands that take longer for it to process than LabVIEW is sending them.

 


I need while loop, because it is important connect sample after open the  power and measure channels. I pulled out OUTPUT VI from while loop. In this case will it be better ?

 


@RavensFan wrote:

 

 

Third, use your error wires between the VISA functions.

 

Fourth, "Step" which from the code seems to mean "number of steps" should be an integer, not a double.


 Yes, I added error wires. But I have not error handler for this device. How do I understand which error arise?

Sure, "number of steps" should be integer. I added some protection now.

 


@RavensFan wrote: 

I don't see any 4 point averaging that you talk about.  I don't see where you are reading 10 voltages.  If you do have 2 currents and 10 voltages, I take that to mean you have 20 different steps going on.  For 30 seconds, that is 1.5 seconds per step.  Have you checked the timing of the VISA functions?  Perhaps it takes the device that long to return a response.  I don't see anything else in your LabVIEW code that would cause it to take longer than you think it should.


 According to manual, I should chose source and measurement function, then device will be work in 4-point measurement rerime. I confige quantity of voltage measument, when I send "number of steps"  for small FOR Loop (see update pictures). 

Your comment about  timing of the VISA functions is right. It was my first think. But I do not know how to check this time. Also I do not find any time option in VISA Read function.

 

first part.jpgmiddel part.jpglast part.jpg

Download All
0 Kudos
Message 5 of 24
(4,192 Views)

@cstorey wrote:

 

 

Finally there's a LabVIEW pre-made driver the the 6430 that might help you - http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=86521DB39F5238CDE04400144F1EF8...

 

At the least the included examples will show you haw the people who built the instrument handle things like reading data storage, setting up resistance measurements, etc..  Its worth a look since its free.


Before start do my own program, I try to use this VI functions. I have not got sucсess. Furthermore, I use some VI from this pre-made driver.  I want make more simple program then in  pre-made driver.


@cstorey wrote:

You should definitely follow the coding comments RavensFan made! 

 

Note that the time it takes to send commands to and from the instrument can be >> measurement time.   So you might consider doing all the averaging on the meter and just reading back the average and SD rather than trying to read back a lot of data quickly and averaging in code.  See the section of the manual about using the Data Store features (Section 8-6 and 8-7 - https://mm.ece.ubc.ca/mediawiki/images/0/07/K6430Manual.pdf

 

 


Hmm. I missed this information. Thank you for this note.


@cstorey wrote:

 

The K6430 isn't a high speed instrument, its a high accuracy instrument, though it does have a lot of flexibility.  Look at how you've configured the meter.  Are you are using the default INIT settings?  Auto-ranging?  If yo, auto-zero, auto-source scaling, auto-delay and all those nice features for high accuracy measurements are enabled.  If  are dealing in very small i or V then it will take longer than a few ms to resolve the measurement accurately and then the measurement aperture might be several powerline cycles long.   I suggest you read up a bit about how long the measurement should realistically require given whatever the default settings you are using dictate and see what you can afford to turn off without sacrificing accuracy. 

 


I checked the configuration. After initialization I reset setting to default. I send to device auto-range and auto-zero command for source and meter channels.  But I do not send any command about delay. 

For me not clear why range, zero and delay commands is important for device in my case.

I want simplify program as much as it possible.  I do not  use scaling and range option of the device. I do this by FOR loop in my code.

 

 

0 Kudos
Message 6 of 24
(4,188 Views)

@JÞB wrote:

At 9600 baud serial with ascii coded double precision floating point numbers.  Nope, can't help.

 

Get a physical layer that can keep up.


Thank you for comment. But I do not understand anything for it.

Could you please explain?

0 Kudos
Message 7 of 24
(4,187 Views)

@q232 wrote:

@JÞB wrote:

At 9600 baud serial with ascii coded double precision floating point numbers.  Nope, can't help.

 

Get a physical layer that can keep up.


Thank you for comment. But I do not understand anything for it.

Could you please explain?


RS232 is a very slow physical layer. The 6430 supports GPIB. Get the GPIB supported option for faster data transfer. (GPIB was designed for Measurement devices and is much faster.)

 

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 8 of 24
(4,183 Views)

Thank you. Now it is clear.

Unfortunately, I have not possibility to connect 6430 via GPIB.

So in this case I should minimize quantity  of READ operation. Is it right?

 

0 Kudos
Message 9 of 24
(4,180 Views)

Yes, minimize the number of commands you send over the RS232 and have the 6430 do your averaging calculations.

 

What sort is the current level you source and the voltage you read? 

 

Attach your VI and people can more easily help you.  The pictures of your code aren't that much help to anyone.

0 Kudos
Message 10 of 24
(4,175 Views)