LabVIEW
How to encrease operation speed when measure with Keithley 6430
You're forgetting a lot of steps that take a lot of time in your code.
1) Every loop you are sending a command to set the current. The instrument needs to receive the command, process the command and allow current to settle. (Atleast 20ms, maybe 1s depending on current value.)
2) Then you send a "READ?" command. Instrument needs to measure (unknown time given all the auto settings), convert reading to ASCII and transfer it over the bus. From memory measurement time is something like 1ms (1-100V) 1s (10mV), 10s (10u-10mV), >10s (<10uV)? Remember this instrument is sensitive enough to resolve <1fA (1E-15A!) its not meant to be fast but accurate. Having said that there are lots of ways to make it much faster, similar to a K2400 if you disable auto settings, set ranges to constant values.
You can speed things up 2 ways:
1) Reduce the number of times you send info to and from the instrument, you could use the memory buffer or the built in sweep. Here's an example of the built-in sweep. Personally, if I was doing this I would source I, measure V and use a linear fit to get R but for simplicity I went with R=V/i here since that's what you did in your VI.
2) Disable the auto-scaling, auto-zero, auto-range, set NPLC, etc.. For starters I haven't bothered with that. Try this code first, report on speed and we'll go from there.
Craig
@q232 wrote:
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?
Block diagram cleanup is an icon on the toolbar. (Unless you have a fairly old LabVIEW version. Click it. It doesn't get rid of wires. It cleans them up so they are visible, straight, and not running backwards.
@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 ?
No need to check to see if the button is pressed every fraction of a second. An event structure could help as well. Don't send the code until AFTER the loop ends.
@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?
Put an indicator on the front panel for the simplest way of seeing what the error is.
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.
Put some small flat sequences and an Get Time function in it with a wire passing through. Put an indicator there. If you put that before and after some key VISA functions and look at the difference in times to see how long certain sections of code take to run.
@q232 wrote:
Hmm, I send command READ? every time as I measure the voltage. Device give answer in 14 byte. According to configuration of RS232, baud rate is 9600. As I know it can get 9600 byte/s. For 14 byte program should spend 1ms.
No, you can get 9600 bits/sec. 1 char is 8 bit+stopbit(s), so usually 9. Ýou can read 1066 chars/sec, pretty much 1ms/char. If you also need to send ~8 chars as command you're up to ~25ms/read.
/Y
Dear cstorey,
I try your code. It works strange.
As a test sample I use 1kOhm resister. Keithley returns resistance between 937-1070 Ohm (see Fig. 1) for current 10 microA to 100 microA. It is ok.
But for current microA to 10 microA the resistance jumps between 840 - 2000 Ohm (see Fig. 2). I think it is some noise. To avoid it, I want to measure voltage for each current value several times and write average. For me it is not clear how to realize such algorithm with function SweepMeas from library.
About speed. For 10 Steps Keithely spends 35 s.
With disable the auto-range in SweepMeas function it spends about 10-20 s for 10 steps.
).