07-06-2023 03:56 AM
When writing data (string: "MyString") to binary file, Labivew automatically adds \s\s\s in front of a file size information (\b). Why? And how to confince Labview to write only file size information not any additional \s in the binary file?
07-06-2023 04:09 AM
The size information is an int32. When you open the file in a text editor, the first four characters will look out of place. Try to change the endianness to see how that affects your file.
For flattened data, see here: https://www.ni.com/docs/de-DE/bundle/labview/page/lvconcepts/flattened_data.html
If you want a different format, you could get the string length, cast it to u8 and write it to the file, before writing the without the string size.
07-06-2023 01:51 PM
Your program won't run if the file doesn't already exist (unless you configure it to "Create"). Recall you are writing a Binary File and giving it text, which means (except for the File Size header) the u8 "characters" will look just fine if you open it with a "semi-smart" Text Editor.
Do you see those 4 "non-printing" ASCII characters before "MyString"? They are null (0), null (0), null (0), backspace (8), or (considering all four as a u32 number) 0008. Count the number of characters in the string -- is this a "coincidence" or is this a "feature" of Binary I/O? [Think about it, especially when you are dealing with data, such as numbers, that don't have obvious sizes unless you know exactly the format of the data beforehand.
Bob Schor
07-06-2023 04:04 PM
I just open the string I showed you (with my editor that shows non-printing Ascii characters), but I also just thought to open it in Notepad, µSoft's "default" editor. It treats the Nulls as spaces, and the BackSpace (decimal 😎 as a thin funny-looking character, but not (quite) a space. Try opening up a true "data file" (where you've really saved binary data) in Notepad -- it will really be messy, as it "force-displays" the binary data as though it were Ascii text.
That's why LabVIEW has both Text File and Binary File I/O routines -- the data bytes are the same, but the interpretation of those bytes can be quite different!
Bob Schor
07-07-2023 12:16 AM
Thanks for answers.
Since there is no way for the Labivew to NOT automatically include empty spaces in front of the data (string) when using "Prepend array or string size" I solved the problem in another way.
I made a bit of workaround so that I manually get number of string characters and clean information of \s od \00. Then I concatenate data string with information about data string size and when write string in binary file without using "Prepend array or string size" Labivew option.
There is a picture of "workaround" part:
07-07-2023 12:51 AM - edited 07-07-2023 12:54 AM
Hi Andraz,
@AndrazS wrote:
Since there is no way for the Labivew to NOT automatically include empty spaces in front of the data (string) when using "Prepend array or string size" I solved the problem in another way.
I guess you don't understand what all the other posters already tried to tell you: there are no "empty spaces in front of data"!
LabVIEW prepends the size of the binary data as an U32 value (4 bytes, big endian first). And that is a quite convinient way to store binary data.
When you want to create plain text files you should use the text file functions instead of the binary file functions…
@AndrazS wrote:
I made a bit of workaround so that I manually get number of string characters and clean information of \s od \00. Then I concatenate data string with information about data string size and when write string in binary file without using "Prepend array or string size" Labivew option.
How do you read the file later on?
How does your "workaround" handle the cases where a string might be longer than 255 chars?
How does your reading routine know how many bytes will describe the length of the string to follow?
How do you determine there might be a length indication of variable 1 to 4 bytes length?
07-07-2023 04:20 AM
@AndrazS wrote:
When writing data (string: "MyString") to binary file, Labivew automatically adds \s\s\s in front of a file size information (\b). Why? And how to confince Labview to write only file size information not any additional \s in the binary file?
If you select to prepend size information, LabVIEW will dutifully do that for you. It will measure that particular string and write the size in binary as I32 (and will even do it in little endian if so configured). If you don't want that, select no to prepend. So what are you actually trying to achieve with all this? Will you append other strings later? How will you read it? If that file read by other applications?
The real file size never needs to be inside the file data, because the OS knows the file size at any time, so that would be redundant..