Andrea C

Check the exact model of your SMU.
Is it the original 2612 release?  Or does it have 2612A or 2612B letter suffix.

It is only the A or B versions of the 2600x series that have the trigger model and the smuX.trigger.X commands.
It seems the Python driver you are attempting to use made use of those commands, therefore a 2612 cannot use the driver.
You would need to directly call one of the sweep commands of the instrument API (reference manual) or use a for loop in Python to program each source level and single measurement.

The TLINK connector on the 2182A is an 8 pin mini DIN style (google it).

The digital IO on the 2600B is on a DB25.

I'll upload some images for an obsolete accessory product that used to serve this purpose.
The one image has the pinout info for the mini DIN to DB25 connections.


 

You still get the full precision of the instrument according to the range and NPLC settings, etc.

The reason you are encountering range compliance even if current auto range is enabled is because the range change that would occur to get out of range compliance will not commence until you ask for a measurement.
When not connected over the bus to PC, the instrument does continuous init of new measurements in local mode.
But once you go under remote operations, that stops and you have to manage all the details.

I am not 100% sure if this will work:  After you source your new voltage value, you could query the value of the measurement condition register (read the value after this command:  :stat:meas:cond?).  Bit 14 will reflect in compliance or not state.  I'm not sure if both range compliance and real compliance will cause this bit to go to logic 1.  It might only be real compliance.

If using the more complex source-memory sweeps, there is the current range holdoff.
This feature sets the measure range = range needed for the current limit just before sourcing new voltage.
When creating the step change of voltage, there will be a displacement current (I = C * dV/dt) and the higher range gives best chance to not saturate due to current range.
Then it resumes use of the last used lower measure range for the measurement.
 

Since the task is structured as trigger model based source and measure into a buffer then transfer data to PC when all done, the speed of GPIB vs. LAN is not really a factor in my opinion.  The data transfer time is not affecting the speed at which the SMU can source a new value.

And even if the SMU can command a new source value quickly, the analog response to that should be considered and verified.

I suspect the rate limiting factor will be the speed of the sourcing action.
You indicate that it gets a little bit faster when you remove the measurement.

If you want to coordinate second SMU channel:

even though you just want a SMUB measurement for each sweep point in SMUA sweep, I'd still treat this as a "sweep".  Your starting V and stopping V for this SMUB sweep can be the same (bias condition) and you measure the SMUB current.

As SMUA goes through the trigger model, those same stimuli can be used as as inputs to the SMUB sweeping trigger model to keep the two SMU synchronized.

I've uploaded an image of a typical interconnected sweep for the two channels of a 2600B.
The logic gates are available "Event Blenders" and are configurable or OR or AND logic.
In this case, we AND together the measure complete event IDs from each SMU and use that output to control when sourcing occurs.

But to get the very first source value, we use an OR gate and allow the ARMED_EVENT_ID to cause the first source value and to start a measure delay timer.
Both SMU channels will loop until their trigger counts are satisfied.
Important:  as structured in this diagram, when arming these tasks, start SMUB first (smub.trigger.initiate()) so that it can fully arm and be waiting at the Source Event detector.  Then start SMUA.

All these interconnecting lines between the two trigger models are accomplished by TSP commands.

When the two SMU are on physically different chassis (two 2601B for example) then the SMU or Timer or Event Blender events can be "echoed" on the TSP-LINK for the remote nodes to consume.

Bonus info:  sometimes is helpful diagnostics to configure a digital IO line on the rear DB25 connector to strobe when certain event occurs.  This can provide a timing mark to feed a scope and you can see what the trigger model is doing vs. the analog behavior from the SMU channel.

​​​​​​​    -- digital output trigger for external equipment
    -- configure digital IO line 1 to output a active LO/falling edge
    -- pulse at start of each current pulse
    digio.trigger[1].clear()
    digio.trigger[1].mode = digio.TRIG_FALLING  --digio.TRIG_RISINGM
    digio.trigger[1].pulsewidth = 100e-6
    digio.trigger[1].stimulus = node[1].trigger.timer[1].EVENT_ID  -- change this according to your needs

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