August 16, 2004

Changing compliance (CMPL) value

I always forget this. I guess I'm not the only one, since Keithley has even published a FAQ on it.

Press the green EDIT button (upper left hand corner) twice to access the compliance values. Use the UP, DOWN, LEFT, and RIGHT arrow buttons to change the displayed value. Press the ENTER button when you reach the desired level.
Very unintuitive.

Posted by torque at 5:15 PM | Comments (0) | TrackBack

August 9, 2004


It takes a good chunk of time to load 2500 data points into the 6430 to do a sweep. If you will be reusing the sweep, you don't need to reload it. All you need to do is to issue the following command before you run :INIT again:

where should be replaced with the number of readings, 2500 maximum.

Posted by torque at 10:58 AM | Comments (0) | TrackBack


The timestamp function of the Keithley 6430 is based on an internal oscillator with a frequency of 8.192kHz. Ticks occur every 8.192kHz/8 or 1024 a second, which means a system tick occurs every 0.9765625. The reported timestamp value is thus off by 24 ms every second. To obtain a more accurate timestamp value, we must multiple the timestamp by a factor of 0.9765625. Hmmm....

Posted by torque at 10:27 AM | Comments (0) | TrackBack

June 24, 2004

IV curve for the Keithley 6430

I "finished" a simple IV curve application for the Keithley 6430 this morning. For those of you who are interested, you can pick up the VI here. You will need to use the included debugged Keithley library, kei6430.llb. I would put this in the C:/Program Files/National Instruments/LabVIEW 7.0/instr.lib directory. The main file,, can be run from anywhere. The VI itself is quite simple, simply enter the start and stopping points and the number of points and it will do a linear sweep. Everything else is in AUTO mode.

Posted by torque at 11:49 AM | Comments (6) | TrackBack

May 17, 2004

Illegal with storage active

When debugging labview programs for the 6430, you might get stuck in with an "illegal with storage active" error. This happens when the device is expecting to store data but you are trying to give it commands that alter, for instance, the buffer size. I have to admit, when I first ran into this I just got frustrated and rebooted the machine. The asterix in the upper right hand corner tells use that it is in storage mode, hence the error. To get out of this, you need not turn the machine off. Just press LOCAL (to get out of remote operation) and then STORE and then EXIT. Whew.

Posted by torque at 12:49 PM | Comments (2) | TrackBack

May 11, 2004

Acquisition update

The source-acquisition system seems to be working properly now. Sometimes the response from :FORM:ELEMents? is slow, so it is important to make sure that GPIB Read does not timeout, which was what was happening. Unfortunately, labview is less than helpful in these instances, providing only a "generic file I/O error". Also, uploading the waveform is slow, since I do it in blocks of 25, communicating with GPIB each time. This can be optimized substantially, though will not affect actually acquisition. The best I was able to achieve was about 1.9 ms. Only two things really make this worse, voltage autoranging (in the case of a current source) and auto-zero. Voltage autoranging makes the timing very erratic, on average it is about 2.7 ms, but can go up as much as 26 ms when the machine is thinking. Auto-zero is not so bad in terms of stability but will add a little more than 2.5 ms to the measurement.

To summarize:

scenarioδt (ms)
all off, just volts, SREal1.857
all off, all functions,SREal1.901
all off, all functions, ASCII1.901
auto filter on (1/5%), rest off, all functions, SREal1.901
repeat filter on (1), rest off, all functions, SREal1.901
median filter on (0) rest off, all functions, SREal1.901
current autoranging on, rest off, all functions, SREal1.901
voltage autoranging on, rest off, all functions, SREal2.724
autozero on, rest off, all functions, SREal4.422

You can pick up the raw data here.

Posted by torque at 3:02 PM | Comments (4) | TrackBack

Automation v0.5

The sine generator works now! Special thanks to Dale Cigoy at Keithley for insisting that I could get down to a couple milliseconds per measurement. I'll post more information and the relevant files tomorrow morning, since some sorting needs to be done on the dependencies. For long waveforms (>100 points), I was running out of GPIB buffer, so I ended up rewriting the source generator to send batches of 25 points directly to the 6430, rather than building a huge command to send all at once. With basically everything optimized, sourcing current and measuring just voltage, I was able to achieve 1.8793 ms per measurement on average. This value seemed pretty stable, though, since I don't have an oscilloscope on hand, it is hard to tell whether this is the real value or if some measurements are faster than others. The timestamp resolution is around 1.9 ms.

For the following table, current, amplitude 1 μA, was sourced sinusoidally and 2500 points sent to the 6430.

