Andrea C

Yes, that can be done.

In general, follow the Guidelines for combining SMU outputs in the Reference manual (section 2).

For two current sources in particular, make sure to have the voltage compliance limits a little bit different from each other.

To have same timing behavior from each SMU, use same ranges and other settings on each.

Also, sometimes the order of starting their trigger models matters.  For example, if SMUB is consuming an output event from SMUA to get things started, make sure to call the trigger initiate for SMUB first so that it can be fully armed and awaiting the events.

Are you using a fixed source range?  If the source range is also using auto, then the discontinuity could be for the hand-off of 200mV to 2V range as you sweep to 250mV.  A source range can go to 101% of its full-scale value.

For the data in the buffer, look at the measurerange and sourcerange attributes.  And perhaps post a CSV with your I, V, timestamp and the range information.
Try setting the smu sourcerange to a fixed value that can handle all the desired source levels (2V in your case).

When was last time your instrument was calibrated?
 

The CVU can source the DC bias at both CVUHI and CVULO.
To put the bias tees into CV mode, source -10 at each terminal from CVU.
The blocking cap of the bias tee will prevent this -10V from reaching DUT;  instead the bias from the SMU passes thru.

You are writing custom code to control it all?
Our ACS or ACS-Basic software has HVCV libraries for this configuration.

Depending on the connection rule in use, when moving to next channel in a scan, the opening of prior channel and closing of next can occur simultaneously or can be configured for break before make, etc.

In general the scan is just closing, measure, open/close next channel, measure, etc.

Since a measure function is associated with the scan, the instrument will also manage the backplane relays to connect the switch to the internal DMM.

Measure count of 10 would give 10 individual readings in the buffer.
To obtain an average, you could use a digital filter.  The instrument has both moving and repeating average filter.
Or there are buffer statistics that you can query to obtain mean, std dev, etc.

Yes.
Next to last page of data sheet lists the PC recommendations/requirements.
Windows 11 is supported.
Datasheet

In event log on the instrument, try turning on command logging.
Sounds like a syntax error.
Video on command logging:  https://www.youtube.com/watch?v=cVU_C308EUc

Or try NI IO Trace to see what is happening on the bus.

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))"))