>> I'm trying to stream some data directly to arrays in memory (instead of the
>> disk), and I was wondering if anyone had come upon an efficient way to do
>> so. My problem is that:
>> 1. I have relatively high data rates (multiple channels at around 20kHz)
>> and it's not efficient to use the Build Array element to tack on data to my
>> buffer array (Since Build Array allocates a new memory buffer everytime).
>> 2. I could preallocate my memory needs using Initialize Array, ...
In <378D450C.CE250D39@austin.rr.com> Greg McKaskle writes:
>If you are using buffered I/O, it won't matter as much how much time replace
>array takes, and it doesn't take that long either.
^^^^^^^^^^^^^^^^^^^^^^^^^
I _think_ that's because when you pre-allocate storage for the
shift-register in your loop, that storage isn't truncated (released)
until you exit the loop even if you call Build Array within the loop.
That's the idea behind preallocating a shift register. Someone correct
me if I'm wrong.
>Another approach is to put off the consolidation of the arrays until the
>DAQ is completed.
If you're using National's DAQ drivers, you can even pre-allocate an
intermediate buffer for your A/D data. Data in the driver's buffer
is stored in U16 format, so it's more memory efficient than storing
it in the LabView application. There are two modes:
1) Allocate an intermediate buffer for the entire dataset. You can
still use indexes to move back an fourth within this data array. And
you can start reading the array from where you left off or from
any intermediate point.
In one application, I actually read this buffer twice. Once in
small blocks for displaying the data as it was collected (in
semi-real-time) and a second time in very large blocks for heavy
numerical processing. If you're doing this, one loop should be
inside the other so you don't mix up the pointers into this
"file" buffer. If you want to want to have _separate_ file buffer
pointers on the READ vi, that's okay too, but then you need to
declare that READ vi as "reentrant" so separate data spaces for
each instance of these READ vi's is established for independant
file pointers.
2) Allocate a ring buffer smaller than the entire dataset, then let
let LabView read out of this ring as the A/D hardware writes into
it. The catch here is that the size of the ring buffer must be
large enough so the A/D hardware doesn't overwrite it if LabView
gets too far behind.
If you really have a lot of data, then it many be best to write it
directly out to disk as it's collected and let the disk's driver
worry about concatenating it altogether (prehaps with LabView doing
some preprocessing on it). But this is a last resort. It also
requires a SCSI disk to be fast. An EIDE disk will suck up all the
CPU time from LabView causing it to be slow. Get the biggest Ultra-2
or Ultra-3 SCSI drive and controller you can buy and be sure not to
mix Ultra SCSI drive types on the same controller or it will demote
the controller's speed to your slowest SCSI device.
--
/\ Mark M Mehl, alias Superticker (Supertickler to some)
<><> Internet: mehl@IAstate.edu
\/ Preferred UUCP: uunet!iastate.edu!mehl
Disclaimer: You got to be kidding; who would want to claim anything I said?
