Andrea C

I failed to notice in my first post that you have auto range for the current measure still turned on.
You are setting fixed source range and fixed measure range v, but the measure range i is not set, so will default to auto range on.  Is that correct?

That is most likely the reason for loss of synchronization and the one SMU getting stuck in the trigger model awaiting a trigger that it missed due to taking extra time during a range change that maybe other SMU did not do.

Are your two 2651A at the same firmware level?  If not, please do that.

For pulsing, it is generally not feasible to also have auto range enabled.  Need a time budget on pulse width vs time for range changes and repeated measurements.

For low measure ranges in effect and large capacitive loads such as a solar device, there can sometimes be source stability issues.
In that case, try restricting the measure range by using fixed range or use of smuX.measure.lowrangei = XX

There is a high capacitance mode you can turn on.
Sometimes, just going to higher ranges fixes things up without the use of high C mode.

If you do not need pulse mode, have long pulses or otherwise want to use current measure auto range, you can maintain synchronization by making sure both SMU have completed a measurement before sourcing next value.  To do it, use the meas complete event from node[2] as stimulus for a tsplink trigger.  Then on node[1], use an event blender to logically AND the node[1] measure complete event with the node[2] meas complete relayed over the tsplink trigger.
The event_id of the blender can then be used to influence when sourcing occurs.
In this case, typically use a second event blender to do logical OR of the armed event id (first src value) or the blender id serving up the combined meas complete events (subsequent src values).
Make this OR blender to be the stimulus for the sourcing action.

 

I’m not seeing any reason for loss of sync between the two 2651A.

I assume you are doing a tsplink reset.
And the armed event on one SMU is starting timers on both SMUs with tsplink trigger.

Why pulse mode?  At max 3A and half your 44V on each SMU, you could be DC.

Your end pulse action is to go to idle level.  I don’t see where you set that.  If zero volts, you are pulling Isc in between each pulse.  Try setting the smuX.source.levelv to 20V so that you move to a low current state in between each pulse.

 

The input buffer is ~2000 characters.  Strings larger than that in a single VISA write will cause the -363, Input Buffer Overun Error.

Ideally, myList could be computed/generated in the TSP Lua runtime within the 2600B scripting engine.
But if not possible for your use case, here is one way that a long array in Python can be populated into a table in the TSP side of things.

 

# in Python, build an array of values
record_length = 360   # how many datapoints to generate
cycles = 3 # how many sine cycles
length = np.pi * 2 * cycles
vector = np.sin(np.arange(0, length, length / record_length))

#send commannds to
# create an empty table, myList, on the 2600B
my_instr.write("myList={}")

#index through and write them on by one to table variable in the Lua runtime environment
#Lua uses 1 based index vs. zero based for Python
#myLuaArray[i+1] = PythonArray[i]
for i in range(0, record_length):
     my_instr.write("myList[" + str(i+1) + "] = " + str(vector[i]))

#print out how many elements we have loaded into myList
print("Number of myList entries: " + my_instr.query("print(table.getn(myList))"))

Sounds like you have a model 2450 SourceMeter.
You could use a triax shorting plug on the Force LO to connect the center pin to outer shell which is at chassis ground.
Keithley part number for shorting plug:  CS-1546
Info about CS-1546 Triax Shorting Plug

You do have the older 4200-SCS running the KITE software.
More than 10 years ago, we transitioned to 4200A-SCS and Clarius software.
Keep in mind, there is always an upgrade path.  Contact your local sales office for more information.

For repeated execution of an ITM, check out the Reference Manual on enabling the cycle mode.
I believe max number of cycles is 128.  When running the cycle mode, the ITM test results will have a tab for each cycle.
This is similar to having multiple append tabs.  But cycle mode relieves you of some button pushing.

If cycle mode is not enough cycles, you might be able to use the Stress/Measure cycling and just pick a benign stress condition.

Alternately, you could close the KITE GUI interface and instead use external command interface (KXCI).  And then from another computer you can send commands over GPIB or LAN to do the repeated IV curves and read back the data.
 

Does your SMU1 also have a 4200-PA?

In your pseudocode, you have a DV2 but no other parameters.  Is SMU2 playing a role in this setup?

If you run an ITM out of KITE for the voltage sweep on the 80KΩ, any clicking then?

Sounds like some range selection issues are going on with the clicking.
Especially if you have the 4200-PA, you could try using the RG command to exclude some of the lowest and most sensitive ranges.
Without a pre-amp, the 100nA and higher ranges are available from the SMU.

​​​​​​​

If the instrument is busy carrying out the sweep, then the VISA write of the "*OPC?" command is not processed until the sweep completes.  This is why the VISA read will timeout.

An alternate approach is to use VISA's ReadSTB() to obtain the value of the status byte or status.condition register.

I put an elaboration and Python sample in the attached document.

Hello,
The PDF is too large for attaching, so here is link to Box:

Reference Manual for the original 2600 models

The LAN communication can be applied from your router (DHCP) or selected manually.

Sounds like you have been using DHCP and the router is periodically giving new address?

Perhaps you can reserve an address in the router setup and manually configure the instrument to use it?

Appendix B-2 in the 2400 Series User Manual has the error codes.
NOTE:  this is not the touch screen models (2450, etc).

User Manual for 2400 Series SourceMeter