Profile · Tektronix Community

Date/heure d'adhésion : 02/10/2022

RE: Update rate of K2450

Wed, 31 May 2023 15:40:23 GMT – Update rate of K2450

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. Here is a post from our old forum on the topic: <a href="https://forum.tek.com/viewtopic.php?f=14&t=142669">Async measuring and sourcing - 2600B</a>  Andrea
RE: Update rate of K2450

Wed, 24 May 2023 14:36:19 GMT – Update rate of K2450

What is your firmware level?  I've been using 1.7.12b on my 2450 SourceMeter. If source delay is zero and auto delay is off, my understanding is that there should not be any current range dependent timing. 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. 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. So readings 1 through 3 are at source level 1;  readings 4 through 6 are source level 2, etc. Regardless of range, the delta in timestamps for readings obtained at same source level is about 320usec. 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. 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.  But for 10uA and higher ranges, the delta timestamp is about 900usec. Timestamp delta for after src change to before src change: print(my_instr.query("print(defbuffer1.relativetimestamps[4] - defbuffer1.relativetimestamps[3] )")) <img alt="" src="https://fortive.box.com/shared/static/l5ikdfyii7iel6yjzbjd03g5d06wwj5d.png">
RE: Partial waveforms being generated

Mon, 22 May 2023 12:04:20 GMT – Partial waveforms being generated

Adding additional information:  If the SEQ option license is enabled, then the start of the waveform can be controlled by a WAIT event. For SCPI wait, when your software sends *TRG, the SCPI wait event is satisfied and the defined waveform will commence. <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

Wed, 17 May 2023 23:00:24 GMT – How to use the status model on a 3706A

When you say you cannot reset the status registers, can you elaborate? Is it that the status.condition register still has some bits at logic 1 but you expect 0?  Which ones/what is the value of the register? For example, if data is still sitting in the output queue (from print or printbuffer), the MAV bit will be set. 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. The status reset affects the enable and other writable registers.  The read only condition registers are not affected by status reset.
RE: How to use the status model on a 3706A

Fri, 12 May 2023 17:30:23 GMT – How to use the status model on a 3706A

Hello Lars, See if the attached document helps.
RE: How to automate sweeping every 10 min

Thu, 11 May 2023 19:14:26 GMT – How to automate sweeping every 10 min

At subsite level in the project, go to subsite setup and enable Cycle Mode. Then if you highlight the subsite when clicking the Run button, all enabled tests under that level will be executed once per cycle.  The data will appear at each test but rather than Append2, Append3, etc.  They will be cycle1, cycle2, etc. How to also have some pause for 10 minutes for each cycle? Do you have the compiler a the KULT tool is functional on your 4200? 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. NOTE:  on the new 4200A-SCS, the compiler is always there.  Older 4200-SCS, depending on vintage, needed it installed as an option.  Open the KULT tool from desktop icon and see if it complains or not.
RE: How to use the status model on a 3706A

Thu, 11 May 2023 18:55:50 GMT – How to use the status model on a 3706A

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

Mon, 08 May 2023 14:21:41 GMT – Partial waveforms being generated

Hi Howard, I've attempted to duplicate, but not seeing any issue yet. I've used the Burst mode and sourcing an ARB defined series of pulses.  Also used Burst mode and Pulse from the Basic mode. For me, on the scope capture, the first burst of pulses after turning the output on has the expected number of pulses. 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. Looks like we will need a little more information in attempt to duplicate the issue. Andrea
RE: Real-time data acquisition: how to achieve high speed with Labview and the KEITHLEY 6485?

Thu, 04 May 2023 23:08:47 GMT – 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. The footnotes give the measurement settings required to get these speeds. But these outcomes would be for N measurements into the internal buffer. Transfer across the bus to PC takes more time. You seem to be wanting to transfer each reading one by one to have speedy update on your LabVIEW. This maximizes the overhead, so will be slower than the max possible of 1000/sec when streaming to internal buffer. 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.  You need something that can continuously stream data to the PC. A DMM6500 could be of help.  Here is app note that details streaming using Python: https://www.tek.com/en/documents/application-note/data-logging-power-profiles-wireless-iot-and-other-low-power-devices Here is a note on evaluating the speed of 6485 analog output to step changes of current.  This is just to illustrate the usefulness of the AO: https://www.tek.com/en/documents/application-note/how-fast-can-i-make-measurements-picoammeter
RE: Update rate of K2450

Fri, 28 Apr 2023 15:02:59 GMT – Update rate of K2450

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

‹
1…
16
17
18
19
20
21
22
23
24
…28
›

Andrea C