format of binary files incorporating multiple digitizer channels

[BrianK]

Hi,

I have a question about the format of the binary file created by the demo vi: "niSCOPE Multi Channel Stream to Disk Queues.vi" used with a a PXI-5105 digitizer.  As I understand that vi, and the binary file format employed in general by LabView, I should be able to read that binary file into another program by treating the LabView created binary files as a 16-bit signed integer data, no file header, little endian binary file.

When I use the single channel version of this demo vi "niSCOPE Single Channel Stream to Disk Queues.vi", I can easily read the data file as a 16-bit signed integer, no file header, little endian/low byte first binary file.

Binary files created by the "niSCOPE Multi Channel Stream to Disk Queues.vi" program are problematic for me to read, and I suspect an embarassingly simple solution is in front of me somewhere. I am recording two channels of data (channels 0:1). When I try to read the binary data file that program creats, my data reducting program has no difficulty reading the binary file, but the data from the two channels are clearly mixed up with each other.

If read the binary file assuming: 16-bit signed integer, no file header, little endian/low byte first, with two arrays of data in the file, and that the data from the two channels are not interleaved, I get two 'new' data files in my program, each with the right number of data points, but the first half of both 'new' files has the data from input channel 0, and the second half of both 'new' files has the data from input channel 1.

If read the binary file assuming: 16-bit signed integer, no file header, little endian/low byte first, with two arrays of data in the file, and that the data from the two channels are interleaved, I get two 'new' data files in my program, each with the right number of data points, but the first and third quarter of both 'new' files has the data from input channel 0, and the second and fourth quarters of both 'new' files has the data from input channel 1.

If I tell my program that there are actually 4 different data files in the LabView binary file, and that they are not interleaved, I get 4 'new' data files. However, in this case, 'new' files 1 and 3 appear to be data from input channel 0, and 'new' files 2 and 4 appear to be data from input channel 1, and all four 'new' files are half as many points as recorded. It seems that appending 'new' file 3 to 'new' file 1, and 'new' file 4 to 'new' file 2 will get me what I want. This is getting closer to what I want, but clearly I'm missing something here.

Reading the LabView binary file as if there were 4 files in it, and that the data are intleaved, I again get four files where the first and third quarters of the data come from input channel 0, and the second and fourth segments of the data appear to come from input channel 1.

So, I'm wondering if that multi channel demo vi assumes some number of recorded channels, regardless of what's selected on the front panel. Since I'm getting the correct number of data points reading the files, I suspect that the data are in fact being saved as 16-bit integers, a place to start.  Any suggestions how to read LabView binary data with multiple files in it?

Many thanks!

[cade]

Hello,

In order to better understand the situation, can you give more information about the program you are using to read the binary files created from LabVIEW? Can you also explain in more detail what you mean by your program assuming the data is interleaved or not interleaved? Is your program taking a single binary file and spliting it into two files of data?

Hopefully this information will further allow me to give a better answer for you.

Thanks! 

[BrianK]

Hi Cameron,

Thanks for your interest in my question. I am planning to use Igor Pro from Wavemetrics.com to read the NI binary files. It does an excellent job quickly manipulating very large data sets, which I expect the PXI-5105 to generate. Igor Pro has allowed me to quickly import all sorts of binary files over the years, the files generated by this particular vi are an exception so far. Within Igor Pro, I can tell the program the format of the binary file to read by specifying these seven parameters:

  data type: double float, single float, 8 16 32-bit signed and unsigned integer

  bytes to skip at the start of the file (header)

  number of arrays in the file

  number of points in each array: read a specific number of points, a range of points, or read until the end of the file

  format: IEEE, VAX

  byte order: high or low byte first

  are the points in the file interleaved?

For the binary files generated by the "niSCOPE Multi Channel Stream to Disk Queues.vi", I assumed that those binary files are 16-bit signed integer, no bytes to skip at the start of the file (no file header), two arrays in the file (I'm recording just input channels 0 and 1 on the PXI-5105), an unspecified number of points in each array, low byte first, IEEE format, and tried interleaved and not interleaved point order.

Since that did not work, I experimented adjusting the various settings, and some of the results I included in my first posting.

Many thanks for taking the time to consider my question!

regards,

Brian

[cade]

Hello Brian,

I'm wondering if the data array orientation is opposite from what your program is expecting.

Can you try using the Transpose 2D Array function before writing the data to the binary file. This will ensure that each column of data from the digitizer channels is written sequentially instead of row by row.

Thanks!