Varying Query Time for TDS 2024 B

[Dennis_Knutson]

Does the instrument have any other connection types that you can test? I'm thinking of either ethermet or serial. GPIB would be best if you had a controller available.

[bcmasters81]

Unfortunately all it has is the USB connection.  Earlier versions of the model were GPIB, and so the firmware within current models is/has a GPIB/USB adaptor, but physically all there is, is the USB port.

I posted this issue on Tektronix' forum and they suggested upgrading the firmware, which I did, no luck.  They've also said it might be the USB driver which might be old and slow (something about an ASIC), but they can't be sure, even having updated the firmware.  The forum is titled "TDS2024B Varying Query Rate via LabView"

Otherwise, I'm able to run 3 channels at 2500 points per channel with comparatively fewer glitches than 4 channels at 1100-1200 points per channel, so my suspicion is that it has something to do with the number of channels, and the overhead required per channel, rather than purely the amount of points being requested.  I'm using the tktds1k2k drivers (the blue, not the red/white) as you can see from the image of my earlier post, and I'm wondering as to why there is a "Read 2 Waveforms" VI, but not a "Fetch 2 Waveforms".  Fetches happen much more quickly than Reads, so if there was some way to do all of the fetches in a single call as opposed to four separate calls, this might be faster.  Is there some way using the Curv? command to request multiple waveforms rather than just one?

Thanks!

[bcmasters81]

Does anyone have any ideas on this?

[Joel-P]

Hello bcmasters81

I had an idea that it might be possible to increase the number of USB channels in order to increase our data transfer rate, however since the driver VI's that you are using communicate via DLL calls directly I was not able to implement it.

The only other advice that I can give is generic troubleshooting;

Swap USB ports.

shut down every unnecessary program running on the host pc in case this is an issue with slow execution.

remove any unnecessary code from your VI.

Modify any possible communication settings on the O-scope.

increase the priority of the LabVIEW program on your CPU via task manager.

etc.

From the Tektronix forum, it appears as though the USB communication may be running on a single channel and could possibly be an older version of USB and we could simply be using all of our available bandwidth based on the custom ASIC USB driver that they are using. Although the cyclical nature of this delay is still puzzling, my only current idea regarding the cyclical nature is that there is some underlying process on either the host PC or the O-Scope that is causing this delay.

I hope this helps.

Joel