scenarioavg time per measurement (ms)
everything off, measuring just voltage1.879
everything off, measuring all functions1.921

Alas when I tried to change the auto-zero I got a buffer read error. I'm not sure why.

Posted by torque at 12:24 AM | Comments (0) | TrackBack

May 10, 2004

Header error in Filter

I kept getting the annoying buzz error (Error -113, Undefined header) this morning when using Keithley 6430 Filter I finally isolated the problem. The third box down, when false, should have :Sens:Med Off; not :Sens:Aver:Med Off;. When true, it should be :Sens:MED:Rank %d;State On; instead of :Sens:Aver:MED:Rank %d;State On;. It still doesn't improve acquisition times, but at least you can get the error to stop. For more information on configuring the median filter go to 17-61 of the manual.

Posted by torque at 12:36 PM | Comments (0) | TrackBack

May 6, 2004

System commands vi

When using Keithley 6430 System as a sub-vi, remember to select a system function, otherwise you may not be doing what you think you are doing. Earlier, I mentioned that switching autozero to disable was not making a difference. That was because I did not select the correct system function "Autozero Control". When I finally did that, the time between data points dropped to 1.9 ms. Woo hoo, >500 Hz. A lot of the included vi's are tricky in this way. Just because you send a value into the vi doesn't mean that it will get set. You really need to open up the vi and take a look at what it is doing.

Posted by torque at 4:38 PM | Comments (0) | TrackBack

May 5, 2004

Sine source generator

It took some time to sort out how to route data in labview, but I finally finished the first version of my source generator for the Keithely 6430. The key? Convert from dynamic data. Unfortunately, the waveform tool that comes with labview does not have a control for specifying the number of points in the waveform. This is done using the vi control panel. Feel free to download, use and abuse Keithley 6430 Sine as you see fit. For one does not have the Sine preset (waveform input) use Keithley 6430 Source Just make sure there aren't more than 2500 points.


Posted by torque at 4:01 PM | Comments (0) | TrackBack

May 3, 2004

System speeds

The 6430 instruction manual gives information about system speeds on page A-5. With Auto zero off, autorange off, filter off, display off, source auto clear off, and binary reading format, at 0.01 NPLC the specs give a reading rate of 2080 rdg/second for "Measure", but only 930 for "Source/Measure Pass/Fail Test".

You can disable autozero using Keithley 6430 System (where you can also do a lot of not so useful things, like changing the beeper frequency). The actually remote command is :SYSTEem:AZERo OFF. It is ON at default.

Every A/D conversion (reading) is calculated from a series of zero, reference, and signal measurements. With auto zero enabled, all three of these measurements are performed for each reading to achieve rated accuracy. With auto-zero disabled, zero and reference are not measured. This increases measurement speed, but zero drift will eventually corrupt accuracy. With auto zero disabled, periodically change measurement speed.
Temperature changes across components within the instrument can cause the reference and zero values for the A/D converter to drift due to thermo-electric effects. Auto zero acts to negate the effects of drift in order to maintain measurement accuracy over time. Without auto zero enabled, measurements can drift and become erroneous.
So, use with caution. More about AZERo in 17-92. More notes, from 17-93,
Auto zero should be disabled with the :SYST:AZER OFF command for maximum source memory sweep speed; otherwise, the cache is of little use. With auto zero enabled, new A/D reference and zero values are taken for every reading and saved into the cache, slowing down sweep operation. However, with auto zero disabled, measurements may drift and become erroneous. To minimize drift when using NPLC caching with auto zero disabled, periodically send :SYST:AZER ONCE to force an immediate auto zero update.

Posted by torque at 10:38 AM | Comments (0) | TrackBack

April 30, 2004

Default source delay

The default source delay, per 1-20 of the manual, is 3 ms. At the moment, I am getting about 7.8 ms between data points. I tried turning the display off, but it made no difference. Next step is probably to take the source delay down to 0 and see how that works. The big question now is how high a frequency I can achieve.

Keithley 6430 Source addresses some of these issues. Setting the source delay to 0 took me down to 4.8 seconds. Reducing the amount of data being measured does not seem to make a difference. I'm not sure what else is left that I can do.

Posted by torque at 11:43 AM | Comments (29) | TrackBack

SREAL buffer read issues - solved

Problem solved. The GPIB read vi and the Keithley 6430 interact in a funny way. If you split the read into two portions, it won't work properly because the last character of the first read shows up in the first character of the next read. The original Keithley 6430 Buffer had two problems. The :TRAC:DATA? read was split into three sections: reading the header "#0", reading the data, and then reading the LF (linefeed) character. Because of the error I discussed above, data was not being properly read into labview. In the second read, the byte for "0" shows up before the data, shifting the dataset by 1 byte, this had two effects - it caused the data to read in funny and it caused the primary vi to crash when run again since there were characters still left in the buffer. I solved the problem by reading the entire block, +1 extra character in one swoop, and then stripping the first two characters out before conversion. You need the extra character so that it doesn't leave the LF in the buffer. If you don't have it the next run will crash.





