Andrea C

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">

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

The 6485 data sheet reports reading rate as fast as 1000/sec.<br> The footnotes give the measurement settings required to get these speeds.<br> But these outcomes would be for N measurements into the internal buffer.<br> Transfer across the bus to PC takes more time.<br> <br> You seem to be wanting to transfer each reading one by one to have speedy update on your LabVIEW.<br> This maximizes the overhead, so will be slower than the max possible of 1000/sec when streaming to internal buffer.<br> <br> If you can locate a voltage reading instrument with sufficiently fast reading rate, you could use that to monitor the 2V analog output from the picoammeter. &#160;You need something that can continuously stream data to the PC.<br> <br> A DMM6500 could be of help. &#160;Here is app note that details streaming using Python:<br> https://www.tek.com/en/documents/application-note/data-logging-power-profiles-wireless-iot-and-other-low-power-devices<br> <br> Here is a note on evaluating the speed of 6485 analog output to step changes of current. &#160;This is just to illustrate the usefulness of the AO:<br> https://www.tek.com/en/documents/application-note/how-fast-can-i-make-measurements-picoammeter<br> <br> &#160;