Issue in reading a binary file, with 'Flatten to String' data.

[moderator1983]

I'm facing issue while reading a binary file (created using LabVIEW).

I've mentioned everything (issue and method to reproduce it) within the attached VI.

Same vi is attached in 2012 and 8.0 versions.

--

Regards

[NapDynamite]

I checked your VI, unplugged that error wire from "unflatten from string" just to see the full error message. It says " Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data". 

Does it have something to do with the data you are providing right over that file path constant? 

[SLee2004]

You need to remove the count constant and add a string constant for the data type in the read case as shown below.

[crossrulz · Accepted solution]

The reading of a string from a binary file stops at a NULL character (0x00).  When the first character is 0x00, you are just reading the one character.  I would suggest writing to a byte array since you are doing the inverting.  And then you can read as a byte array.

[camerond]

In supplying your "write to binary file.vi" with a refnum instead of a file path, you are telling it to append to the beginning of the existing file instead of replacing it. That could well screw up your unflatten because the VI is looking for a 5-element cluster and you're giving it extra stuff.

To test your program, take out the "encrypt" until you have the read/write stuff correct. You're just making finding your problem harder.

Cameron

[crossrulz]

---

@camerond wrote:

In supplying your "write to binary file.vi" with a refnum instead of a file path, you are telling it to append to the beginning of the existing file instead of replacing it. That could well screw up your unflatten because the VI is looking for a 5-element cluster and you're giving it extra stuff.

---

Look closer.  He is using "Create or Replace" for the file open.  This means the file will be totally erased if one was already there.  There will not be any extra stuff.

[camerond]

---

@crossrulz wrote:

---

@camerond wrote:

In supplying your "write to binary file.vi" with a refnum instead of a file path, you are telling it to append to the beginning of the existing file instead of replacing it. That could well screw up your unflatten because the VI is looking for a 5-element cluster and you're giving it extra stuff.

---

Look closer.  He is using "Create or Replace" for the file open.  This means the file will be totally erased if one was already there.  There will not be any extra stuff.

---

You're right, I missed that. My bad.

Cameron

[moderator1983]

---

@crossrulz wrote:

The reading of a string from a binary file stops at a NULL character (0x00).  When the first character is 0x00, you are just reading the one character.  I would suggest writing to a byte array since you are doing the inverting.  And then you can read as a byte array.

---

@crossrulz:

U rocks..!!

you have hit bull's eye...!!

[crossrulz]

---

@moderator1983 wrote:

---

@crossrulz wrote:

The reading of a string from a binary file stops at a NULL character (0x00).  When the first character is 0x00, you are just reading the one character.  I would suggest writing to a byte array since you are doing the inverting.  And then you can read as a byte array.

---

@crossrulz:

U rocks..!!

you have hit bull's eye...!!

---

After playing around a little more, I think I might have misinformed you a little.  If you explicitly tell it a string, it looks for the string length at the very beginning and reads that length of bytes as a string.  It appears that if you implicitly tell it to read a string (not wire the data type) it reads all of the bytes directly, including the length of string you wrote.

Regardless, my advice is the same.  You should just write and read using byte array.  It is less conversions if you are performing your "encryption".

EDIT:  Here's a snippet of the VI I was playing with to figure this out.

[crossrulz]

Ha.  After some more playing around, I discovered all you needed to do was set the "Append Array/String Size" on the binary write to FALSE.  Or you could just explicitly tell the read to read a string.

But again, why convert back to a string when you don't have to.  Here's the solution I was proposing for everybody to see.