Download file

Posted by torque at 10:39 AM | Comments (0) | TrackBack

April 29, 2004

Arbitrary source waveforms

A very nice feature of the 6430 is the capability of generating source waveforms, up to 2500 points. Programmatically it is a bit awkward. Source points are entered 100 points at a time, in comma-delimited format. For the first 100, you use :SOURce:LIST:CURRent <first 100 in list> where the list for current can range from -105e-3 to 105e-3 and the voltage from -210 to 210. It's not clear, but I think you also have to set :FUNCtion:MODE properly. After that you use APPend, as in, :SOURce:LIST:CURRent <next 100 in list>. If we wanted to source current, we would do something like

:SOURce:LIST:CURRent .001, 0, .01, 0, .005, ...;   (1 mA, 0 mA, 0 mA, 5 mA)
:SOURce:LIST:CURRent:APPend .5, .4, .0, .01, ...

Posted by torque at 4:32 PM | Comments (0) | TrackBack

April 28, 2004


I was able to get my data acquisition vi to work properly, but only when the storage mode was set to ASCII. When set to Single precision REAL, read buffer returned what seemed like junk data. It isn't really clear why.


I'm getting close. There are some subtle bugs in the Keithley 6430 Buffer having to do with SREAL acquisition. If you look at the raw data coming back from the machine, the header is actually three bytes, not two. There is also a line feed (LF, #010) at the end.

Posted by torque at 12:00 PM | Comments (1) | TrackBack

April 27, 2004

SENSe1 subsystem - CONCurrent

Per 17-54 of the manual, in order to enable the 6430 to measure more than one function simultaneously, you must use :FUNC:CONC ON. After you do this, you will still need to turn the various functions on and off, e.g., :FUNC:ON "CURR","VOLT". Note that each function in the list must be enclosed in quotes. To get voltage, current and resistance, you can use :FUNC:ON:ALL or just :FUNC:ALL. Now, what is not clear is how choosing all versus just one makes a difference in how fast one can do the measurements. Presumably when measuring impedance you would want both current and voltage.

I wish there was a simple way of searching through vi's for a particular string of text. As it is, you have to open each one and skim through the block diagram.

Keithley 6430 Data

  • :FORM:ELEM ...

Hmmm, in 13-2 it says that when changing from local to remote operation, concurrent measurements are enabled. I'm not sure why it isn't working properly then.

Posted by torque at 2:02 PM | Comments (0) | TrackBack


I decided on using the larger pre-built Keithley vi's. While they make life a bit simpler, they can sometimes have too many options. I'm stuck at the moment on the trigger configuration vi. The command in question is the direction: TCON:DIR SOUR or TCON:DIR ACC. I took a look at the triggering flowchart, but that only confused me more.


From the flowchart, it looks like the difference between SOUR and ACC is whether it waits for an external event. It seems like I should choose SOUR if I have no external triggering. But then why is ACCeptor the default?

Posted by torque at 11:01 AM | Comments (0) | TrackBack

April 23, 2004

Surf the web with labview

Ok, this is not really related to the 6430 - only sort of. It turns out that labview has TCP vi's which are pretty easy to use. After changing text on the 6430 display yesterday, I started thinking about fun things I could put on it... like stock quotes or maybe a news ticker. I know, it's silly. For what it is worth,

You might use this technique to inteface your labview instrument with an external database, which could be quite useful. Of course, this could also be done with ODBC and LabSQL.

Posted by torque at 11:43 AM | Comments (0) | TrackBack

April 22, 2004

6430 display config

Be careful when you use the Keithley 6430 Display Config vi. You must set the displayed resolution otherwise you will get error -222. This is because the default value for the displayed resolution is "<4>" and not "4".

An alternative to entering the number is actually fixing the vi. If you look, Displayed Resolution is entered into the GPIB code using a knob. The knob itself uses text labels "4,5,6,7" to output numbers "0,1,2,3" to which the vi adds 4.


You can see the text labels by right-clicking on the Displayed Resolution icon and selecting the "Text Labels" tab.


It's clear from hear that the default value should be 0, not 4. To fix this, click on the "Data Range" tab. You'll have to first change "Minimum" to 0, then change "Default value" to 0, then change the "Maximum" to 3.


