Matt Payne

So shortly after I was tasked with additionally gathering current readings for the duration of the test, which further prompted me to go the trigger model route. Here is my current code:

function config_current_trace()    

smua.measure.rel.leveli=0     
smua.measure.count=5000     
smua.measure.interval=0.0001    
smua.measure.autozero=smua.AUTOZERO_OFF 
smua.measure.nplc=0.001 
smua.measure.autorangei=0    
smua.measure.rangei=1 

end 

function config_trigger_model(dio_line,v_test) 

smua.trigger.arm.count=1 
smua.trigger.arm.stimulus=0 
digio.trigger[dio_line].stimulus=smua.trigger.ARMED_EVENT_ID 
smua.trigger.source.stimulus=smua.trigger.ARMED_EVENT_ID 
smua.trigger.measure.stimulus=smua.trigger.ARMED_EVENT_ID 
digio.trigger[dio_line].mode=digio.TRIG_RISINGM 
digio.trigger[dio_line].pulsewidth=0.500000 
smua.trigger.source.action=1 
smua.trigger.source.linearv(v_test,v_test,1) 
smua.trigger.source.limiti=1 
smua.trigger.autoclear=smua.DISABLE 
smua.trigger.measure.i(responsebuffer) 
smua.trigger.measure.action=smua.ENABLE 
smua.trigger.count=1 
smua.trigger.endpulse.action=smua.SOURCE_IDLE 
smua.trigger.endsweep.action=smua.SOURCE_HOLD 
smua.trigger.endpulse.stimulus=smua.trigger.MEASURE_COMPLETE_EVENT_ID

end 

And then to execute the test:
1. Use standard LabVIEW VI's to set range and turn on source output.
2. Execute the test, using 24V and using digital output line 1:

config_current_trace() 
config_trigger_model(1,24.0)
digio.writebit(1,0) 
smua.trigger.initiate() 
waitcomplete() 
digio.writebit(1,0)

3. Use VI's to read buffer and reset.

And it works great! Same tight timing between the SMU and the NI DAQ, and very nice current trace that easily feeds into a peak detection algorithm to find the response bump. Very cool stuff, thanks again for your help and if you see anything that could be done better, feel free!

 

Another update, I was able to improve the delay to about 80-90µs by manually setting the source range. Interestingly, it also seems to be the same delay no matter which order the function is written, DIO then source or source then DIO. Either way the source level is set about 87µs after the DIO line turns on. This is very acceptable!

My function is:

function response_test(dio_line,v_test,delay_s)
    digio.writebit(dio_line,1)
    smua.source.levelv = v_test
    delay(delay_s)
    digio.writebit(dio_line,0)
end

So to a 5V, 500ms test, the execution would be:

smua.source.rangev = 6
smua.soruce.output = smua.OUTPUT_ON
response_test(1,5,0.5)
waitcomplete() --not sure if I actually need this anymore
smua.source.autorangev = 1

Thanks again for your help, and if there are any further recommendations, I'm always open to improving!

Quick update, it seems that 3ms may just be the time it takes to set the voltage. Depending what order I put "smua.source.levelv = " and "digio.writebit()" in my function, I get different results. If I set the level first, the output comes on about 270µs later. If I set the output bit first, the source voltage doesn't rise until about 3ms later. So doing the former, we end up improving our results by about a quarter of a millisecond, but short of configuring the NI device for analog triggering, this looks like the best way.

Very interesting, and thank you for going through all the effort to try that out! I'm going to try and customize your example and see what I get because using the LabVIEW VI's to set up a remote trigger model, I still get a consistent 3ms delay between the digital output line turning on and the source output changing according to an oscilloscope. This is the equivalent set of commands:

smua.source.output = smua.OUTPUT_ON
smua.trigger.arm.count = 1 
smua.trigger.arm.stimulus = 0 
smua.trigger.source.stimulus = smua.trigger.ARMED_EVENT_ID 
digio.trigger[1].mode = digio.TRIG_RISINGM 
digio.trigger[1].stimulus = smua.trigger.ARMED_EVENT_ID 
digio.trigger[1].pulsewidth = 1.000000 
smua.trigger.source.action = 1 
smua.trigger.source.linearv(10.000000, 10.000000, 1) 
smua.trigger.source.limitv = 10.000000 
smua.source.delay = 1.000000
smua.trigger.autoclear = smua.ENABLE 
smua.trigger.initiate()
smua.trigger.arm.set()
waitcomplete()
smua.abort()

This results in a 1 second pulse of both the source output (at 10V) and the digital line which works perfectly with the rest of the test machine, but I always get a 3ms delay which is just too much. 40µs though would be great!

As for my previous question about triggering the actual source output going on or off, I think you make a good point that that is not the way to do it. That's just an old method we used on a previous machine that was driving parts with a simple op amp with a disable line, so we'd trigger the analog read off the signal to turn the op amp on or off. An SMU is a very different device, so it doesn't really make sense to do it that way.

In fact, all we really need to control here is the timing of setting the output level and the turning on of the digital line. If doing an off-response time test, we'd have the SMU already sourcing a voltage, so we'd just need to execute a synchronized digital line on and source voltage level to 0. If doing on response, the source output level would already be commanded to 0 so we'd just need to set the level to the test voltage and turn on the digital line, again at the same time. I don't think we need to control any of the previous state with this function, and actually would prefer not to so I don't have to change what I'm doing before.

So I am going to try and customize your example to execute a function that simply sets a voltage level and turns on the digital line and see what sort of timing I get there. Thank you again!

Thanks for the quick reply! The 2601B won't be doing anything else during this test, just supplying power to the part under test. The source can stay on until explicitly commanded off, especially if it simplifies things.

The trigger model sounds like what we'd want and I've been trying to figure it out. I think I have something that works, but it's a little different than what I was planning. It seems I can't command "smua.trigger.initiate()" without the output already on. So I can't actually trigger the output turning on, but I can trigger the output going to a level by doing a 1 step sweep which will probably be OK, it just feels a little clunky.

Is there any way to actually simply trigger the output enable?

Hi all. I am brand new to programming these instruments and can't figure out the best way to do this, so I'm looking for ideas from those more experienced than myself.

The situation:
In performing a response time test on a pneumatic valve, I need to synchronize the analog read of an NI DAQ device and the source output of a Keithley 2601B.

The setup:
The 2601B is being controlled over LAN by a LabVIEW program. A digital IO line from the 2601B is connected to the NI device (USB-6353) on a PFI line to act as a digital trigger to start the high-speed analog read. The steps are:

1. NI: Set up a triggered analog read task triggered by this digital line.
2. NI: Start task, wait for trigger.
3. 2601B: Set source output level via TSP command (pre-canned VI, "smua.source.levelv = X").
4. 2601B: Set source output on and set digital IO bit on in same command (modified VI, "digio.writebit(1,1)" and "smua.source.output = smua.OUTPUT_ON" sent in same TCP/IP command, separated by a return/line feed).

The problem:
Depending what order the commands in step 4 are written, there is an approximately 5ms difference in result which is way too much for this application. This suggests that even though the commands to turn on source output and turn on the digital line are sent at the same time, there's enough overhead in executing them that way to affect the result.

We need the digital line and the source output to go on at exactly the same time, or at least within maybe 1ms. I imagine there is an easy way to do this, I just am not familiar enough with all these commands to see it. Any ideas?