DCSIMG

TDS2024B and USB throughput rate VERY SLOW.

Moderators: Buck, Hiker, notnomis, Super Mod

TDS2024B and USB throughput rate VERY SLOW.

Postby SWGuy on Thu Oct 22, 2009 7:41 pm

Hello -

My boss asks, "SWGuy, can you write something to grab data from the TDS2024 in the lab? It uses a USB link.."

Platform: Windows XP Pro SP3, USB 1.1 built-in, 512M RAM. Pentium 4 @ 1.8 GHz.

Compiler: Visual C++

VISA: TekVISA 3.3.3.4 (Good job on the install.. dropped right in, no arguments.. and the examples have all the DLL settings in the DSW file pointing to the right place).

Manual says to throw the 'scope into ACQ:STOPafter SEQuence mode then issue ACQ:STATE 1 commands to arm the trigger. Add *OPC? to that and voila! Read a '1' after the 'scope is done acquiring. Yes, a few other command need to be issued to get everything working.. but that's OK.

For example, I wanted to avoid messing with setting the USB timeout.. and so send *OPC? then viReadAsync() to sit in viWaitOnEvent() waiting for that '1' to appear. (By the way, does the channel need to have the VI_EVENT_IO_COMPLETION set for each use of an async read call? Or just once? Also, I don't recall reading anything about mixing asynchronous and synchronous calls (viReadAsync and viRead respectively).

Transmitting WAVF? retrieves everything. Some work with strstr() and I have the data.

But ... this... thing... is.. slow. Call Monitor says 1.6 seconds to transfer 2766 bytes on a USB 1.1 bus. Does it really take the 2024B that long to send binary data (DATA:WIDTH 1 and DATA:ENCdg RIBinary are sent during initialization) over the bus or am I mistreating the I/O system?

Your time is appreciated.
SWGuy
 
Posts: 3
Joined: Thu Oct 22, 2009 7:08 pm

Re: TDS2024B and USB throughput rate VERY SLOW.

Postby SWGuy on Tue Oct 27, 2009 12:25 pm

Hello -

Plenty of reads of the original post... but not one response?

Well, I'll try stacking commands up in the 2024B's buffer. Maybe that'll fix it.

SWGuy
SWGuy
 
Posts: 3
Joined: Thu Oct 22, 2009 7:08 pm

Re: TDS2024B and USB throughput rate VERY SLOW.

Postby SWGuy on Mon Nov 16, 2009 8:54 pm

Well, that didn't work.

Is the TDS 2024B a slow roller USB wise? I find it hard to believe the maximum data transfer rate is 1.6 seconds for a WAVF response.
SWGuy
 
Posts: 3
Joined: Thu Oct 22, 2009 7:08 pm

Re: TDS2024B and USB throughput rate VERY SLOW.

Postby Buck on Fri Nov 20, 2009 6:46 pm

Remote instrument communication isn't specified so I cannot comment on the performance.

Here are some things to try:
  • use single sequence (single-shot)
  • turn off headers
  • turn off all measurements
  • set data width to 1
  • set encoding to RIBinary
  • if you just need measurement data, use MEASU:IMM
  • use CURVE? to get waveform data without scaling information. good for multiple queries when you do not change your t/div or v/div
  • use abbreviated commands
  • use concatenated commands to minimize reads and writes
  • use a higher performance scope
Tektronix Application Engineer
AFGs & AWGs
readme.1st readme.2nd
Buck
 
Posts: 750
Joined: Wed Jul 30, 2008 11:45 pm
Location: Beaverton, OR

Re: TDS2024B and USB throughput rate VERY SLOW.

Postby NathanielTagg on Fri Jan 13, 2012 9:46 pm

I'm surprised that there hasn't been a more substantial reply to this.

I've been attempting to use Tek 1024/2024 scopes for cheap data aquisition. They do the job well, but the slowness is indeed an issue.

I am working with an input that has a typical trigger rate of ~10-20 Hz. It's no trouble to watch the screen of the scope update this quickly. But taking data via the USB port is much slower (~2 Hz). Although reading "CURVE?" data is slow (taking roughly 0.25 seconds), the biggest hit is actually setting up the trigger. Between writing "ACQ:STATE RUN" and getting single digit back from the *OPC? query takes something on order of 0.4 seconds.

Using "ACQ:STATE?" gives the same speed - usually there's a trigger queued up so fast that I don't have to ask twice - so clearly it's got something to do with run initialization on the scope end. Other queries (i.e. horizontal state) are much much faster.

Improving the speed of these operations would make this scope a killer DAQ system for educational purposes.

Incidentally: I'm using the TMCUSB interface on Scientific Linux, which is much simplier and easier to install than NIVISA (which I had problems with), and lets me program in C for more speed.
NathanielTagg
 
Posts: 1
Joined: Fri Jan 13, 2012 9:34 pm

Re: TDS2024B and USB throughput rate VERY SLOW.

Postby BCM-CERL on Thu Mar 08, 2012 6:28 pm

I agree.

I am using a TDS 2024B with LabView, and even if I am trying to just pull a measurement (i.e. 1 number, single precision), it takes half a second. This is through a USB cable on a reasonably fast Dell GX620 Dual core machine, using LabView 8.6. I can't fathom why polling for a single number takes this much time. Using a function generator, I send a 1 kHz pulse every second, so triggering of the scope is done directly from the function generator, and I simultaneously trigger the computer through the DAQ, which tells the oscilloscope to send the measurement number (in this case just the Vpp). I'd like to be able to do this as much as 10 times a second (10 Hz), but would be happy if I could do it reliably at 1 Hz. Usually when I pulse 30-40 times, there is usually at least 1 or 2 dropped measurements. Eventually, I will need to pulse over 100,000 times, and can't afford to lose upwards of 5% of my data!

I realize that the 2024's ability to save data to a *flash drive* may take some time, and that is reasonable. But the measurements are held in volatile memory and I can't understand why these numbers can't be polled faster. I believe the baud rate is 19200, which isn't super fast, but it's fast enough to send a single precision number, or an integer much faster than half a second. The LabView drivers offer a "Read" function and a "Fetch" function, the latter is the lower level and hence faster, but again, this isn't a lot of data, and it's insanely slow!

I feel like I am better off sending my signals into the DAQ directly have LabView analyze and compute, and deal with measurements that way, because you can do it faster than once every 2 seconds!

I'll be Tek's flavor of Signal Express is even slower, but I'll try it anyway.

If you are having this issue, the only way we can have it fixed is by letting the Tek folks know it's a problem.

Thanks!
BCM-CERL
 
Posts: 8
Joined: Fri Jul 23, 2010 12:58 am


Return to Oscilloscope Technical Support