LabVIEW writes Line Feed and Carriage return when writing a single Line Feed or Carriage Return

[Foreshadow20]

When I'm writing data to a file in order to emulate a "binary file", LabVIEW is replacing 0xA and 0xD with both 0xD & 0xA.

How can this automation be disabled. It does the same thing both on Windows XP LabVIEW 8.2 and Windows 7 LabVIEW 2016.

Someone stated in another thread that it was the editor causing the issue, however in the LabVIEW array shows that only 0XD is replaced by 0xA, however a Hex Editor shows that both bytes were written to the file. Furthermore, the size of the file is 258 bytes which clearly confirms that LabVIEW has written the 2 extra bytes.

[billko · Accepted solution]

See the little "double-arrow" on your file read and write?  This icon tells you that it is converting EOL characters to what is appropriate for your operating system.  In order LabVIEW to leave these guys alone, you have to right-click on the read and write and uncheck the "Convert EOL" option.  I wish this was unchecked by default because I haven't had a single instance in my years of using LabVIEW where this option was appropriate.

[crossrulz]

---

@Foreshadow20 wrote:

When I'm writing data to a file in order to emulate a "binary file",

---

Then you should be using the Write Binary File instead of the Write Text File.  Beware that there is an input of the Write Text File to "prepend array/string size" that should generally be set to FALSE.

[Foreshadow20]

Thanks, that worked. I agree that it should be disabled by default. I'm surprised that I didn't see anything about it in the forums.

[billko]

---

@Foreshadow20 wrote:

Thanks, that worked. I agree that it should be disabled by default. I'm surprised that I didn't see anything about it in the forums.

---

It's a gripe of mine, but I also understand why the aren't going to change it.  Changing it would break all existing code.

[rolfk]

It’s also a question what you interface with. LabVIEWs default EOL is the new line character as they opted for the Unix (or C) default EOL And back in those days when computers still were real computers and men were real men, the programs on a specific platform were very finicky about reading text files that had not the correct EOL character. Notepad still is in many ways.

So making the LabVIEW Write Text File function convert EOL when writing to a text file was rather a call to reduce potential support calls than any form of user harassing. And yes, once such a decision has been made, changing it to something else is a serious decision that will be very likely considered as even more harassing by quite a few old time users.

It’s a decision that should be made consciously every time you use that function, similar to things like what decimal sign you should use when formatting floating point numbers. Depending on who it is for, you want to always use a point (instruments) or the platform specific format (when interfacing to local applications, especially when they are from Microsoft) or a comma (when talking to hardware programmed in Germany). 😀