Problem saving 2D array to binary file

[OrangeAndGreen]

I am getting some strange results when trying to write a transposed 2D array of Unisgned 8-bit data to a binary file. Attached is an example program ("071026_ArraySave_Bug.vi") which demonstrates the suspicious behavior.

The program generates a small 2D array of U8 data, then saves it to two temporary files using two different methods.

1) Row-by-row: The 2D array is auto-indexed, and the indexed row is written to file at once (with the prepended size option disabled).

2) Point-by-point: Two For loops are used to auto-index each element and write it to file individually.

The saved files are then reopened and the data is read into two 1D arrays for display.

The bug occurs when the generated 2D array is transposed before being saved to file. In the point-by-point method, the data is always saved to the file as desired, i.e. by row or by column depending on whether the data was transposed. However, in the row-by-row method the data is incorrectly saved when the input data is transposed. Without transposing the array, the row-by-row results are correct.

Saving the array row-by-row is significantly faster for larger arrays, so this method is desired.

Note that the option to transpose the input data in the attached VI is performed using a case structure with a boolean constant ("Bug Control"). This is important because:

1) The bug does not occur if the boolean constant is replaced with a control.

2) The bug does not occur if the case structure is replaced with a "Select" node from the Comparison Palette.

3) The bug still occurs if the case structure is removed such that the array is always transposed (i.e. keep the True case).

For now, I have been able to circumvent the bug in practice by transposing the array and then passing it through a Select with a constant True (the False case uses the untransposed array). This allows the faster row-by-row method to be used without error, but requires new memory allocation for the transposed array.

I will appreciate any help that can be given regarding this problem, or simply confirmation that it is indeed a bug in Labview 8.5. It is worth noting that the same program did not produce any errors when run in Labview 7.

Thank you for your help,

David Viggiano

[chilly_charly]

This is a known bug (CAR : 4DP855N3) , related to memory management. see this thread

If I remember well, Altenbach shown somewhere that forcing the transpose operation to produce a copy of the memory was a proper workaround.

Message Edité par chilly charly le 10-26-2007 08:40 PM

[altenbach]

For your reference, here's the original discussion:

http://forums.ni.com/ni/board/message?board.id=170&message.id=274905