rearm speed of s devices

[TJW]

I have an application where I need to monitor 4 channels
simultaneously at about 70 KHz for about two minutes. That should be
no problem except I need to monitor the data more or less real time
(i.e. within a second or two) as it is being generated. I think that
means I need to acquire a single sample from each channel and then
rearm in time for the next (hardware) trigger. Does anyone know the
overhead associated with rearming a 6123s (or similar s-series board
from NI)? Or is it possible to set up a buffered acquisition for the
full length of time needed and somehow get access to the data before
the acquisition has ended? I haven't purchased the board yet and can't
find this type of data on the NI site.

Thanks,
TJW

[Norbert_B]

TJW,

i think your question is based on a misunderstanding of the basic functionality of AI at a PC-based measurement system. This is quite common, so please don't take this personal
Well, if you want to acquire analog signal with a PC-based measurement system, you have to choose between two modes of acquisition:
a) single point
b) finite/continuous
As you can see, b) includes two (different) measurement methods, but they have one in common: both are buffered. But let's first take a look into a):
When a measurement is set to single point acquisition, you will retrieve one sample by interrupt, handle it and after that retrieve a new one. Since this is based on interrupts, your acquisitionrate is absolutly defined by your performance of the system. Commonly, rates of 1-15kHz are possible. There is only ONE purpose where you will NEED single point: controls like PLC.
If you want higher rates for your acquisition, you have to choose a buffered method. In your case, since you have a determined measuring time, you would choose finite. In a buffered measurement, the data is sampled with a sample clock and then transferred to the buffer. The buffer-size equals the number of samples for the finite acquistion or has a default size for continuous acquisition. 
Regarding the size of the buffer, you would have to choose a number of samples which equals your rate multiplied by time. In your case, this would be 70 kHz * 120 s = 8,400,000 samples. This will be one channel, so your complete data will take 8,400,000 * 4 * 8 Byte = 268.8 MByte. This is quite large, especially if the data is copied for your analysis perharps several times. But it is possible... If you don't want to have such a large array of data at once in your memory, you have to choose continuous acquisition and retrieve data during measurementtime and analyse "at runtime"..

Hope this helps,
Norbert B.
NI Germany

Message Edited by Norbert B on 07-31-2006 02:44 AM

[TJW]

Norbert,

Thanks for the lengthy description. (BTW, I think your calculation of
the buffer size is off by a factor of two for a 16-bit acquisition in
raw data mode but the buffer size really is not the issue here.) The
only reason that I mentioned buffered acquisition is that some devices
have dual fifo buffers that allow the user to grab data from one while
the digitizer is filling the other. I am assuming from your answer
that NI boards don't have this capacity.
Now getting back to the single point acquisition - you said about 15
KHz is the top speed. I assume that applies to the s series as well
because even though you may be acquiring multiple channels, the
transfer time on a PCI bus is clearly not the limiting factor at 15
KHz. At 100 Mbyte/sec (yeah, I know its never that fast, but that is
the supposed transfer rate on a PCI), it would only take 80
nanoseconds of actual transfer time to tranfer 8 bytes of data (4
channel * 2 bytes per channel). So most of the time is spent in
preparing for the DMA transfer (which I erroneously called
"rearming"). I have achieved 10 KHz using an AMD Athlon 2500+ system
with an Acqiris 8-bit digitizer but that means about 100 microseconds
needed for the DMA prep (again, the acquisition and transfer times are
insignificant). This is consistent with your 1-15 KHz number but seems
like a long time. Acquiris swears that they have achieved much faster
rates on a slower DOS-based machine - so it isn't just the speed of
the computer. Is it Windows or Labview (or both) that cause the
additional delay?

TJW

On Mon, 31 Jul 2006 03:10:08 -0500 (CDT), Norbert B <x@no.email>
wrote:

>TJW,
>
>i think your question is based on a misunderstanding of the basic
>functionality of AI at a PC-based measurement system. This is quite
>common, so please don't take this personal
>Well, if you want to acquire analog signal with a PC-based measurement
>system, you have to choose between two modes of acquisition:
>a) single point
>b) finite/continuous
>As you can see, b) includes two (different) measurement methods, but they have
>one in common: both are buffered. But let's first take a look into a):
>When a measurement is set to single point acquisition, you will
>retrieve one sample by interrupt, handle it and after that retrieve a
>new one. Since this is based on interrupts, your acquisitionrate is
>absolutly defined by your performance of the system. Commonly, rates of
>1-15kHz are possible. There is only ONE purpose where you will NEED
>single point: controls like PLC.
>If you want higher rates for your acquisition, you have to choose a
>buffered method. In your case, since you have a determined measuring
>time, you would choose finite. In a buffered measurement, the data is
>sampled with a sample clock and then transferred to the buffer.
>The buffer-size equals the number of samples for the finite acquistion
>or has a default size for continuous acquisition. You can get more
>infos on that <a href="http://zone.ni.com/devzone/conceptd.nsf/webmain/79087F996973863086256D250082713F?opendocument&amp;node=10119_us" target="_blank">here</a>.
>Regarding the size of the buffer, you would have to choose a number of
>samples which equals your rate multiplied by time. In your case, this
>would be 70 kHz * 120 s = 8,400,000 samples. This will be one channel,
>so your complete data will take 8,400,000 * 4 * 8 Byte = 268.8 MByte.
>This is quite large, especially if the data is copied for your analysis
>perharps several times. But it is possible... If you don't want to have
>such a large array of data at once in your memory, you have to choose
>continuous acquisition and retrieve data during measurementtime and
>analyse "at runtime"..
>
>Hope this helps,
>Norbert B.
>NI Germany
>Message Edited by Norbert B on 07-31-2006 02:44 AM

[Norbert_B]

TJW,

the issue of single point is, that everytime your program "hits" a read function, the program will create an interrupt, which is sent to the DAQ device, which will acquire the sample and sent the value back by another interrupt. So the transfer of the data itself is very fast, but you create a large overhead with the interrupts. Since the interrupts are handled by the OS, this will have a great impact on this for sure. Besides, even C-applications which are optimized for performance only succeed the 15kHz very hard under Windows (at least to my knowledge).
Regarding the "double buffer": You can find infos for this in the link i already posted in the chapter "Optimization for Continuous and Single-Point Operations".

Norbert B.

[Henrik_Volkers]

additional thought on your application:

you wrote, you want a 'real' - time monitoring.

assume your screen updates with 70Hz, so you can read 1k samples at once and while you get the next 1k you can start to display /save them

Now replace the 70Hz with 10Hz which is still fast for visual monitoring and you have 7k samples  BUT your screen has only 1024-2048 points to display

For 2min you get 1200 x 7k samples, so you probably can reduce one 7k block to 1 or 2 points in your diagram  (min/max/mean/whatsoever)

[TJW]

Thanks to everyone that responded to my request. All of it was good
information. But special thanks to Matt Otis at NI who took the time
to experimentally verify that 70 KHz is indeed possible. That's above
and beyond the call and a rare event in today's world of customer
service.

TJW