• RE: DAQ6510 Labview - Faster Data Visualisation

    Hello John,&#160;<br> <br> There are a few ways to increase measurement rates.&#160;<br> <br> 1) Reduce NPLC.&#160;<br> 2) Use Autozero once or OFF.<br> 3) Use fixed range instead of autorange.&#160;<br> <br> You can find some of these subVIs on our LabVIEW drivers. Additionally, you can add those commands to your .VI, please review the reference manual for more information about remote programming:&#160;<a href="https://www.tek.com/en/keithley-switching-and-data-acquisition-systems/keithley-daq6510-manual/model-daq6510-data">Model DAQ6510 Data Acquisition and Multimeter System Reference Manual | Tektronix</a><br> <br> &#160;
  • RE: Real-time data acquisition: how to achieve high speed with Labview and the KEITHLEY 6485?

    Ali,&#160;<br> <br> Please review the following modified .VI<br> <br> I'm using FETCH:DATA? at the end of the test to save the full buffer after taking single readings with READ? and storing the buffer on the computer.&#160;<br> <br> Looking at the timestamps, stored on the I/O file, I'm getting a time between readings of 95ms, which is close to the programmed 100ms between reading.&#160;<br> <br> As for the first measurement being out of the expected value, this is due to transients when disabling Zero Check. Due to Zero Check being a switch that connects and disconnects the measurement circuitry from the input connectors, disabling it will generate that spike before the measurements settle.&#160;
  • RE: Real-time data acquisition: how to achieve high speed with Labview and the KEITHLEY 6485?

    Hello Ali,&#160;<br> <br> Please see the attached .VI.&#160;<br> <br> Real Time Data.vi uses the READ? command in a loop to trigger the instrument and get 1 reading at the time and displays it. This approach is not one I recommend for a few of reasons:&#160;<br> 1) Triggering the instrument every time you take a measurement will increase measurement time in the long run. Even though it's a software trigger, there is some overhead that will add up in the long run.&#160;<br> 2) At a fast-sampling rate, seeing the live data might be complicated as numbers are changing so fast.&#160;<br> 3) Because I'm getting 1 reading per trigger, I'm not using the internal buffer of the instrument, so you'll need to append your readings to an array or stored them somewhere else.&#160;<br> <br> 6485_FastestMeasurement.vi is a more standard solution where the data is stored in the buffer and requested at the end of the test, similar to the .vi you posted. In this case, using the instrument's buffer and only sending 1 trigger to initialize the test is preferable as you already loaded all the settings, and the instrument will keep running without additional stop-start steps.&#160;<br> <br> In the end, both approaches are doable. It comes down to your application needs.&#160;<br> &#160;
  • RE: Keithley 2450 non-equidistant samples

    I forgot to add something. In your test you are using Autorange (smu.measure.autorange = smu.ON). I recommend using a fixed range.&#160;<br> <br> Based on your graph, it seems that you cross the 100mA range and that's when your timing changes. Autorange will affect timing because the instrument has to &quot;figure out&quot; which range is best so it will take some time to adjust and then measure.&#160;<br> <br> In general, adjust your fixed range to the highest expected value so you don't cross it and get overflow.&#160;<br> <br> You can also use&#160;smu.measure.autorangehigh and&#160;smu.measure.autorangelow to restrict the possible ranges the instrument will check when using autorange. This will improve timing but it's not better than using a fixed range.&#160;
  • RE: Keithley 2450 non-equidistant samples

    Hello Paul,&#160;<br> <br> I tested your script and could not see any datapoint skipping time. However, I noticed that you are on firmware version 1.6.7c and I tested the script on 1.7.12. Please upgrade to the latest firmware version and let me know if you still have timing issues.&#160;<br> <br> Review the release notes for installation guide:&#160;<a href="https://www.tek.com/en/support/software/firmware/model-2450-firmware-revision-1712-and-release-notes">Model 2450 Firmware Revision 1.7.12 and Release Notes | Tektronix</a>
  • RE: VIRTUAL FRONT PANEL JAVA PROBLEM ON 2281S-20-6

    Hello Joan, 

    The 2281S virtual front panel is developed using Java. Due to security concerns, all internet browsers dropped support for Java based application. For that reason, we can no longer support virtual front panel operation for this unit.