Bradley Odhner

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.

Can you be more specific? What kind of voltage errors are you seeing?

The DMM7510 doesn't have a contact check feature, but you might be able to use the continuity or other functions to accomplish what you want, especially if you consider TSP. What sort of test are you performing where you want to verify contact?

The issue is you placed the smu.measure.autozero.enable = smu.OFF command too early. By placing it with the source commands, before you set smu.measure.func, you are setting the autozero behavior for the smu.FUNC_DC_CURRENT measure function. Move that command below smu.measure.func = smu.FUNC_DC_VOLTAGE and you'll get the faster ramp behavior every time.

How I discovered this (since the same process can help with script debugging in general):

1. I noticed that reset() always resulted in the first run having the lower ramp rate. This means it must be something in the instrument settings.
2. I created 2 config lists, MySourceList and MyMeasList
3. In the code, before starting the sweep, I added commands to save the current settings to those config lists: smu.source.configlist.store("MySourceList"), and the equivalent for MyMeasList
4. After running the function twice, to see the problem behavior, I opened the ConfigLists from the front panel. The front panel interface highlights what settings change between each ConfigList entry. There were no changes in the Source list, but the Meas list showed that on the second run, smu.measure.autozero.enable was set to smu.OFF, so it must've been on the first run.

A other few notes:

• You're setting "smu.source.autodelay = 1e-3", but smu.source.autodelay can only be on or off. Do you mean to be setting smu.source.delay to 1e-3? Right now you are turning autodelay off, but keeping smu.source.delay at 0.
• You are measuring twice at each sweep point with smu.measure.read(), your code accounts for it, I'm just curious why?