Timeout error when synchronizing two SMU instruments for IV sweeps

[tsong241]

Hi LabVIEW experts,

Here is a detailed description of what my timeout problem is. I wrote a piece of LabVIEW codes to control two Keithley SMUs (2460 model) to do synchronized IV sweeps on two difference devices. I used the Keithley’s synchronous triggering mode to configure one SMU (let’s say SMU #1) as a synchronous master and the other as an acceptor (SMU#2). Then I ask SMU#1 to sense one device's voltage and current at 10 voltage sourcing levels (e.g., 0-1V). At each voltage sourcing level, I need SMU#2 to simultaneously run a different IV sweep starting from 0 to 0.6V on another device.

The following is my code logic. When SMU #1 does a voltage sourcing, it will simultaneously send a trigger to SMU#2 via the digit I/O cable and tell SMU#1 run a I-V sweep. After this sweep is complete, SMU#2 will send a trigger back to SMU#1 to notify the sweep is complete and then have SMU #1 moves to the next voltage sourcing point. I use a For loop to repeat the process until all the voltage sourcing points are done. The LabVIEW code appears to work fine when running in the highlight execution mode, but when running in the normal mode, a timeout error showed up right away. I used the NI I/O Trace program to check the LabVIEW communicate timeline with the two SMUs. The trace timeline showed that the acceptor SMU#2 received the SCPI commands earlier than the master SMU#1 which caused SMU#2 never received any trigger signal from SMU#1 and thus SMU#1 stuck there and a timeout came out. I tried to add wait function (time delay) on SMU#2 to ensure SMU#1 always received the commands first but it still did work. I wonder if there is a better way to handle this SCPI command racing issue. Any suggestions or feedback would be appreciated.  Attached is the LV code library including all the needed driver VIs from Keithley. 

Thanks!

[cstorey]

It looks like you are trying to implement the standard Keithley example for triggered dual SMU FET measurements from p70 of their manual - https://download.tek.com/manual/2450-900-01E_Aug_2019_User.pdf

This example SCPI code should work just fine. There are a few issues with your LabVIEW implementation.  The biggest is that you CANNOT read and write to two different instruments in parallel over a serial bus connection (GPIB, USB or Serial). The code is working in Code Highlight mode because the slowed execution is sending the messages to each SMU slow enough that there are no overlapping or garbled commands.  In your code you have created a race condition where either SMU12 or SMU2 could receive the commands first and then the SMU to be triggered is not ready when the trigger command is sent.  

You must address each instrument sequentially.  Send the configuration commands to the Slave, then Master, then send the trigger after both instruments are ready.  Once the trigger is send, wait on the *OPC? for just one instrument (whichever measures last according to your SDM trigger setup.  Then collect the data from each SMU sequentially.  

See attached example.  Its just a butchered version of your code making the VISA Write and Read sequential so that the bus isn't being abused.  You may want to revisit the dual *OPC? commands you are using, I didn't read your full trigger setup to be sure both instruments will respond properly to that querry.  I would just query one instrument since they should both terminate measurement at the same time.

Hope that helps,

Craig

[Jay14159265]

---

@tsong241 wrote:

Hi LabVIEW experts,

Here is a detailed description of what my timeout problem is. I wrote a piece of LabVIEW codes to control two Keithley SMUs (2460 model) to do synchronized IV sweeps on two difference devices. I used the Keithley’s synchronous triggering mode to configure one SMU (let’s say SMU #1) as a synchronous master and the other as an acceptor (SMU#2). Then I ask SMU#1 to sense one device's voltage and current at 10 voltage sourcing levels (e.g., 0-1V). At each voltage sourcing level, I need SMU#2 to simultaneously run a different IV sweep starting from 0 to 0.6V on another device.

The following is my code logic. When SMU #1 does a voltage sourcing, it will simultaneously send a trigger to SMU#2 via the digit I/O cable and tell SMU#1 run a I-V sweep. After this sweep is complete, SMU#2 will send a trigger back to SMU#1 to notify the sweep is complete and then have SMU #1 moves to the next voltage sourcing point. I use a For loop to repeat the process until all the voltage sourcing points are done. The LabVIEW code appears to work fine when running in the highlight execution mode, but when running in the normal mode, a timeout error showed up right away. I used the NI I/O Trace program to check the LabVIEW communicate timeline with the two SMUs. The trace timeline showed that the acceptor SMU#2 received the SCPI commands earlier than the master SMU#1 which caused SMU#2 never received any trigger signal from SMU#1 and thus SMU#1 stuck there and a timeout came out. I tried to add wait function (time delay) on SMU#2 to ensure SMU#1 always received the commands first but it still did work. I wonder if there is a better way to handle this SCPI command racing issue. Any suggestions or feedback would be appreciated.  Attached is the LV code library including all the needed driver VIs from Keithley. 

24

Thanks!

---

I have lots of experience using the 2400 series and LabVIEW to run transistor sweeps. You should check out how to use the built in Test Script Processing (TSP) in the 2400 series. This way the 2400 is responsible for the entire test and you don't have to run a super slow GPIB SCPI messaging control loop between the 2400 and the system controller computer (running LabVIEW). You can still use LabVIEW (or whatever language you want) to set up the script on the 2400 and collect the data during or after the sweep. Here is a reference:

https://download.tek.com/document/1KW-61540-0_Script_with_TSP_Application_Note_031121.pdf

[tsong241]

Thank you for the valuable input, Craig! I did not notice this FET measurement example until you pointed it out. I use SMU 2460 (its manual does not have this example) not 2450. Otherwise, I could have saved more time on the trigger model commands. I just compared the SCPI commands I wrote with this example and luckily I am on the right path except for the time out issue I encountered. I am going to following your suggestion and revisit my code. Hopefully, I can solve this racing issue.

[tsong241]

Thanks for the sharing, Jay! My application is not on transistor, but I would like to read through the TSP note you shared and see if I can get some clues from it.

[tsong241 · Accepted solution]

By following your suggestions, I rewired my block diagram and it did not fully solve the problem. But the revisit helped me identify multiple racing issues related Keithley's SCPI commands. The key issue is that I did not set the automatic reference measurement with my two SMUs in a proper manner. By default, the SMU instrument automatically checks the reference measurements after every measurement. This can cause some measurements to take longer than normal. This additional time can cause problems in sweeps and other test sequences in which measurement
timing is critical like my two SMU synchronization application. To avoid the time that is needed for the reference measurements, I disabled
the automatic reference measurements by adding one extra SCPI command ":AZER OFF" and the timeout issue disappeared. 

Thanks much for your helpful suggestions!