Andrea C

A couple comments and a file attachment that may help.
Example 3 in the attachment has some Python snippets and TSP code.

Comment 1:  if your model is 2636 without any letter suffix after, it does not support the smuX.trigger.xxx commands.
Comment 2:  check the readings/sec rate supported by the model for various settings (datasheet has them).  1 usec reading rates are way too fast of an expectation.

Are there C# examples distributed with the IVI driver?  How are those?
Does driver support 64-bit target?

In meantime, can you use 4-wire RTD mode, but jumper the sense hi to HI and sense LO to LO at the DMM terminals and then connect your 2-wire sensor

Some info here:  2424L on tekwiki

Or try https://vintagetek.org

Need to set the dropdown to Forums:

Check out the free TekScope Utility.
TekScope Utility

Escope can be finicky with the older TDS3000B series scopes.  If you are unable to get a browser combo to work consider looking at TekScope Utility. 

Attached is a document that describes how to make use of the TSP functions and scripts from LabVIEW.
The LV driver for 2600x has a Load Script VI.

Great progress.  Let me give you some trigger model sample code to illustrate the very tight timing you can achieve.

Attached is a scope capture.
The digital IO have pull up resistors so will be at 5V or logic HI by default.  Looks like you want a rising edge trigger for your DAC board, so you've been using a mode command to change the DIO state.  The scope capture starts at that occurrence.

Subsequently, when the trigger model task is started, the DIO goes to 5V and the SMU goes to 10V.

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 config_dio()
    digio.trigger[1].mode = digio.TRIG_RISINGM
    digio.trigger[1].stimulus = smua.trigger.ARMED_EVENT_ID
    digio.trigger[1].pulsewidth = 1.000000
end  -- function

function config_trigger_model()
    smua.trigger.arm.count = 1
    smua.trigger.arm.stimulus = 0
    smua.trigger.source.stimulus = smua.trigger.ARMED_EVENT_ID
    smua.trigger.source.action = 1
    --smua.trigger.source.linearv(10.000000, 10.000000, 1)
    smua.trigger.source.listv({10})   -- single point list sweep is another way
    smua.trigger.source.limiti = 0.1
    --smua.source.delay = 1.000000
    smua.trigger.autoclear = smua.ENABLE
    smua.trigger.count = 1   -- set this equal to number of sweep or list points
    smua.trigger.endpulse.action = smua.SOURCE_HOLD
    smua.trigger.endsweep.action = smua.SOURCE_HOLD
end  -- function
​​​​​​​
-- **************************************************
-- use the functions
reset()
errorqueue.clear()
config_smu(10, 0.1)
config_dio()
config_trigger_model()
smua.source.output = smua.OUTPUT_ON

delay(0.5)  -- not needed....just allows us to see the dio setup of getting to LO state
smua.trigger.initiate()
delay(1.25)  -- not needed...just delay a bit before setting the SMU source level back to zero
smua.source.levelv = 0

 

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.