Performance of GPIB (with Tectronix scope)

[GPIB Guy]

I have an ICS Electronics GPIB card and I'm using the Quick Basic
libraries that came with it to code a program that captures a section
of the displayed trace. The scope is a Tectronix TDS-210.

The first version of the program used the RS-232 port and I was
capturing 512 samples of the captured trace (out of a possible 2500
points). I am capturing thousands of traces in a sequential manner.
The throughput using the RS232 port was about 1 capture per second.
With the new code for the GPIB port, I can capture about 3 traces per
second. I was expecting a MUCH higher capture rate given that GPIB
has a stated transfer rate of at least 200k bytes per second.

So, my question is this: Is it typical that certain GPIB cards or
hardware has effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing within
the device (TDS-210 in this case) is incredibly slow?

 

[CFoley1064]

Subject: Performance of GPIB (with Tectronix scope)
From: GPIB Guy GPIB@Guy.com
Date: 4/28/2004 8:35 AM Central Standard Time
Message-id: <408FB31B.A9AB00BF@Guy.com


I have an ICS Electronics GPIB card and I'm using the Quick Basic
libraries that came with it to code a program that captures a section
of the displayed trace. The scope is a Tectronix TDS-210.

The first version of the program used the RS-232 port and I was
capturing 512 samples of the captured trace (out of a possible 2500
points). I am capturing thousands of traces in a sequential manner.
The throughput using the RS232 port was about 1 capture per second.
With the new code for the GPIB port, I can capture about 3 traces per
second. I was expecting a MUCH higher capture rate given that GPIB
has a stated transfer rate of at least 200k bytes per second.

So, my question is this: Is it typical that certain GPIB cards or
hardware has effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing within
the device (TDS-210 in this case) is incredibly slow?

Hi, GPIB Guy. GPIB and QuickBASIC together almost guarantee slower results in
IEEE-488. Here are some suggestions:

* I strongly recommend against running DOS in a window with GPIB if you're
trying to move things along. I know it can be done, but please don't.
Dedicate granny's old '486 which has been sitting in the attic for 5 years to
running your data acquisition setup alone as a dedicated DOS system. The days
where we had to conserve hardware because of cost/availability are long gone --
thousands of working PCs are converted to landfill every day. Make sure you
use at least a '486 with the ISA board. Faster clock speed won't affect ISA
throughput to the GPIB board, and it will act like an ankus on QB, getting it
to go faster.

* Since you've got QuickBASIC (lector emptor -- I've only got experience
programming GPIB with v.4.0 and 4.5), have you tried doing a compile? I'd stay
away from the dreaded "P-code interpreter" except for the debugging phase at
all costs. Also, doing a compile is a good check on some problems, depending
on how you massage your settings. Being in QB, you tend to forget the
satisfaction of a clean compile (and incidentally occasionally also forget to
save before exit -- ouch ;o).

* You've probably got some kind of ONERR statement available in your program.
If not, put one in there, and output *all* errors of any type to something.
Look at them. One of the annoying parts of QB is that you can set it up to run
just about anything, no matter how kludgy or error-ridden. A special note here
for memory issues if you're using 4.5 in interpreted mode -- the help facility
is a pig, and your ONERR might reveal some memory problems. Do a FRE
occasionally.

* Look at what's happening with the hardware dance on the other stuff in the
computer. DO NOT use disk access during data capture time, not even with a
RAMdisk (using the DOS disk access interrupt slows things down). You should
also avoid doing screen updates if you can help it (errors above can go to an
array like your data -- the error codes are integer, and you can look them up
after). The idea is that your ICS board is dancing with a rather slow, clumsy
elephant in QB. Use the ankus, make it so QB stays out of the way while you're
busy. GPIB boards timeout and have to resynchronize when the program takes too
long doing something -- that slows things down a lot.

