Bradley Odhner

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?

Hmm, can you share your code?

How are you measuring the ramp speed? Looking at your image, the slope on all those runs is the same but runs 2+3 are starting at a higher current level so they reach the cut off point faster.

I would look at how you're determining the starting point for each ramp.

The 2612B and Lua 5.0 do support the '...' notation for vararg functions, though it works differently than in Lua 5.1. This is called out in the 5.1 documentation: https://www.lua.org/manual/5.1/manual.html#7.1 and described in the 5.0 docs: https://www.lua.org/manual/5.0/manual.html#2.5.8

I see that state machine code was written for Lua 5.1, so if you're using it directly that would be at least one of the reasons it's not working. Unfortunately I'm only familiar with Lua for TSP, but a dedicated Lua forum might help more if you're trying to adapt 5.1 to 5.0 script.

Always fun adapting other people's code! Let me know if you run into other issues.

Here's what I would do in TSP:

1. Since it's a 1kHz signal, you will need to use the digitizer to digitize the PWM signal voltage. Refer to page 4-31 of the Reference Manual to learn about digitizing if you're not familiar.
2. Configure the digitizer to measure some number of points, maybe 1M. This is the sample you will use to determine duty cycle. The digitizer measures at 1M pts. / second. The internal memory can hold a maximum 7M points.
3. Create a limit with dmm.digitize.limit1.high.value of say, 1V. We will use this to flag when the PWM signal is high or low. You could alternatively use dmm.digitize.limit1.low.value, but no need to use both.
4. Use buffer.make() to create a new buffer to hold your reading.
5. Use dmm.digitize.read(bufferVar) to make a measurement into your buffer.
6. Iterate through your buffer in a loop, tracking bufferVar.statuses to count how many readings were high/low based on limit1.
7. Use the count of high/low readings and the length of your measurement to determine duty cycle.

Some variation ideas:

• You don't have to use the limit method, you could take the readings and iterate through the buffer readings with greater than or less than operation to determine high/low.
• You might want to verify your method works through the front panel before routing through a switch card. It will work the same, but it can be easier to debug a method like this without worrying about channel settings.
• You could use the trigger model to set up your measurements. The trigger model provides the best response time if timing/speed will be an issue for your application. Though, the method I described will iterate through a buffer, there might be a less processor-heavy way of doing this that hasn't occurred to me yet.
• You could adjust the digitizer aperture with dmm.digitize.aperture if 1MS/s is too many samples for you. Thinking about it, you might want to, since 1MS/s might catch a bit of the PWM edge transitions on a 1kHz signal.