FTP copied .txt file incorrectly from cRio

[loves2]

I am using the "FTP Get File.vi" to retrieve a .txt file from my CRio which is then copied to my host computer.  The file is a tab deliminated array of data.  The copied file has all of the data except that the copy has an empty row between each data set.  These extra rows cause me to read incorrect rows when the file is read into my program later with the "Read from Spreadsheet File".  Where are these extra rows coming from?  I've checked original file on the cRio by transferring it via MAX and those lines do not exist.  Can anybody tell me how to fix this?  Thanks,

[RavensFan]

My guess is that there is a misintepretation in the end of line character.  It could be carriage return (ASCII 13), line feed (ASCII 10), or CR/LF (ASCII 13 followed by 10).  It is probably sending CR/LF, but your program is intepreting that as two different end of line characters thus give you data ended by a CR, then an empty line that ends with the LF character.  Inspect the two files in a hex editor and compare.

How does your program read it?  If you are using Read Text File, then look at the setting on the right click menu for Convert EOL.

[loves2]

The .txt file is actually stored with the extra lines when copied from the cRio.  So if it is a misintepretation in the end of line character it is within the "FTP Get File.vi".  I don't have access to a hex editor so I can't tell you the exact difference between the two files.  Do you know how I would check the EOL character interpretation of that vi?  Thanks. 

[jareds · Accepted solution]

If you look at the inputs for the FTP Get File.vi, you'll notice that there's one that says binary:

 

 By default, this is set to false, which means it copies the data in an ASCII format.  Try wiring a true constant to this input.  This is need since Windows and VxWorks use different end of line markers.  This difference is probably the reason that it's adding lines to it.