speed storing with LabView 6.1

[Andrea]

Hello!
I'm trying to acquire data and time as rapidly as possible. I used the
example VI "acq & chart" because it's a non-buffered acquisition,
hence is rapidly and it's able to save every point with its relative
time. But what's the rapidest mode to save? The data and times are
floating point numbers. I tried to convert them to a string, every
cycle I concatenate the string and at the end of the acquisition I
save it into a file. But I have a trouble: when the data number
exceeds 12000-15000, I think that labView don't store the string
correctly! Somewhere in the file the time value restarts from zero
value! L
If I convert the data into string and I save it every cycle, I don't
have the trouble with the size, but the speed decrease to
1000 points
pas seconds (in the other case the speed was 3000 point par second).
So, is it normal the trouble with string size?
How can I store rapidly my data? (nearly 100000 points)
Thank you for the help

Andrea

[markwysong]

If speed is what you are after, buffered acquisition is the way to go. Most time is spent opening and closing the file on the drive, so if you can do that minimal times, you can store more data faster.

The way I do it, is I use a buffered acquisition (like Continuous Acq & Chart.vi), and I append the time to the data that comes out of the AI Read VI. Let's say you have it return 3000 points, and your scan rate is 3000 samples/second. I then just create an array with a for loop, 3000 iterations, and add 1/3000 second for each iteration. You get a time stamp of 0, 1/3000, 2/3000, ....., 2999/3000. Next time through, add a second to the beginning, so you get 1, 1 1/3000, etc, etc. Then you write that to a file, and append to it on every iteration of
your AI Read.

That will write faster than any non-buffered acquisition.

Mark

[Dennis_Knutson]

Mark is absolutely correct about buffered acquisition being the best solution. There are a couple of other examples you might want to look at. One is Cont Acq to File (binary). Another one is Cont Acq to File (scaled). And the last one is Cont to Spreadsheet File. None of them include a time stamp but that is simple to add if you want. The fastest is the binary save. Instead of converting to text, you might try the binary save, You could also skip the time stamp and just write the start time and scan interval in a header. Because the scan interval is a constant, you could determine absolute or relative time when you post process the data file.

[Andrea]

Thank you for your answers. But i don't know if i can trust in labview
timing. I mean: when i doing a buffered acquisition, should i be sure
that every delay between the point is the same? Is there a log to
monitoring the real delay? On my way every cycle I acquire the data
and the time, so I think that possible delays are smaller and, what is
more important, they are independent. And if something arrive to the
pc and an extra delay occurs, I can watch it, so it's not a problem.

[markwysong]

Andrea,

I think you may be confused as to how buffered acquisition works.

When you set up a buffered acquisition, memory in the computer is reserved. The data acquisition then uses its own clock to acquire the data, and passes that data into the computer memory. This process occurs all in hardware, so you can be assured that the timing between each sample is the same to a very accurate degree, UNLIKE a non-buffered acquisition, where the computer just asks the DAQ board for the current value of a channel or channels. If the computer must take care of some other function, it stops getting data for a moment; in buffered acquisition, the DAQ card continues to stream data into memory, regardless if the computer needs to perform
another action.

Mark

[Andrea]

Ok, i'm convinced that it works. I've made some trials with a binary
buffered acquisition and i reached 3.04 microseconds delays between my
points. I can see a well sinusoidal graph by using a wave generator
with frequency of 30 KKz.
Thank you everybody for the help.
Ciao a tutti

Andrea