Andrea C

Hi Matt,
Those are great observations.
For either approach, as your "resting state" can you have the SMU output (the blue light) on, but have it forcing 0V?
Then when ready for testing, command the digital IO and the source level to change to a new level.

If I measure the time required to turn the smua.source.output on and off wiht the source level set to 3V, I'm getting about 8 msec for that operation.
When output is off, the SMU is still actively sourcing and limiting according to the output off mode and settings.
When output is then turned on, the new settings have to be applied, and you are seeing some overhead associated with that.

In contrast, if the output is already on but at 0V, then changing the source level to a different level requires much less time.

Combining this info about the source output and my prior suggestion about using a function to reduce bus traffic, I'm seeing less then 40usec from the DIO changing state and the start of the SMU source level changing.

Some TSP code to illustrate the concept:

function config_smu(v_src, iLimit)
    smua.source.func = smua.OUTPUT_DCVOLTS
    smua.source.limiti = iLimit
    smua.source.rangev = v_src
    smua.source.levelv = 0   -- this is the resting bias level as soon as output is turned on
    smua.measure.nplc = 1
    smua.measure.delay = smua.DELAY_AUTO
    smua.measure.delayfactor = 1.0
end  -- function
 
function speed_test(dio_line, v_src)
    -- to run the configured setup
    digio.writebit(dio_line, 0)  -- make digio low state
     smua.source.levelv = v_src
    digio.writebit(dio_line, 1)
end  -- function
 
-- test our function
reset()
errorqueue.clear()
digio_line = 1
config_smu(2.5, 0.1)  -- config for 2.5V and 100mA
smua.source.output = smua.OUTPUT_ON
for i = 1, 10 do
     --speed_test(v_src)
    speed_test(digio_line, 2.5)
    delay(100e-6)
    smua.source.levelv = 0
   
end
smua.source.output = smua.OUTPUT_OFF

A screen shot from the scope is attached.

For sure, we can get the timing of the DIO and the sourcing more synchronized.
Is the 2601B doing anything else?  Any measuring?
Does the source level stay applied until you send new commands?

To have the best synchronization will require use of the trigger model.
Both the DIO output trigger and the source stimulus can be setup to use the same start event (or software assert).
With this approach you can get the synchronization to sub microsecond.
You can even deliberately time skew them if you wanted to trigger and then source a known amount of time later.

Before re-architecting the code for trigger model, you could most likely realize some time improvement by defining a function in the runtime memory of the 2601B.  Your LabVIEW code would need to use a VISA level write to call your function.  The function would issue the DIO, output on, etc like what you are doing now.  The time savings comes from requiring just a single bus command between LabVIEW and the 2601B.
The function execution would still sequentially carry out the lines of code.  But the command parsing from the bus is reduced to just once.

:SENS:FUNC "RES", (@101)
:SENS:RES:RANG 10000, (@101)
:ROUT:CLOS (@101)
:READ?

You can connect over LAN or USB.

Over LAN, you can use something like TightVNC to interact with the scope.

Other software approaches:
KickStart scope application
TekScope PC
TekScope Utility (free)
Python drivers
more

Very nice implementation.  Thanks for sharing!

KickStart does not offer relay control of that nature.  It supports conventional scanning of the two-pole channels on the multiplexer cards.

The internal web page has an application that provides a means to send commands to the instrument over LAN.
Our use our TSP Toolkit from vscode to send commands.

To do what you describe would require connection of the front terminal DMM to the 7702 card input or card sense so that you can measure between the two banks.  When wiring the channels, treat them as single pole and use only the HI or only the LO.
NOTE:  you will also have to manage channel 43 for the card sense to bank 2.

 

Try setting the source level and source limits before turning the output on.

Keep in mind, when using power limit, the current limit in use will be the lower of the limit.i value or the computed value from source v and requested power limit (watts).

If troubles persist, can you tell us more about the DUT error and the only if device disconnected observations.
Is device accepting power from SMU or is SMU sinking power from DUT?

KickStart can only scan the channels.
If ch1 has 5v and gnd1 and ch2 has 5v and 12v and so on.

Otherwise, you’d need some customized approach to try to measure between any two pins.
That is normally done with a matrix rather than multiplexing switch.

You need to assign the range command also to the channel.  Similar to what you did for the measure function.

The data sheet indicates:  
Maximum input: 250 Vpeak DC to 60 Hz sine wave; 10 s per minute at maximum input on mA ranges (one-sixth
duty cycle)

Maximum common mode voltage (DC to 60 Hz sine wave): Electrometer, 500 Vpeak; V-source, 750 Vpeak

You may want to mount some protective diodes.  See attached from our Low Level Measurements Handbook.
Or download a copy:  Low Level Measurements Handbook