Now when you use the vi, it should work without filling out Display Resolution. If you do add a constant, you'll see that the default is "4" instead of "<4>".

Posted by torque at 5:17 PM | Comments (0) | TrackBack

Feed control

This post regards the buffer control command, :TRACe:FEED:CONTrol. There are two parameters, NEXT and NEVer, discussed in 17-101. NEXT "fills buffer and stops" while NEVer disables buffer storage. In some previous code, I wrote

This tells the instrument to stop storing information in the buffer and then clears the buffer. Pretty straight-forward. If you do this, you must remember to call :TRAC:FEED:CONT NEXT in order to resume buffer storage.

Posted by torque at 4:13 PM | Comments (1) | TrackBack

April 19, 2004

Almost there...

I'm basically replicating an existing sample - but trying to understand things as I go along. Often it still seems that having code would make things much faster to understand. Labview is growing on me though.


Posted by torque at 6:13 PM | Comments (0) | TrackBack

Handling bad programs w.r.t. the 6430

I've been fiddling around with controlling the 6430 using Labview. From time-to-time, I write bad code, which causes all my other code not to work. Resetting the 6430 does not seem to make a difference, and the only solution seems to be to reboot the computer. This is very annoying. There must be a better way. The most frustrating part is when you don't know whether it is the code or if the GPIB card is stalling. I see the error a lot - it is the sign to reboot. Arrghhh.


Isn't that horrible? It's so bad I took it off the main page.

Posted by torque at 4:38 PM | Comments (1) | TrackBack

April 16, 2004

4-wire sans connector

I realized that I could simply use one of the probe stations to act as a sense, since these were configured correctly. The results for the 18 MΩ resistor. About 25-30 seconds are necessary before the 2-wire values stop moving. The 4-wire values seem to take even longer, slowly creeping upwards. I'm speculating that the resistor may have some capacitance, causing its behavior over time to change. Should I let it sit until it stops moving, or should I record the first value right away? Tricky. I used a much smaller resistor (several kΩs) to discharge the large resistor right before recording a measurement for both 2-wire and 4-wire. This seems to always bring it back to about the same value.

measureR (MΩ)
2-wire, no OCOM17.6977
2-wire, with OCOM17.6971
4-wire, no OCOM17.6998
4-wire, with OCOM17.6986

Why would the 4-wire take so much longer to stabilize? What is the proper procedure?

Posted by torque at 2:38 PM | Comments (0)

April 15, 2004

Triax and test equipment "accessories"

In my last post on the 6430, I realized that the triax-to-BNC converter was not hooked up properly for my application. Looking for triax online I inevitably ended up at Pomona Electronics, who also made my BNC to grabber cable, which I purchased for $13.99 at Fry's. Their Model 4725 & 5342 Triaxial BNC Male 2 & 3 Lug To Insulated Alligators Cable Assembly looks quite suspiciously like the corresponding Keithley part. Now where can I buy one? Whoa, it's $112.38 at Newark InOne. Per the 6430 data sheet, I would want the 3-lug part. They also have a BNC-to-triax connector, the 5300, but it is guard to shield.

It turns out that the 6430 data sheet includes a big list of accessories you can buy from Keithley. They offer the Model 7078-TRX-BNC Adapter, which is a 3-slot male triax to female BNC adapter used to connect a BNC cable to the triax input of the 6430. Now, unlike the Model 237-BNC-TRX Adapter (male BNC to 3-lug female triax), there is no mention that the guard is disconnected, so there is a chance that this is what we already have.

I found exactly what I was looking for at Probing Solutions - $166 for this tiny part. It's the one on the left, 102: Adapter, Male Triax/BNC Jack, Shield to Shield, not, as we have now, the Guard to Shield.

Posted by torque at 5:49 PM | Comments (6)

Ohms, continued

To recap, I found an 18 MΩ resistor that I decided to use to scope out the Keithley 6430. I made two 2-wire measurements, with offset compensation (OCOM) disabled (17.7025 MΩ) and enabled (17.7084 MΩ). Next up, 4-wire measurements and other variations...

As a sanity check, I redid the two measurements (machine cold) from yesterday.

measureR (MΩ)
2-wire, no OCOM17.7057
2-wire, with OCOM17.7048

Not very encouraging. It is unclear how long it has to warm up before the readings are consistent? It may also be due to the temperature of the resistor. After about 5-10 minutes the OCOM measure is now 17.7056 MΩ. It has been about an hour now, here are the measurements.

measureR (MΩ)
2-wire, no OCOM17.7057
2-wire, with OCOM17.7047

Maybe I did something funny yesterday. Here's the setup for the 4-wire measurement:


