Bradley Odhner

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