Andrea C

What is your exact model and firmware level?  The response to a *IDN? command will tell us.

For the delay, are you talking about the stime parameter?  Or the delay inside the my_wait_complete().
Of course, if the my_wait_complete() loop rate is very slow relative to the speed of the Source-Measure sweep, then it will be slow to detect the exit condition.  In the sample as posted, it uses 50msec loop rate.

What parameter values do you use when calling the ExitCondition_SweepVLinMeasureI(smu, startv, stopv, stime, points, current_limit, lowest_range) function?
And at appx what voltage and currents are you expecting the exit to occur?

Keep in mind, during the active trigger model sweep and during the my_wait_complete() loop, attempts to interact with instrument from the PC will be blocked.  This is why the logic of an exit condition is moved into the TSP code.

As for ACS, it is doing a for/next loop and able to check for compliance at each iteration.  These are implemented as functions in the TSP runtime memory on the instrument so there is no required bus traffic to the PC for each iteration of the loop to decide about exit condition.

 

Should Sense HI also be guarded?  Ideally, yes.

In concentric conductors like a triax cable, is easy to envision the minimization of leakage currents from the signal on center pin if the next layer inner shield is driven at same potential by the guard.  No delta V = no current.
This is one motivation for guarded cable especially for the Force HI.

But guarding has additional benefit of smaller effective RC time constant if the coupled capacitance between the layers does not have any charge up requirements.  This would be the reason to also guard the Sense HI line.
The input R of the Sense HI is typically > 10GΩ

For long cables, you might find some settling time benefit by guarding depending on the speed of your IV curves, size of dV steps, etc.

Looks like your Python code was written for different product than the model 3706A.
You are sending SCPI syntax commands.
The 3706A is TSP command set only.

:SENSE:FUNC "VOLT:DC"  becomes dmm.func = dmm.DC_VOLTS

See if the attached Getting Started document helps you.

In KickStart, the AutoZero check box control results in turning it ON or OFF (dmm.autozero = dmm.OFF).

It is not using the auto zero once setting.

In addition to the 2450 related accessory, the 1100V model 2470 has similar one:  2470-1100V-BAN.

I see no reason not to operate them in reverse, e.g. plug the banana into rear of 2410 to present triax.

Take note on how the LO and Sense LO are handled if intending to use 4-wire connections.

Info about 2470-1100V Accessories

The male triax ends are mechanically compatible with the rear panel HV triax connectors on model 2470.
But they are also compatible with our more legacy triax such as the 237 related barrels, tees, 7078-TRX-x, CS-630, etc.
You may need some 237-TRX-BAR barrel connectors.

 

So, your terminal 4 is not at GND potential?<br> How big might the voltage at terminal 4 become?<br> <br> I do think you will need a floating amp meter where the LO is not shared with other SMU in 4200.<br> An external 2400 or 2600….. or even Amps terminals of a DMM depending on the values of current.<br> <br> Can you use known small resistor between terminal 3 and 4. &#160;Use a SMU at each terminal too.<br> Both SMU force 0 Amps and measure V. &#160;Your current is (V3-V4)/R<br> <br> A third SMU sweeps V at terminal 1.<br> Terminal 2: &#160;GNDU or use a SMU to force 0V and measure the current flowing into the SMU. &#160;Be sure to set the current limit high enough for all the current that will arrive.

See if this helps. &#160;The code should apply to any 2600A or 2600B.<br> https://forum.tek.com/viewtopic.php?f=224&amp;t=142633<br> <br> &#160;

Try turning on the high capacitance mode.<br> smua.source.highc = 1

Hello,<br> <br> I'm not sure if a bug or feature.&#160; But I have opened a formal &quot;issue&quot; in our quality tracking system.<br> My expectation was that we should be able to turn off the delays even if it is likely to wreck your data quality.<br> <br> As for the 300msec that is imposed for use of the most sensitive ranges, it is a reasonable number.<br> If operating in the nA levels, is reasonable to assume there are GΩ of resistance.<br> As for estimating the capacitance, is easy to envision 100pF from a few feet of cable.<br> At 1GΩ and 100pF, the RC time constant is 100msec.&#160; For settled readings, is not uncommon to wait 5 time constants.<br> It really depends on the setup and particular goals.<br> Keep in mind, when the voltage steps from one value to the next, a displacement current is generated in proportion to the C and the step size and edge speed ( I = C * dV/dt).&#160; The delay is targeting enough time to have a reasonably steady state measurement.<br> <br> I will mention our 2600B series have more flexible trigger models.&#160; By this I mean it can measure&#160;Asynchronously from the sourcing action, so you can capture the transient displacement currents as the voltage is stepped.<br> Here is a post from our old forum on the topic:<br> <a href="https://forum.tek.com/viewtopic.php?f=14&amp;t=142669">Async measuring and sourcing - 2600B</a>&#160;<br> <br> Andrea

What is your firmware level?&#160; I've been using 1.7.12b on my 2450 SourceMeter.<br> <br> If source delay is zero and auto delay is off, my understanding is that there should not be any current range dependent timing.<br> Of course, if using sensitive ranges where settling time is likely to be required given the RC time constants, operating the instrument this way can easily result in unsettled measurements.<br> <br> I used the same code but add a command to set the smu.measure.count equal to three, and use the relativetimestamps differences to get an idea about how fast the instrument is going.<br> So readings 1 through 3 are at source level 1;&#160; readings 4 through 6 are source level 2, etc.<br> <br> Regardless of range, the delta in timestamps for readings obtained at same source level is about 320usec.<br> But when comparing the timestamps from before and after a source level change, we have to expect some larger amount of time for the sourcing action to take place.<br> However, I also see that the amount of time in those time stamps does vary with the current measure range setting and for the 10nA and 100nA ranges it is about 300msec.&#160; But for 10uA and higher ranges, the delta timestamp is about 900usec.<br> <br> Timestamp delta for after src change to before src change:<br> print(my_instr.query(&quot;print(defbuffer1.relativetimestamps[4] - defbuffer1.relativetimestamps[3] )&quot;))<br> <br> <img alt="" src="https://fortive.box.com/shared/static/l5ikdfyii7iel6yjzbjd03g5d06wwj5d.png">