Andrea C

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.

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.