From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-31-2013 03:48 AM - edited 05-31-2013 03:50 AM
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
Solved! Go to Solution.
05-31-2013 07:40 AM
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?
05-31-2013 08:08 AM
You need to remove the count constant and add a string constant for the data type in the read case as shown below.
05-31-2013 08:13 AM
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.
05-31-2013 09:08 AM
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
05-31-2013 09:26 AM
@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.
05-31-2013 09:28 AM
@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
05-31-2013 10:47 AM
@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.
U rocks..!!
you have hit bull's eye...!!
05-31-2013 10:58 AM - edited 05-31-2013 11:03 AM
@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.
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.
05-31-2013 11:17 AM - edited 05-31-2013 11:17 AM
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.