* If you've got any anti-virus software running, lose it immediately. I doubt
there are many hackers out there waiting to prey on unsuspecting DOS systems.
The anti-virus software will see a DMA or IRQ and flag it just long enough to
check if everything's OK. That might be too long, giving you a bus timeout.

* Look at the hardware settings on your ICS board again. If you've bypassed
DMA access (the board I used had jumpers and DIP switches to set these things),
that could be your problem. You just might have to stop the boat and get that
DMA working. If there are conflicts on all DMA, you might have to remove some
other hardware from the PC or get another one.

This isn't a complete list, GPIB Guy, but it should get you started. If
you're looking for speed, try upgrading your drivers libraries for C. If you
use TurboC++ 3.0/TurboC 2.0 or M$ QuickC, you'll almost certainly get better
results.

Good luck
Chris

 

[CFoley1064]

Subject: Performance of GPIB (with Tectronix scope)
From: GPIB Guy GPIB@Guy.com
Date: 4/28/2004 8:35 AM Central Standard Time
Message-id: <408FB31B.A9AB00BF@Guy.com


I have an ICS Electronics GPIB card and I'm using the Quick Basic
libraries that came with it to code a program that captures a section
of the displayed trace. The scope is a Tectronix TDS-210.

The first version of the program used the RS-232 port and I was
capturing 512 samples of the captured trace (out of a possible 2500
points). I am capturing thousands of traces in a sequential manner.
The throughput using the RS232 port was about 1 capture per second.
With the new code for the GPIB port, I can capture about 3 traces per
second. I was expecting a MUCH higher capture rate given that GPIB
has a stated transfer rate of at least 200k bytes per second.

So, my question is this: Is it typical that certain GPIB cards or
hardware has effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing within
the device (TDS-210 in this case) is incredibly slow?

And, as always, RTFM (Read The Manual). I haven't used the TDS-210 with GIPB,
but I'm certain the manual will tell you what your maximum throughput will be.
Your limitation *is* the instrument, not the GPIB bus. Also, you might be able
to program the TDS to help you. That information will also be in the manual.

Feel free to email if you have any questions.

Good luck
Chris

 

[GPIB Guy]

Les Hammer wrote:

Is it typical that certain GPIB cards or hardware has
effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing
within the device is incredibly slow?"

Short answer is "yes".

