TDS2024B and USB throughput rate VERY SLOW.

[SWGuy]

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]

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]

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.

[Buck]

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

[NathanielTagg]

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.

[BCM-CERL]

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!