Bradley Odhner

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.

The 2612B already has Lua installed on it through the Test Script engine, you won't need to/be able to install anything on it, just add and run TSP scripts.

The TSP language is based on Lua 5.0 with a fair number of restrictions to prevent interference with the instrument operation, and custom libraries to facilitate instrument control.

There isn't a test bed that mirrors the 2600B engine (that I know of). You have the Reference Manual though, yes? https://www.tek.com/en/keithley-source-measure-units/smu-2600b-series-sourcemeter-manual-8
That details all the custom commands and covers the most common structures in Lua available.

If you're doing something more complex, I'd recommend the Lua 5.0 documentation. Many of the more complex features are functional on the 2600Bs, but libraries like io, os, and the C API will usually return errors.

When you say the SMU is not generating the specified voltage, do you mean the instrument is triggering properly but the output isn't what you expect? Or do you mean the SMU is not triggering at all?

First, I recommend using digio.TRIG_RISINGA (A for acceptor) for digio.trigger[1].mode instead of digio.TRIG_RISING. This sets DIO line 1 to TTL Low and waits for the rising edge of a TTL pulse.

1. Your code sets the SMU to trigger on DIO line 1. See page 4-38 of the Reference Manual (https://www.tek.com/en/manual/source-measure-units/model-2601bpulse-system-sourcemeter-instrument-reference-manual2601b-pulse-system-sourcemeter-10-sec) for a diagram of the DIO port. If you're using bnc from pulse generator, you want the outer shell connects to ground (pins 15-21) and the center connector connected to pin 1.

2. The digio.TRIG_RISINGA mode will look for the rising edge of a TTL High pulse. The pulse width is not relevant based on your code.

3. See page 4-40 of the Reference Manual for the hardware schematic of the DIO pins. They all have a 100 Ohm resistor on them. If you are using TTL pulses you shouldn't need to worry about impedance.

A fatal error is rarely related to the test setup. It can possibly happen if the instrument is connected to a setup that damages the SMU, but nothing of your description indicates a hazardous setup.

A few thoughts on your description though:

• The instrument is expected to show fluctuating voltage/current readings on the Home screen on startup. By default, the 2450 starts up into the Normal Output off state in Source V/Measure I mode. This sets the instrument to source 0V, and it reads V and I continuously. The instrument will go a low range with autorange and read/display noise.
• In general, connect your entire setup before turning the output on, I'm not sure if you did that based on your description.
• When performing a test like you described, where you're sourcing a voltage and not sure if you will see current, the current limit is very important. The current limit setting is in the bottom right of the Home screen, the default is 105mA. If current does appear across your sample, and it tries to increase beyond the current limit setting, the SMU will stop being a voltage source and instead become a current source; similar to how power supplies operate when they reach their max current setting. Decide the maximum amount of current/power you'd be comfortable going through your sample and set the current limit appropriately.

Do you get the same error with nothing connected?
If so, on a 2450 this is very likely a hardware problem and the instrument will need to be sent in for service: https://www.tek.com/en/service-quote

Did anything happen before the error message started showing up?