Bradley Odhner

Oh good! I had read through your post but hadn't looked at the code yet. Glad you figured it out! Autozero is a very common setting to trip people up when trying to do time dependent measurements.

We do recommend using the Autozero Once command (AZER:ONCE) immediately before your test and periodically or when you have gaps in your test for the best accuracy.

How many voltage points are we talking about?

My first thought is to try sending the list to the SMU separately as new array, breaking it up if needed. In pseudocode:

writeline(K2412B, strjoin({'vlist=',VliststrPart1)});
writeline(K2412B, strjoin({'vlist=vlist..',VliststrPart2)});
writeline(K2612B, strjoin({gate_smu,'.trigger.source.listv(vlist)'}));

(".." is the concatenation function in TSP/Lua.)

Autozero measures at the same nplc as the measurement it's taking a reference for, so I would expect it to ~double the reading time of measurement.

There are a number of things that dictate when autozero measurements happen, but larger nplc will generally cause them to happen more often, perhaps even every measurement. Larger nplc reduce external error factors so the DMM attempts to reduce internal error factors by autozero-ing more often. Also, autozero measurements are considered valid for some amount of time independent of the nplc setting, so larger nplc will burn through that valid time after fewer readings. Temperature is another factor and autozero frequency can be impacted by the system uptime.

Some TSP code and results to check this:

dmm.measure.autozero.enable = dmm.OFF
dmm.measure.count = 2
for i = 1, 10, 1 do
    dmm.measure.nplc = i
    dmm.measure.read()

    diff = defbuffer1.relativetimestamps[defbuffer1.n] - defbuffer1.relativetimestamps[defbuffer1.n-1]
    diff = diff*1000
    print("sample period ="..16.67*i.." , actual time = "..diff.."nplc = "..i)
end

sample period =16.67 , actual time =16.706666 nplc =1
sample period =33.34 , actual time =33.368485 nplc =2
sample period =50.01 , actual time =50.038273 nplc =3
sample period =66.68 , actual time =66.703666 nplc =4
sample period =83.35 , actual time =83.374394 nplc =5
sample period =100.02 , actual time =100.037848 nplc =6
sample period =116.69 , actual time =116.704788 nplc =7
sample period =133.36 , actual time =133.37103 nplc =8
sample period =150.03 , actual time =150.036636 nplc =9
sample period =166.7 , actual time =166.704273 nplc =10

dmm.measure.autozero.enable = dmm.ON
dmm.measure.count = 2
for i = 1, 10, 1 do
    dmm.measure.nplc = i
    dmm.measure.read()

    diff = defbuffer1.relativetimestamps[defbuffer1.n] - defbuffer1.relativetimestamps[defbuffer1.n-1]
    diff = diff*1000
    print("sample period ="..16.67*i.." , actual time = "..diff.."nplc = "..i)
end

sample period =16.67 , actual time =16.707213 nplc =1
sample period =33.34 , actual time =33.373909 nplc =2
sample period =50.01 , actual time =50.040182 nplc =3
sample period =66.68 , actual time =66.704819 nplc =4
sample period =83.35 , actual time =168.76 nplc =5
sample period =100.02 , actual time =202.091 nplc =6
sample period =116.69 , actual time =235.426 nplc =7
sample period =133.36 , actual time =268.759 nplc =8
sample period =150.03 , actual time =302.093 nplc =9
sample period =166.7 , actual time =335.427 nplc =10

Hi there, I'm guessing autozero was on?

The reference measurements will insert themselves wherever the unit decides, so you should always turn off autozero for tight timing control (and manually take them with dmm.measure.autozero.once() ).

Ah glad you found a solution!

I would think it would be faster to do the search on the instrument using the TSP engine, did you try that? Unless you needed all the readings on your PC anyway. Or it sounds like things are running fast enough for you already.

This TSP code searches through defbuffer1 to find all instances of num within a tolerance (since defbuffer1[i] returns more digits than the measurement resolution).

function countInstance(num, tolerance)
    local count = 0
    local high = num + tolerance
    local low = num - tolerance

    for i = 1, defbuffer1.n do
        if high > defbuffer1[i] and defbuffer1[i] > low then
            count = count+1
        end
    end

    return count
end

After putting this function on your DAQ6510, you simply run print(countInstance(num, tolerance)) to return the count to the terminal.

Check out section 17 of the 2460 Reference Manual for a guide on converting 2400 code for the 2460: https://www.tek.com/en/keithley-source-measure-units/keithley-smu-2400-graphical-series-sourcemeter-manual-8

I'm not totally sure what you mean on synchronizing source/sense for the 2460s, you just want to measure the voltage and current at the same time? This is called source readback on the 2460 and is on by default. When source readback is on, the SMU will measure the source value immediately before the measure value. These readings are returned with the same timestamp in the reading buffer.

Need some clarification here, do you want to find how many times a value (the max value) is repeated in a buffer? Or do you want to find multiple local maximum values?

For the former, I don't think there's a faster way to count the number of occurrences in a buffer than iterating through and using a helper variable to count the number of times you see the value you want. You mentioned you're searching for a low voltage condition though? You might be able to use limits to get what you want, see the dmm.measure.limit commands.

For the later, I think using a bit of calculus would be the best bet to find the number of local maxima. A compact way would be to use buffer.channelmath() with a created full buffer (not defbuffer1 or defbuffer2) and the buffer.EXPR_SUBTRACT expression. This creates a new column on the reading buffer that records the difference between the current reading and the previous reading. There is a local maximum wherever this column changes from positive to negative. Though, you will need to search through the data to find those changes, I'm not sure of a great way to do that automatically...
Another way could be to perform a binary search on the buffer by using timestamps to cordon off parts of the buffer to search in, using the buffer.getstats(bufferVar, relStartTime, relEndTime) syntax for example.
 

Preferable would be to bring the 4200A closer to your test setup if at all possible.

The PMU-RPM interconnect cables (P/N CA-547-x) are close to being standard HDMI; specifically they are Belden Series-FE 28 AWG HDMI cables. But, we impose additional requirements before they are accepted as RPM cables so I cannot say they are exactly standard. The RPM uses the cable for both digital and analog signals, so adding length or changing the style of cable may degrade the performance and measurements you get.

Sorry to say I would recommend against using a different cable than what came with your RPM.

For a powder I would recommend measuring resistivity by sourcing voltage and measuring current, yes. Since the 6514 doesn't have a built-in voltage source, this would mean using an external supply as you noted. For connections, place the 6514 as an ammeter in series with your voltage source and sample. Place the 6514 on the LO side of the system, so your circuit goes voltage source HI > sample > 6514 > voltage source LO.

Ideally the 6514 LO, not chassis/ground, would be connected to the metal enclosure and you would have another metal enclosure around that connected to chassis/ground. But I wouldn't worry too much about that until you're getting stable readings.

If you haven't seen them already, you might find sections 2.4 and 4.4.2 of the Low Level Measurements Handbook helpful: https://www.tek.com/en/documents/product-article/keithley-low-level-measurements-handbook---7th-edition#C4section3

Based on your description, you might be seeing capacitive behavior of the sample charging up then discharging, though it could easily be some other effect. Sourcing voltage and allowing plenty of settling time should return a more accurate result.