I've seen incredibly great differences in GPIB speeds based on:
Language (BASIC was slow - didn't try QuickBasic)
Computer
GPIB Card
Instrument

Some set-ups could see a 50ms overhead just for an ID query.
(Try timing 100 id queries to get an idea of your command
overhead.)

That 200k bytes/second is a burst rate with a tail wind.
(Special set-up with some delays turned off.)

OTOH, 3 traces/second does seem a bit slow. You may see an
improvement with better hardware.

FYI:

I talked to a Tektronix support guy today and specifically asked about
the TDS-210 and the specs of the "trace?" command. Turns out that the
best that the 210 can do (and pretty much all Tek scopes) is to
transfer a complete trace in anywhere from 300 to 320 ms. I was told
that all Tek scopes behave this way when it comes to GPIB.

My own benchmarking reveals that when requesting trace down-loads of
variable lengths (from 32 to 2500 points) that there is a consistent
fixed delay of 250 ms (1/4 second). The data itself is tranfered at
between 8k and 12k points (bytes) per second. Basically I was able to
repetitively acquire complete single-channel traces of 2500 points at
the rate of about 1.9 per second. This is with an ICS Electronics
GPIB card (PCI) in a P-4 computer (2.6 Ghz) running Windows 98 and
running a compiled quick-basic program from the command prompt.

When I described my application (aquiring thousands of traces from a
custom piece of hardware where each sample is 512 points acquired from
a 10 us window) the Tek guy suggested I use a TDS 5000 ($7300) because
the 8 mb of trace storage capacity can be segmented to store the
traces in sequence and then I can dump or spool the data out of that
buffer.

 

[Sean M.]

"GPIB Guy" <GPIB@Guy.com> wrote in message news:408FB31B.A9AB00BF@Guy.com...

I have an ICS Electronics GPIB card and I'm using the Quick Basic
libraries that came with it to code a program that captures a section
of the displayed trace. The scope is a Tectronix TDS-210.

The first version of the program used the RS-232 port and I was
capturing 512 samples of the captured trace (out of a possible 2500
points). I am capturing thousands of traces in a sequential manner.
The throughput using the RS232 port was about 1 capture per second.
With the new code for the GPIB port, I can capture about 3 traces per
second. I was expecting a MUCH higher capture rate given that GPIB
has a stated transfer rate of at least 200k bytes per second.

So, my question is this: Is it typical that certain GPIB cards or
hardware has effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing within
the device (TDS-210 in this case) is incredibly slow?

Hi GPIB Guy,

Sometimes the instrument is the limiting factor, other times your
computer/GPIB card are the limiting factors. With some GPIB controllable
instruments, you can output all of the trace data (one or more axes) as one
stream, with a specific character separating the individual data points in
the stream (e.g. all 512 data points are output at once, with a comma
between the data for each point). With some other instruments, you have to
explicitly ask the instrument for each data point coordinate (e.g.
amplitude/time) individually (e.g. point 1, point 2, point 3......point
512). Asking for each data point individually can sometimes decrease the
data transfer rate. Also, the format by which you read the data from the
instrument (string, real, scientific, etc.) can affect the transfer rate.

Do you know if the Quick Basic libraries are reading the data in either of
the ways I've described above? Do you have access to the source code? (I've
worked with Basic, but not with Quick Basic).

Also, have you investigated whether a Tektronix data acquisition program
will work for you? Test equipment manufacturers sometimes write easy to
use data acquisition software and make it available with/for the
instruments. I just found something about Tek's WaveStar software here:

http://www.tek.com/site/ps/0,,60-12123-INTRO_EN,00.html

I hope that helps...good luck to you,
Sean

 

[GPIB Guy]

"Sean M." wrote:

Sometimes the instrument is the limiting factor, other times your
computer/GPIB card are the limiting factors.

I'm pretty sure that in this case it's the Tek scope that's the
limiting factor. A 2.6 Ghz P-4 computer isin't going to be a limiting
factor I don't think.

With some other instruments, you have to explicitly ask the
instrument for each data point coordinate (e.g. amplitude/time)
individually (e.g. point 1, point 2, point 3......point 512).

No - not in this case.

The TDS-210 can send the trace data to the computer as either ASCII or
binary. You can set the START and END data points (where the defaults
are 0 and 2500) and when you send the "trace?" command it will respond
by streaming the values in sequence (I think there is a 10 or 12 byte
header sequence first). The data is 8-bit (1 byte) per sample (ie
they are signed integer values).

 

[DarkMatter]

On Wed, 28 Apr 2004 21:03:35 -0400, GPIB Guy <GPIB@Guy.com> Gave us:

I talked to a Tektronix support guy today and specifically asked about
the TDS-210 and the specs of the "trace?" command. Turns out that the
best that the 210 can do (and pretty much all Tek scopes) is to
transfer a complete trace in anywhere from 300 to 320 ms. I was told
that all Tek scopes behave this way when it comes to GPIB.

My own benchmarking reveals that when requesting trace down-loads of
variable lengths (from 32 to 2500 points) that there is a consistent
fixed delay of 250 ms (1/4 second). The data itself is tranfered at
between 8k and 12k points (bytes) per second. Basically I was able to
repetitively acquire complete single-channel traces of 2500 points at
the rate of about 1.9 per second. This is with an ICS Electronics
GPIB card (PCI) in a P-4 computer (2.6 Ghz) running Windows 98 and
running a compiled quick-basic program from the command prompt.

