Writing to a file in RT

[PrasannaSSRK]

Hello LabVIEW users,

I am writing a normal config file(ini) in the RT environment. After writing, when I copy the file to PC, all the text what had been written are in straight lines. (i.e) All the line feeds in the file have been removed. This affects the readability of the file. Any solution to this issue?

Thanks in advance.

[GerdW]

Hi Prasanna,

Any solution to this issue?

Use a better editor on your computer! I suggest Notepad++…

Background: different OS use different "end of line" chars. Linux (as is used on recent RT systems) uses LF, while Windows insists on CR+LF. (Well, the latest or the next update for Win10 claimed to handle that better with allowing just LF…)

[PrasannaSSRK]

Hello GerdW,

I have a file in PC. I copy it to cRIO and then edit it programmatically in RT environment. Now when I copy that file back to PC, I have this issue of Line feeds getting deleted. When I open that file with notepad++ as you said, it looks correct with all line feeds. This means there is an issue with notepad. But the original file which I had it in PC can be viewed without any changes with notepad. When I just read the modified file through LabVIEW by using read text file node, the contents are perfect with linefeeds. I still don't know why notepad couldn't recognize line feeds when a file is copied from cRIO. 

Thanks,

Prasanna.

[GerdW]

Hi Prasanna,

that old "notepad" (aka Editor) of Windows ONLY likes the Windows-style end-of-line char (CR-LF). Better software likes all kind of end-of-line chars (Unix-LF)…

Get rid of notepad and use better editors like Notepad++ (or UltraEdit or many other)!

When you want to avoid such problems you have to save the files in your RT system using the Windows-style EOL chars…

[rolfk]

If you do the file writing yourself you can play with the Convert EOL option of the Read and  Write Text to File function. If this is enabled the read function will attempt to convert any occurrence of <CR> (\r), <LF> (\n), and <CR><LF> (\r\n) into the LabVIEW default <LF>. On write the Write function will convert any occurrence of <CR>, <LF>, and <CR><LF> into the platform specific EOL sequence (<LF> for Unix and MacOS X, <CR> for Classic Mac and <CR><LF> for Windows).

If you use the INI File VIs you are in a bit of bad luck as the file writing is embedded deep down in the library and can't be changed to not convert. The only feasable option would be to read the entire ini file after you closed the INI file using the Convert EOL option on the Read File VI and replace all the occurrences of \n with the \r\n you so badly want, then write it back with the Convert EOL option disabled on the Write File node.

Another option, as already mentioned by others, is to use a decent text editor like Notepad++ or Ultraedit, which don't get messed up about different platform specific line endings like the awful Windows Notepad application. Once you start using either of those two you never ever will want to go back to the Windows Notepad application. It's awfully inadequate.

[PrasannaSSRK]

Hello Rolf,

I tried to read the contents of the modified file(without any line feeds) through read text file node and tried to display it in string indicator. I changed the display style to Codes View. There was no \r present in the file. There was only \n. This is why I got confused. The codes view of the original file before copying to cRIO and the file copied from cRIO were exactly same. 

Thanks,

Prasanna.

[rolfk]

When you created that VI to read the file, did you right click on the File Read node and deselect the Convert EOL option? (The two arrows in the lower right corner MUST NOT be visible anymore!)

[PrasannaSSRK]

Yeah. I did that too. Still, in the Codes Display, there were no \r found. All the line feeds were found in the string indicator.

[rolfk]

Something in your various posts seems not quite as you say it is. But without seeing the code in question it ends here. And considering that the main problem is mostly caused by the use of a crappy Notepad application, I think we can rest the case now.