What's the best way for reading this binary file?

[Danigno]

I've written a program that acquires data from a DAQmx card and writes it on a binary file (attached file and picture). The data that I'm acquiring comes from 8 channels, at 2.5MS/s for, at least, 5 seconds. What's the best way of reading this binary file, knowing that:

-I'll need it also on graphics (only after acquiring)

-I also need to see these values and use them later in Matlab.

I've tried the "Array to Spreadsheet String", but LabView goes out of memory (even if I don't use all of the 8 channels, but only 1).

LabView 8.6

[Dennis_Knutson]

Since you are using Write to Binary File, use the Read From Binary File with the correct data type wired to it. There is a shipping example called Read Binary File that will give you a start.

Also, as mentioned in this response on your original question, you really need to save the scaling coefficients and timing data either as a header or at the end of the data file. As it is, you are throwing away a lot of information.

Message Edited by Dennis Knutson on 11-13-2008 07:51 AM

[DFGray]

You probably want to set the prepend array info input to FALSE in your save data.  This will give you a flat file structure, making it easier to retrieve pieces of it.  You currently have a clumped file structure with each chunk having a small header giving the number of points (and data type, if I remember correctly).  This is easy to read the way you wrote it, but much harder to get arbitrary pieces out of.

[Danigno]

But my real problem, at least now, is how can I divide the information to get not only one graphic but eight?

I can read the file, but I get this (with only two channels):

So what I tried was, using a for loop, saving 250 elements in different arrays and then writing it to the .txt file. But it doesn't come right... I used 250 because that's what I got from the graphic: at each 250 points it plots the other channel.

Am I missing something here? How should I treat the information coming from the binary file, if not the way I'm doing?

(attached are the .vi files I'm using to save in the .txt format)

(EDITED. I just saw that I was dividing my graph's data in 4 just before plotting it... so It isn't 250 but 1000 elements for each channel... Still, the problem has not been solved)

Message Edited by Danigno on 11-17-2008 08:47 AM

[TCPlomp]

My advice,

TDMS

Maybe another option

TDMS

It let you store the data directly and fast to disc, LabVIEW provides a very good example of how to read these files, and you can store metadata directly with the data.

Ton

[Danigno]

Isn't it faster to write binary files?

If so, that's what I need, because it's more important to acquire data as fast as possible than dealing with it fast later (I just have to be able to deal with it later...)

[TCPlomp · Accepted solution]

I think the data access is just as fast, what happens in a TDMS file is that an index generated in the TDMS file that says 'at byte positions xxxx data yyyy written' that is the only overhead for TDMS files as far as I know.

We had never issues with data storage. Acquiring data, analyzing and storing with >500 ks/s, the issues you normally get are most of the time a result of bad programming styles.

Ton

[DFGray]

As I mentioned in the other thread referenced above, for this type of data storage (small number of high count channels), binary is fastest, HDF5 follows at one or two percent slower, TDMS is next at 10 to 15 percent slower.  At higher channel counts, TDMS and HDF5 switch positions.

[Danigno]

But I'm using TDMS not because it was the fastest, but because it could acquire data with 2.5MHz 🙂