Error 116 while reading string from binary file

[kevin.moll]

I am trying to use the "write to binary file" and "read from binary file" pair of VI's to write a string to a binary file and read it in again.  The file is successfully created and a hex editor confirms that the file contains what is expected (a header + the string).  However, when I try to read the string back in again, I recieve an Error 116: "LabVIEW:  Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data."  One quirkiness that I have found though, is that if I set the endianness to "Big Endian, network order", the error disappears while if I use "native, host order" (my original setting) or "little-endian" the error occurs.  Am I missing something in the documentation that says that you can only use big endian ordering when writing strings, am I doing something else wrong, or is this a bug in Labview?  Since the program this will be used in consists of writing large arrays in addition to strings, I'd like to be able to stick to the "native" setting for speed reasons and not have to mix endianness.

I have attached a sample VI that demonstrates this problem.

I am using Labview 8.5 on Windows XP SP2.

Thanks,

Kevin

[tbd]

Hi Kevin,
      I think you may have identified a bug - at least, a lack of symmetry in the way the "byte order" control affects Writes and Reads of strings.

No matter what byte-order is specified during Write, the "Prepend Array or String size" always writes the 4 size bytes Big-Endian.
When READing strings WITH THE DATATYPE WIRED, the prepended length bytes ARE interpreted according to the "byte order" - so there's an error if Big Endian is not specified.

IMHO, when the Write prepends length bytes to strings, it could/should obey "byte order"!

The attached VI "WriteReadRecord" encapsulates the string in a cluster.  The "top-level" data-type is no longer string - so the "prepend" input is ignored, however, the Write recognizes that some length data is required for unpacking and appends the required length-bytes according to the "byte order" control - and Write/Read behave consistently.

Cheers.

[kevin.moll]

Thanks for confirming that this behavior is not limited to my installation of Labview.

Since I need to later append arrays to the same file after writing a string, I cannot use the method in the WriteReadBinary.vi in which you rely on the file size to determine the length of the string.

Thanks for pointing out that by wrapping the string in a cluster, the Labview VI's seem to sort themselves out and work for all endianness formats.  It's annoying, but I can make that work.

Can someone from NI comment on this behavior?

[NI-Bob · Accepted solution]

Hello,

Thank you for contacting National Instruments!  I have verified the behavior that you have encountered and agree that this is a bug This was reported to R&D (CAR # 130314) for further investigation.  As you have already figured out a possible workaround is to use the Big-Endian setting.  Also, I have attached another example that converts the String to a Binary Array before writing to the file and then converts back to a String after reading from the file.  Please let me know if you have any questions after looking though this example and I will be happy to assist you!  Thank you very much for the feedback! 

[kevin.moll]

Bob,

Thanks for the alternate workaround and forwarding this to R&D.