I'm not sure why the diagram has the Sense LO going all the way back to the rear panel connector. Wouldn't it be sufficient to use the Sense LO from the pre-amp? Since I didn't have a banana plug cable handy, I used a triax to BNC followed by a BNC to clip leads. Something funny... I setup the four-wire measurement and am now getting 0.51274 MΩ. Weird. Without the sense wires, I get what I got before (whew... didn't break anything.) What went wrong here? Ok, I think I see the problem, I think it is the triax-to-coax connector. Instead of taking Sense HI and Sense LO out, it is taking Sense Hi and the shield.


The 6430 comes with one 6430-322-1A triax cable which is terminated with a triax connector on one end and booted alligator clips on the other end. Why just one? What I really would like is another one of these for the sense side.

On another note, I notice that whenever I hover around the measurement the reading gets noisy - static? capacitive-coupling? Be careful.

Posted by torque at 10:14 AM | Comments (2)

April 14, 2004

Measuring Ohms

To get to know the 6430, I've decided to measure Ohms. According to 2-4 of the instruction manual, for the triax to alligator clip, red=HI, black=GUARD, and green=LO. Although I could have left LO floating, I connected it to the chassis ground. (I'll try the floating... later.)

For the two-wire configuration, per the diagram in the manual, SENSE is left open, and the resistor (the device under test or DUT) connected between HI and LO. GUARD is the same voltage as HI (2-6) - I left this disconnected.


There are four items to configure in resistance measurement:

  • SRC RDBK - source readback mode (ENABLE or DISABLE), and
For this first measurement, I set SOURCE to AUTO (CONFIG->Ω->SOURCE->AUTO) to make the device select its own test current. If you do not do this, it will give some wierd number - around 700 kΩ - because the source current is zero. I left everything at it's default (CABLE/ENABLE/DISABLE). Testing a resistor that Nick left on the table, I found it to be 1.00011-1.00013 MΩ with the value of the last digit fluctuating over time. Does it make sense? Unfortuantely the resistance value was encoded using 5 bands. Thanks to Sam Engström's graphically-nifty translator, I was able to decode it in a jiffy, 1 M&Ohm; with 1% tolerance. Good. The source current, Isrc, was 1.00000 μA and the compliance voltage limit, Cmpl, 2.10000 V.

Now, 1 MΩ was still kind of small, so I scrounged around and found a brown-brown-blue-gold resistor - 11 MΩ±5%. (Incidentally, in case you ever need them, html symbols found here.) Measurement? 11.2178 MΩ. Nice. I'll use this resistor for the remainder of my tests though it would be good if I could find something in the 100 MΩ range... I scrounged some more, and found a brown-gray-blue-gold resistor - 19 MΩ±5%. Measurement? 17.7025 MΩ. Ahh, I'll use this one.

Several quick tests. First of all, what does offset compensation do? It attempts to take out thermal EMF by measuring resistance (V/I) at a specific source level and then subtracting a resistance measurement made with the source set to zero. Result, 17.7084 MΩ. Interesting. Next step, 4-wire.

Posted by torque at 5:02 PM | Comments (0)

April 13, 2004

VI curve

I managed to get the 6430 to take a VI curve using the following code:

:*SRE 1;
followed by
and a wait period. I have several things in mind for this device. I would like to:
  1. Test input current for various amplifiers, and on the Softsens sensors,
  2. Measure the DC resistance for various electrode combinations, and
  3. Measure the impedance between 0-100Hz for various numbers of pins in my pin-electrode.

Probably the easiest first test is to do the resistance. That will also give me a chance to measure noise in the measurement. According to IEC 60601-1-4, for non-cardiac, floating ground applications, the limit is 100 μA DC and 10 μAC.

Things to do:

  1. Figure out how to get raw data from the machine
  2. Get labview to plot my data
  3. The grounding configuration...

Posted by torque at 4:37 PM | Comments (2)

April 9, 2004

Getting labview working

The GPIB board finally came in. At the moment, we are running a copy of Labview 7 Evaluation, though the real one should come in a week or so. Through Keithley, you can download the 6430 BETA LabVIEW ver. 5.X driver for Windows, which, when unzipped, contains a library of Labview VIs for the Keithley 6430.


Make sure that the communication mode on the 6430 is set on GPIB, 488.1 (not SCPI) and click on "Keithley 6430 One-Shot Measure?". Run the instrument by clicking on the white go arrow, and you should see something like this:


That's great. The next step is to build our own continuous acquisition. Here's the block diagram.


First, do a Save As so that we don't write over the original.

Posted by torque at 3:22 PM | Comments (4)