Andrea C

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,
I'm not sure if a bug or feature.
But I have opened a formal issue in our quality tracking system.
My expectation was that we should be able to turn off the delays even if it is likely to wreck your data quality.
As for the 300msec that is imposed for use of the most sensitive ranges, it is a reasonable number.
If operating in the nA levels, is reasonable to assume there are GΩ of resistance.
As for estimating the capacitance, is easy to envision 100pF from a few feet of cable.
At 1GΩ and 100pF, the RC time constant is 100msec.
For settled readings, is not uncommon to wait 5 time constants.  It really depends on the setup and particular goals.
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).
The delay is targeting enough time to have a reasonably steady state measurement.
I will mention our 2600B series have more flexible trigger models. By this I mean it can measure Asynchronously from the sourcing action, so you can capture the transient displacement currents as the voltage is stepped.   
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">

Adding additional information: &#160;If the SEQ option license is enabled, then the start of the waveform can be controlled by a WAIT event.<br> For SCPI wait, when your software sends *TRG, the SCPI wait event is satisfied and the defined waveform will commence.<br> <br> <a href="https://imgur.com/a/Eyq2lQA"><img alt="" src="https://imgur.com/a/Eyq2lQA" style="float:left;"></a><a href="https://imgur.com/a/Eyq2lQA"><img alt="" src="https://imgur.com/a/Eyq2lQA"></a>

<p>When you say you cannot reset the status registers, can you elaborate?</p> <p>Is it that the status.condition register still has some bits at logic 1 but you expect 0?&#160; Which ones/what is the value of the register?</p> <p>For example, if data is still sitting in the output queue (from print or printbuffer), the MAV bit will be set.</p> <p>Either VISA read the info or send a inst.clear() to clear old data in output queue and that will reset the MAV bit to 0.</p> <p>The status reset affects the enable and other writable registers.&#160; The read only condition registers are not affected by status reset.</p>

Hello Lars,<br> <br> See if the attached document helps.<br> <br> &#160;

At subsite level in the project, go to subsite setup and enable Cycle Mode.<br> Then if you highlight the subsite when clicking the Run button, all enabled tests under that level will be executed once per cycle.&#160; The data will appear at each test but rather than Append2, Append3, etc.&#160; They will be cycle1, cycle2, etc.<br> <br> How to also have some pause for 10 minutes for each cycle?<br> Do you have the compiler a the KULT tool is functional on your 4200?<br> If yes, you could make a simple routine that waits for the desired duration before returning control back to KITE for the cycles to continue.<br> <br> NOTE:&#160; on the new 4200A-SCS, the compiler is always there.&#160; Older 4200-SCS, depending on vintage, needed it installed as an option.&#160; Open the KULT tool from desktop icon and see if it complains or not.

Hello Lars,<br> <br> Are you saying it is not working for you?&#160; Or you just want to better understand it.<br> <br> I ran just the TSP portion from Test Script Builder, and I am seeing the SRQ annunciator on the front panel.&#160; So I conclude the Python status byte polling loop should be OK.<br> <br> Each of your functions that perform a scan, also make use of waitcomplete().&#160; This will cause the code execution to stall there until the scan finishes.&#160; This seems fine.<br> <br> If you want the SRQ notification on operation complete, the opc bit in status.standard register set &quot;feeds&quot; the ESB bit in the status byte.<br> <br> I would make minor chance to your code and instead use these lines to configure the status subsytem:<br> status.request_enable = 32 &#160; -- enable SRQ on ESB<br> status.standard.enable = 1 &#160; -- OPC bit in this register feeds the ESB bit<br> <br> The last thing your TSP script does is call opc();&#160; when that is able to report complete, the ESB bit will go to logic 1 and the SRQ will go logic 1.<br> The value of the status byte will be 96 or bit pattern 01100000 (in TSP use print(status.condition) to see value of status byte).<br> <br> &#160;

Hi Howard,<br> <br> I've attempted to duplicate, but not seeing any issue yet.<br> I've used the Burst mode and sourcing an ARB defined series of pulses.&#160; Also used Burst mode and Pulse from the Basic mode.<br> For me, on the scope capture, the first burst of pulses after turning the output on has the expected number of pulses.<br> <br> If just a single burst is desired upon a software command, you can config the AFG for External trigger source and send *TRG command to satisfy the external trigger.<br> <br> Looks like we will need a little more information in attempt to duplicate the issue.<br> <br> Andrea