When I described my application (aquiring thousands of traces from a
custom piece of hardware where each sample is 512 points acquired from
a 10 us window) the Tek guy suggested I use a TDS 5000 ($7300) because
the 8 mb of trace storage capacity can be segmented to store the
traces in sequence and then I can dump or spool the data out of that
buffer.

Quite informative material. This is very useful.

Thank you.

 

[GPIB Guy]

Dennis Knutson wrote:

If you need much faster data transfer rates than what the scope
or the GPIB board (you're using a very slow model, btw)

Heh. What's the point of having a "fast" GPIB card if the damn
instruments connected to it have such lousy latency or internal GPIB
instuction-handling characteristics? I'm getting burst data transfers
of between 8 and 12 k/second. That's pathetic - and don't tell me
it's the card's fault.

I would recomend a pci scope card. They are usually much cheaper
than a standalone scope as well.

The TDS-210 (and it's sucessor the TDS-1000 series) costs about
$1000. Show me a dual-channel PCI card capable of 1 or 2 giga-samples
per second capture (for the same price or less).

Actually, for the settings I'm using, 200 mhz sampling from each of 2
channels is the most I need, and I can even do with 50 mhz sampling @
8 bits.

But I still think the Tek scopes are a bargain for what they can do
compared to a dedicated PCI card. I had hoped their implimentation of
the GPIB was more speedy.

 

[Chris Carlen]

GPIB Guy wrote:

FYI:

I talked to a Tektronix support guy today and specifically asked about
the TDS-210 and the specs of the "trace?" command. Turns out that the
best that the 210 can do (and pretty much all Tek scopes) is to
transfer a complete trace in anywhere from 300 to 320 ms. I was told
that all Tek scopes behave this way when it comes to GPIB.

Our experience with other Tek models, I think fromt the 7000 series have
been entirely consistent with these comments.


Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[perfb]

FYI - re Tektronix 'Wavestar' - I have used this on Tek TDS/THS scopes,
and as far as I can see it is not 'built for speed'. It does a credible
job of downloading and archiving scope files, once one has deciphered the
cryptic interface. But as far as automating rapid i/o, I dont think it
can beat hand-coded software, BASIC or otherwise.

IMLE, data transfer specs are never really realized in real world apps
no matter what the application:
VME/VXI/PCI/GPIB/IEEE1394/RS232/USB1/USB2/IEEE802.11 etc.

fwiw, I would agree a dedicated NI PCI scopecard would most likely achieve the
fastest capture rate, but would not be less expensive than a TDS2xx/3xx scope,
esp when adding in Labview full system cost,
and software would be considerably more complex as NI canned apps are typically
very limited in functionality, and it takes considerable hair-pulling to
delve into their buggy libraries to get it to finally do what you want.

I have an ICS Electronics GPIB card and I'm using the Quick Basic
libraries that came with it to code a program that captures a section
of the displayed trace. The scope is a Tectronix TDS-210.

The first version of the program used the RS-232 port and I was
capturing 512 samples of the captured trace (out of a possible 2500
points). I am capturing thousands of traces in a sequential manner.
The throughput using the RS232 port was about 1 capture per second.
With the new code for the GPIB port, I can capture about 3 traces per
second. I was expecting a MUCH higher capture rate given that GPIB
has a stated transfer rate of at least 200k bytes per second.

So, my question is this: Is it typical that certain GPIB cards or
hardware has effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing within
the device (TDS-210 in this case) is incredibly slow?


Hi GPIB Guy,

Sometimes the instrument is the limiting factor, other times your
computer/GPIB card are the limiting factors. With some GPIB controllable
instruments, you can output all of the trace data (one or more axes) as one
stream, with a specific character separating the individual data points in
the stream (e.g. all 512 data points are output at once, with a comma
between the data for each point). With some other instruments, you have to
explicitly ask the instrument for each data point coordinate (e.g.
amplitude/time) individually (e.g. point 1, point 2, point 3......point
512). Asking for each data point individually can sometimes decrease the
data transfer rate. Also, the format by which you read the data from the
instrument (string, real, scientific, etc.) can affect the transfer rate.

Do you know if the Quick Basic libraries are reading the data in either of
the ways I've described above? Do you have access to the source code? (I've
worked with Basic, but not with Quick Basic).

Also, have you investigated whether a Tektronix data acquisition program
will work for you? Test equipment manufacturers sometimes write easy to
use data acquisition software and make it available with/for the
instruments. I just found something about Tek's WaveStar software here:

http://www.tek.com/site/ps/0,,60-12123-INTRO_EN,00.html

I hope that helps...good luck to you,
Sean

 

[legg]

On Wed, 28 Apr 2004 21:03:35 -0400, GPIB Guy <GPIB@Guy.com> wrote:

Les Hammer wrote:

Is it typical that certain GPIB cards or hardware has
effective transfer rates that are much below GPIB spec,
or is this a case where the command or instruction-processing
within the device is incredibly slow?"

Short answer is "yes".

I've seen incredibly great differences in GPIB speeds based on:
Language (BASIC was slow - didn't try QuickBasic)
Computer
GPIB Card
Instrument

Some set-ups could see a 50ms overhead just for an ID query.
(Try timing 100 id queries to get an idea of your command
overhead.)

That 200k bytes/second is a burst rate with a tail wind.
(Special set-up with some delays turned off.)

OTOH, 3 traces/second does seem a bit slow. You may see an
improvement with better hardware.

FYI:

I talked to a Tektronix support guy today and specifically asked about
the TDS-210 and the specs of the "trace?" command. Turns out that the
best that the 210 can do (and pretty much all Tek scopes) is to
transfer a complete trace in anywhere from 300 to 320 ms. I was told
that all Tek scopes behave this way when it comes to GPIB.

You must have some pretty interesting SW, to read and interpret these

traces for you.

I find it takes quite a while to figure out what a single trace is
really telling me.

Are you collecting this info for some other poor smuck to wade through
later?

If you're sorting for a specific event, you might find that the scope,
if properly set up, can find it. Then you've got a lot less info, but
it is closer to being relevent, and worth looking at.

RL

 

[DarkMatter]

On Thu, 29 Apr 2004 09:46:09 -0400, GPIB Guy <GPIB@Guy.com> Gave us:

Dennis Knutson wrote:

If you need much faster data transfer rates than what the scope
or the GPIB board (you're using a very slow model, btw)

Heh. What's the point of having a "fast" GPIB card if the damn
instruments connected to it have such lousy latency or internal GPIB
instuction-handling characteristics? I'm getting burst data transfers
of between 8 and 12 k/second. That's pathetic - and don't tell me
it's the card's fault.

I would recomend a pci scope card. They are usually much cheaper
than a standalone scope as well.

The TDS-210 (and it's sucessor the TDS-1000 series) costs about
$1000. Show me a dual-channel PCI card capable of 1 or 2 giga-samples
per second capture (for the same price or less).

Actually, for the settings I'm using, 200 mhz sampling from each of 2
channels is the most I need, and I can even do with 50 mhz sampling @
8 bits.

But I still think the Tek scopes are a bargain for what they can do
compared to a dedicated PCI card. I had hoped their implimentation of
the GPIB was more speedy.

"Their implementation"??? Da Bus is Da Bus is Da Bus...

The problem appears to be with their compilation of the data to be
sent.

 

[Dave Cole]

in article 20040428114805.15763.00000628@mb-m16.aol.com, CFoley1064 at
cfoley1064@aol.com wrote on 4/28/04 10:48:

Faster clock speed won't affect ISA
throughput to the GPIB board, and it will act like an ankus on QB, getting it
to go faster.
^^^^^

Pardon my ignorance, but what does 'ankus' mean?
TIA
DC