C Andrea

With 2400 or 2420, don’t think you’ll get there.
To have each measurement available on the PC essentially as they are available would require the PC controlling a loop.  But as you observe, loops can have timing variation and changes with CPU speed, etc.
The use of trigger model allows better timing determinism, but as you observe, the instrument cannot serve up data and carry out the list sweep.  It’s available only at completion of the sweep.

The 2450 and TSP could be pressed into using trigger blocks to have good timing control and run some code that prints the buffer data to output queue for pickup by a VISA Read.  Keeping it coordinated will be a consideration.  For example, if you do VISA read too frequently, you could get timeout errors that would need handled.

There is a nice app note and Python sample on our GitHub for data streaming from our DMM7510 of DMM6500.  Similar approach can be applied to 2450, albeit at much slower rates than the DMMs.

 

Maybe obvious, but this error means the 6221 does not receive the expected response from 2182A on the rs-232.

Double check the rs-232 settings are same in both instruments.
Then set LAN or GPIB the active interface on 6221.
Press delta button on 6221 and accept defaults.
Error?

Hi Niko,
See if the attached document helps with how to access Live Update feature on the graphical SourceMeter such as 2450.
Andrea

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.