Andrea C

Again, looking into why these are not on tek.com manuals download site.

In meantime, it is attached here.

Can you post an additional image of the LabVIEW front panel for what values you are passing to the VIs?

There is an example and code listing in the PDF I attached in earlier post.
This app note is good too:

App Note showing trigger model use - production test - fast throughput

Even for transfer curve, “sweeping” both gate and drain with trigger model task can give fast test speed.
If wanting a drain bias condition rather than a sweep, just make start equal to stop and number of steps same as the sweeping channel (gate).  You’ll get an Ids at constant Vds for each Vgs value.

Sometimes you might want to do your own loop rather than use the trigger model sweep or list sweep.  So what you have implemented is totally reasonable.
But if you judge it is taking too long to execute consider some revisions.
With the code you have now, each time your Python function is called, a lot of commands are sent to the SMUs.  What’s in the Keithley_get()?  Even more commands for the measurements?
All that is consuming time.

step 1:  don’t execute setup commands needlessly.  Same for reset.  This costs time.
step 2:  make a “apply configuration to SMU” function.  Call it only when a setting is changing/prior to first run 
step 3:  make a run_it() function.  Maybe clear buffers, output on, trigger.initiate(), <determine done>, printbuffers, output off - Next DUT

If you install these functions in the runtime memory of the SMUs, then the amount of characters across the bus between Python and the instrument can be vastly reduced and your speed further improved. You just need to VISA write the name of your functions to execute the code on the instrument.  Big speed improvement!

I also encourage you to make use of tsp-link so that your Python code only needs connection to one instrument.  Over tsp-link you will have node[2].smua and node[2].smub rather than a second VISA session to an instrument.

Last on buffer size:  how many samples do you need?  In the rare case that nvbuffers are not large enough, you can allocate runtime memory to be an even larger buffer.  If you are getting past 100K samples to be transferred, take a look at binary xfer to reduce bus traffic for the data to PC xfer to again reduce time to do the task.
 

Hello,
The errors on PrInit usually indicate a basic communication issue between the computer running the ACS software and the prober.
Often times you need to set GPIB address or other parameters for remote operation of the prober.
I suggest to consult the Sentio Remote Commands manual for the setup info.
Also, sometimes using a utility application like VISA Test Panel or NI IOTrace to validate basic communication with prober prior to using ACS can be helpful.
 

Try setting up scope to trigger on CH1 level and connect the AFG output to scope CH1.  Perhaps have the AFG output simple square wave of similar amplitude to what you will use for DPT.  When able to capture that, move to the DPT waveform.

When the instrument reports value of 9.9e+37, it is indicating an over-range condition.

Since you are forcing voltage, is very odd to have a reported over-range for voltage as the voltage measure range will follow the source range.  For the sweep up to 5v, it should be selecting 20V range.

Try this:  reboot and do not yet connect from remote PC.  In local operation, the instrument will continuously update the V and I measurement to front panel.  Even with the output off (blue light not illuminated).  What voltage does it report?  Near to zero or over-range?

I notice your script is asking to use the sense HI and sense LO/4-wire connections for the voltage measurement.
Are those connected to the DUT?
Try setting it to 2WIRE.

How goes the project with the 4 SMU channels?

You can treat the A and B versions the same from command set standpoint.
Are you putting them on TSP-LINK and connect PC to just one of them?

For fast performance in the source + measure actions, using trigger model is way to go.
But this means place the data into buffers.
Most typically, the data is available when the trigger model task completes.
Your script/collection of commands could just print the data or you can have PC send a printbuffer() command.
So the task shifts to coordination of the 2600x trigger model with the PC/Python.

With the script writing feature of TSP, you can bundle the trigger model definition commands in a function that is loaded into runtime memory.  You can define parameters so that the function is flexible.  Also make a run_it() function.  Then your Python code does not have to send a lot of characters for each time you run it.

A couple comments and a file attachment that may help.
Example 3 in the attachment has some Python snippets and TSP code.

Comment 1:  if your model is 2636 without any letter suffix after, it does not support the smuX.trigger.xxx commands.
Comment 2:  check the readings/sec rate supported by the model for various settings (datasheet has them).  1 usec reading rates are way too fast of an expectation.

Are there C# examples distributed with the IVI driver?  How are those?
Does driver support 64-bit target?