Bradley Odhner

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?

The electrochemistry scripts (including cyclic voltammetry) are not available by default for the 2450. They are included with the purchase of the EC-UPGRADE option.

The issue you're having is that the iterator of script.user.catalog() is a string, not the actual scriptVar. You can confirm this by running

for name in script.user.catalog() do
   print(name, type(name))
end

which will report each name as having the type 'string'.

So, we need to interpret the string 'name' as a variable name (i.e. ScriptVar). This is fairly simple to do but is not in the standard TSP documentation. It is part of the standard Lua documentation though.

for name in script.user.catalog() do
 print(name, _G[name].autorun)
end

_G is a table that holds the global variables of the instrument. _G[name] will return the object with variable name 'name'. So _G["ScriptVar"].autorun is equivalent to ScriptVar.autorun. You can read more here: https://www.lua.org/pil/14.1.html