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.
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:
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....
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, anu_02.vi, 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.
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.
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.
|all off, just volts, SREal||1.857|
|all off, all functions,SREal||1.901|
|all off, all functions, ASCII||1.901|
|auto filter on (1/5%), rest off, all functions, SREal||1.901|
|repeat filter on (1), rest off, all functions, SREal||1.901|
|median filter on (0) rest off, all functions, SREal||1.901|
|current autoranging on, rest off, all functions, SREal||1.901|
|voltage autoranging on, rest off, all functions, SREal||2.724|
|autozero on, rest off, all functions, SREal||4.422|
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.
|scenario||avg time per measurement (ms)|
|everything off, measuring just voltage||1.879|
|everything off, measuring all functions||1.921|
Alas when I tried to change the auto-zero I got a buffer read error. I'm not sure why.
I kept getting the annoying buzz error (Error -113, Undefined header) this morning when using Keithley 6430 Filter Config.vi. 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.
When using Keithley 6430 System Commands.vi 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.
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 Generator.vi as you see fit. For one does not have the Sine preset (waveform input) use Keithley 6430 Source Generator.vi. Just make sure there aren't more than 2500 points.
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 Commands.vi (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.So, use with caution. More about AZERo in 17-92. More notes, from 17-93,
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.
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.
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 Control.vi 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.
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 Read.vi 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.
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, ...
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 Read.vi 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.
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 Format.vi
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.
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?
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.
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>".
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
:TRAC:FEED:CONT NEVer;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.
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.
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.
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.
|2-wire, no OCOM||17.6977|
|2-wire, with OCOM||17.6971|
|4-wire, no OCOM||17.6998|
|4-wire, with OCOM||17.6986|
Why would the 4-wire take so much longer to stabilize? What is the proper procedure?
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.
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.
|2-wire, no OCOM||17.7057|
|2-wire, with OCOM||17.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.
|2-wire, no OCOM||17.7057|
|2-wire, with OCOM||17.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.
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:
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.
I managed to get the 6430 to take a VI curve using the following code:
:TRAC:DATA?and a wait period. I have several things in mind for this device. I would like to:
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:
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.