Writing 2D double precision data to binary file broke upgrading from 8.2.1 to 8.5?

[Ron Norton]

Hi,

I have a VI which continuously aquires and writes a 2D array of double precision data to a binary file using the Write to Binary File function.

It works fine in LabVIEW 8.2.1, but in LabVIEW 8.5 it seems to write all zeros to the file even though a probe on the data input to the Write to Binary File function confirms that the data is indeed non-zero.

Is anyone aware of a change in the way the Write to Binary File function works in going from 8.2.1 to 8.5? I can't seem to find anything about it.

I will try to construct and post a simple example of the problem in 8.5 a little bit later - we are running 8.2.1 right now to get some data.

Thanks for any help,

Ron Norton

[Ron Norton]

Here is a simple example which illustrates the issue.

In LabVIEW 8.2.1 it saves the sine waves correctly as 4 columns of double precision reals. In LabVIEW 8.5 it stores the right number of elements but they're all zero.

A strange thing is that if I remove the transpose operator, the non-zero data is stored correctly as 4 rows of data (although that's not the way I want it in the file for later processing with other software).

Any insights or suggestions would be greatly appreciated. Thanks,

Ron

[Matthew_Kelton]

I am able to reproduce your problem in 8.2.1 and 8.5.  It is very perplexing.

[Matthew_Kelton]

There is an issue in the transpose array.  If I write my own transpose function, the VI works.  In your VI, if I do the following, it will work.

There is some memory issue with the output of the transpose array where the data is corrupted.

Message Edited by Matthew Kelton on 09-28-2007 06:17 PM

[Matthew_Kelton]

Even better - If I create a subVI which is nothing but a wrapper around their transpose (click the transpose icon in your VI and choose Edit->Create subVI), it works.

Message Edited by Matthew Kelton on 09-28-2007 06:29 PM

[altenbach]

Very curious problem.

Yes, selecting the transpose, followed by "create subVI" fixes the problem. 😮

If you place two transpose in a row, the problem disappears, but reappears with three transpose operations.

I have reported it in the bug thread:

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=4310#M4310

[altenbach]

OK, it seems a memory optimization problem. Fortunately, we have the new "always copy" function. Placing it before the file write fixes the problem!

I always wondered if I'm ever going to use that function anywhere. 🙂

Message Edited by altenbach on 09-28-2007 05:42 PM

[Ray.R]

Always copy??

It is new..  Can you elaborate on this one (no longer have access to 8.5 😞 )

[altenbach]

Yes, that's new for 8.5, complementing the "in place element structure" and others. They are nicely hidden in the "application control...memory control" palette.

I am still struggling to think of a scenario where "always copy" would provide benefits. Typically, the compiler decisions are pretty good. 😉 

Message Edited by altenbach on 09-29-2007 09:45 AM

[dan_u]

Seems NI introduced some bugs in 8.5...
Just recently I reported a similar bug in LV 8.5 to NI. If you write an array of SGL/DBL to disk using "Write to Binary File" in big-endian format it works as expected. But if you use an index array function (e.g. to extract a row/column) of a 2D-array and wire it's output to "Write to Binary File" it will always save in little-endian format. To test, you can just use build array and index array in a row.
A workaround is to use flatten to string first and write the string to the binary file.

Daniel