• RE: Update rate of K2450

    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
  • RE: Update rate of K2450

    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">
  • RE: Partial waveforms being generated

    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>
  • RE: How to use the status model on a 3706A

    <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>
  • RE: How to use the status model on a 3706A

    Hello Lars,<br> <br> See if the attached document helps.<br> <br> &#160;
  • RE: How to automate sweeping every 10 min

    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.
  • RE: How to use the status model on a 3706A

    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;
  • RE: Partial waveforms being generated

    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
  • RE: Real-time data acquisition: how to achieve high speed with Labview and the KEITHLEY 6485?

    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;
  • RE: Update rate of K2450

    <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">If I understand, you want to sweep or source a series of voltage values but do it from a Loop on the PC side where you send a command for each source level.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">And if also obtaining measurements, from your loop you are also sending commands to cause a current measurement to occur.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">You will have overhead and possibly some timing variation by the loop-based approach.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">Using TSP command set and Python, I have this code that does the loop and obtains a measurement.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">The measurements are sent to PC at the end (one bus transfer).</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">Duration at each source level is about 900usec. Scope shot image uploaded.</span></span></span><br> <br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">If I instead send each measurement one by one, the duration increases to about 3.6msec; I have set the integration rate to fastest and turned off autozero.</span></span></span><br> <br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">If you know source values ahead of time and can load them into a Source Config List, you can get faster operations.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">From datasheet for 2450, you can approach 1700 Hz Source-Measure rate at 0.01 NPLC.</span></span></span><br> <span style="font-size:11pt;"><span style="line-height:107%;"><span style="font-family:Calibri,sans-serif;">Look at the System Measurement Speeds table in datasheet (pg 10).</span></span></span> <pre class="linenums prettyprint">my_instr.write(&quot;reset()&quot;) my_instr.write(&quot;status.clear()&quot;) my_instr.write(&quot;errorqueue.clear()&quot;) MEAS_RANGE = 100e-3 cmd_list = [&quot;smu.source.func = smu.FUNC_DC_VOLTAGE&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.autorange = smu.OFF&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.range = 20&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.ilimit.level = &quot; + str(MEAS_RANGE), &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.delay = 0&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.autodelay = smu.OFF&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.source.readback = smu.OFF&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.measure.func = smu.FUNC_DC_CURRENT&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.measure.autorange = smu.OFF&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.measure.range = &quot; + str(MEAS_RANGE), &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.measure.nplc = 0.01&quot;, &#160; &#160; &#160; &#160; &#160; &#160; &quot;smu.measure.autozero.enable = smu.OFF&quot; &#160; &#160; &#160; &#160; &#160; &#160; ] &#160; &#160;&#160; for cmd in cmd_list: &#160; &#160; my_instr.write(cmd) &#160; &#160;&#160; &#160; &#160;&#160; #lets loop thru some source levels and measure speed with scope debug = 1 voltage_list = {} for i in range(0, 11): &#160; &#160; voltage_list[i] = i/10 print(voltage_list) &#160; &#160; &#160; &#160;&#160; my_instr.write(&quot;smu.source.output = smu.ON&quot;) for j in range(0,1): &#160; &#160; for i in range( 0 ,len(voltage_list)): &#160; &#160; &#160; &#160; my_instr.write(&quot;smu.source.level = &quot; + str(voltage_list[i])) &#160; &#160; &#160; &#160; my_instr.write(&quot;smu.measure.read()&quot;) &#160; #obtain a reading into the buffer &#160; &#160; &#160; &#160; #print(my_instr.query(&quot;print(smu.measure.read())&quot;)) &#160;# this will slow you down! &#160; &#160; &#160; &#160;&#160; &#160; &#160; &#160; &#160; &#160; &#160; #all done, turn output off my_instr.write(&quot;smu.source.level = 0&quot;) my_instr.write(&quot;smu.source.output = smu.OFF&quot;) #bring the data back from the buffer print(my_instr.query(&quot;printbuffer(1, defbuffer1.n, defbuffer1.readings)&quot;)) </pre>