Andrea C

The 2182A data sheet has some hints in table labeled "System Speeds".
It has an entry indicating as fast as 40 readings per second over RS-232 at 19.2K baud rate.
But the footnotes indicate the various settings that need to be in place to attain those speeds.

Relative to your present settings, you may want to turn off the digital filter.
Also the nplc value is big contributor to time.  1 NPLC at 60Hz = 16.7msec per reading (assuming no other overhead).
The 40 readings per second would be at NPLC of 0.01 which may negate the benefits of a 7.5 digit nanovolt meter.

If you can wait for the N samples to be transferred to the PC after they have all been acquired, I'd say set the sample count to N and then issue ":read?" command.  N needs to be not larger than the buffer size which is ~1024 samples.
In the Triggering chapter of the manual, check out the figure 7-10 remote operation trigger model.  If sample count is greater than 1, the logic can quickly loop back to acquire another reading.  There is coding sample at end of that chapter.
 

Hello,

I do not happen to have a 2400 or 2410 SourceMeter.
But I used a DAQ6510 in a 2700 SCPI emulation mode to get close to same command set and behavior as your 2410.

The point of my file attachment was to show how to use VISA and the ReadSTB feature to know when the instrument has data for you.
Use of ReadSTB can allow coordination between the Windows PC side code and the instrument state.

 

When the SourceMeter is busy performing the sweep, most SCPI commands sent to the instrument during the active sweep will not be processed by the command parser until the sweep is completed.  This is normal/expected behavior for the product.

When a large number of steps is used or other factors that make the sweep take a long time, it becomes important to synchronize the PC code with instrument state.

It is not uncommon for customers to experience a VISA timeout on the attempted ReadString() after starting the sweep.  The default duration of VISA timeout is usually 10 seconds.
Moving ReadString to a separate thread will not resolve the underlying issue.

The way to work this out is to use the status system of the instrument.  The PC code can read status byte information from the instrument during the active sweep.  Just you need to setup some flags in the status system to give bit change signals such as when the expected buffer is full.  Often times this is called Service Request or SRQ.

I'll dig up a C# sample.

Most likely there is a syntax error in the SCPI command you are sending.

On these touch screen models like DMM6500, you can enable command logging in Event Log and have the instrument identify the offending command for you.

Here is brief video showing the process:
https://www.youtube.com/watch?v=cVU_C308EUc

Hello,

Also, the time allocated for the measurement, needs to be less than the Pulse Width.
As a test, set the smuX.measure.nplc = 0.001

This is the minimum allowed value for 2600X.

When you say you do not get all values:
Is the sweep completing?  Or is the sweep "stalling" because maybe there is a timing problem with nplc, pulse width and pulse period.

The print(smuX.nvbufferX.n) will indicate how many values are in the buffer.
Let us knw if expected number of readings are in the buffer, but you are not successfully transferring all the data.
I take it you using LAN connection now?

Hello,

Seems you are attempting to use NI VISA from multiple threads in C#.

Can you clarify which exact model of instrument you have?
Also, can you give us an idea of the operation you are attempting with that instrument.

Sometimes a multi-point sweep can take a long time to run and in that case it would be expected that attempts to read the information would not be processed until after the sweep operation completes.

This NI forum post seems to have some good info about using VISA from threads:
https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/What-is-the-difference-between-doing-a-VISA-read-asyncronous-vs/m-p/60673?requireLogin=False

As for speed of the source-measure sweep, pg 30 in the 2600B series datasheet gives an idea.

Max expected rate for source and measure operations into memory is 12000 per second.

The 2600A series will have similar capability.

In your pulse mode Python code, the pulse period would need changed to 83.3usec to attempt that 12K rate.

This is fairly common issue to coordinate the state of the Python code with the state of the instrument.

For the 200 point sweep, it clearly requires more time to conduct the sweep vs. the 100 point case.

The VISA session has a timeout parameter, in msec.  Default value is 10 seconds for most VISA versions.

If your 200 point sweep needs more than 10 seconds to complete, then is very possible to receive a VISA timeout from the VISA read following your printbuffer() command.

There are a number of strategies to deal with this.

One would be simply to set the VISA session timeout to a larger number.  Default is 10000 msec.
Downside of longer VISA timeout is that for real error conditions, it will take longer to raise the error.

Or introduce a time.sleep(seconds) on the PC side before asking for the data.

Alternately, it is possible to have the instrument assert an SRQ when the sweep completes and your Python can do status polling and ask for data only when the instrument signals that is has some ready for you.

Really depends on how fancy you want to get in the code.

From old forum:  https://forum.tek.com/viewtopic.php?f=263&t=143187

In general, the problem in the code was how the voltage sourcing SMU at input to the DC-DC converter was programmed.

Revised Python code for two 2450 attached.



 

Looks like this one found a work around:  https://forum.tek.com/viewtopic.php?f=617&t=142379