Real-Time Measurement and Control
LV RT 2009 File Write to Pharlap OS PXI hard drive converts \r to \n Characters
Solved!
I know in LabVIEW help it says that the "End of Line constant" on the string palette is converted to the "platform-dependent end-of-line value", but where does it say that the "carriage return constant" (\r or ASCII 13d) would be converted to a line feed (\n or ASCII 10d) on the same platform?
I was debugging a process on my PXI 1044 chassis with the PXI-8106 embedded controller running LabVIEW 2009 and created a simple text based log file for this purpose, using the "end of line constant" (what some people would associate with a \r\n combination or as I like to put it, [cr][lf]) to delineate each line added to the file. I was a little surprised to see the lines delineated with the line feed character (\n, ASCII 10d) instead, but not too surprised because of the caveat in help about the substitution (for "end-of-line") on certain platforms. However, when I wrote to the file using a concatenated pair of string characters from the string pallet for a carriage return followed immediately by a line feed, I was surprised to see the combination of characters replaced in the file each time with a single line feed. I then experimented and tried to use just a single \r to delineate the lines but even single \r ([cr] or ASCII 13d) characters are converted to \n (ASCII 10d) characters. I am now using the line feed (\n) to delineate the lines in the file, but why can't a \r be used in a text file on this platform?
Is this the expected behavior? If it is not, has anyone else experienced and reported this to NI? If it is, where is this mentioned in the documentation?
Bill
Bill,
I ran some code on a Phar Lap-based controller, and I can't replicate what you're stating. I see the [cr][lf] options existing for a file created on Windows and Phar Lap. Here's the code I ran along with the resulting file. (The file was identical for both OSs - Windows XP and Phar Lap.)
I do know that some different behavior can exist between [cr] and [lf] values when using a VxWorks-based real-time controller. This article outlines some of these differences: Why Is There a Formatting Difference between Files Generated in VxWorks and Phar Lap?
Kevin S.
Applications Engineer
National Instruments
Kevin:
Did you build your code as an executable that runs as a startup vi? My file utility is a subvi of a much larger built application. My code looks substantially the same as yours, with one exception, that is, I load in the previous contents of the file, add the new entry, and then save to the file. I am not at work and do not have access to the actual code until tomorrow, but as I recall what I wrote goes pretty much like the following:
Basically it is a three step process.
1. Open or create file. Close reference to file. This ensures the file exists and avoids an error 7if file is not found.
2. Open file to read contents and save contents to string (wire) or shift register. Close file reference.
3. Open file to write concatenated contents from previous read (held in shift register or wire) with new data. Close file reference.
Again, I am not at work as I write this but I will go over the code once again when I get to the office in the morning. It may be that the build process does something that running it from a ethernet crossover cable from within the LabVIEW development environment does not, so please check it as an application. Also, for your information, I FTP the file back to my laptop, then I do a simple file read into a vi that has two string indicators, one set to show slash codes and the other hex. The concatenated [cr][lf] always becomes a single [lf] and a single [cr] always becomes a single [lf]. Bizarre!
By the way, thanks for following up on this so quickly. I have a workaround (I don't use [cr] anymore) but it is a puzzle to me how this could be happening and I like that kind of stuff.
Kevin: Here's an image of my code. It still converts [cr] to [lf] in the saving process.
It even does it if I run it from the LabVIEW development environment with the PXI as a target (see lower left corner of image).
At the bottom of this post you can see I have added the image from the file examiner tool I created to debug this.
You can see pretty clearly the \n and 0x0A values.
Thanks again for looking into this for me.
Bill
Bill,
I had trouble seeing some of the detail in the image. (If needed, post a VI snippet. ...remember about some of the caveats if using Firefox or Google Chrome browers.) I've got at least one comment though regarding it - why are you closing the file reference multiple times? You only need to close the file reference once. (Open it once and close it once.) I see a potential issue there.
In lieu of your code, I wrote some more test code. I get the same consistent output each time - on Windows and Real-Time (Phar Lap). No matter what permutation I do ([cr][lf], [lf][cr], [cr], [lf]) I always get the same output in Notepad++ (being [cr][lf]). I even wondered if reading from a file and writing that same data back to the file causes a conversion, but I saw no difference. Here's my code. Have you been able to identify at which point in your code the "conversion" takes place?
Kevin S.
Applications Engineer
National Instruments
Kevin: Here's a snippet of my code. I can see your code is simpler but I wrote mine the way I did to allow the flexibility I have with my various state modes. After running into the "read only" problem by using the Read from Text File vi before the Write Text File vi I just decided to do a complete mini-application with a few added functions. Try it and see what you get. By the way, which version of Notepad are you using? I've never seen one that highlights the non-printing characters. Once again, thank you for the time you are spending on this.
Kevin: I haven't seen any response to my snippet posting so I am going to assume you either feel the issue is resolved or NI is working on a reply / fix / or some other approach to dealing with the issue. In the meantime, the issue has not gone away and I can duplicate it on my laptop with the simple code in snippet form below. If anyone else wants to step in and examine or discuss the issue I would appreciate some feedback whether this occurs on any other machines and not just mine. Note that for people just happening upon this discussion, the problem occurs when the created file is read back. On my machine, the [cr] values (decimal 13 or hex 0D) are converted to decimal 10 (hex 0A or [lf]) in the saved file. I am running this on a XP SP3 platform, and the VI was created in LabVIEW 9.0f2.
Kevin: When did they move the "Convert EOL" control inputs on the "Write to Text File" and "Read from Text File" vis to the right click (context) menu? I was looking for a wire connection on the vi icon and now see what you have been saying. As far as new "Standardized user interfaces" goes, this one slipped by me, even though it was staring me in the face. Looks like a good question for the next CLAD / CLD-R test cycle (NOT 
).
And yeah, I am deliberately provoking a fire storm of discussion on this subject by bringing up the CLAD and CLD exams (and renewals) so others will learn from my error.
Thanks for your help and patience on this issue.
