09-14-2011 03:11 PM
There is what appears to be a bug in NI_InternetTK_FTP_VIs:FTP Data Send.vi. In our testing, this didn't seem to cause any issues (inexplicably) when running in the LabVIEW development environment on Windows or VxWorks. It only manifested itself when we attempted to FTP binary data files from a cRIO from within a deployed executable. I have no idea why those conditions must be met because it seems like this would corrupt any binary file transfered with this vi that contained any <eol> characters.
As it says in the comment, this will "Replace all <eol> characters with <cr><lf>. If the last character is a <cr>, add it to the next iteration". Unfortunately, it only does this for binary files. I believe it should only be done for text files.
We were transfering TDMS files that were created on the target to a network FTP server. The files were corrupt upon receipt, and we found the problem to be the presence of <cr><lf> where there shouldn't have been. Switching this case from True to False fixed our problem.
Chris
09-15-2011 05:32 PM
Hello,
I am going to look into this behavior. What version of LabVIEW are you using?
Regards,
Patricia B.
09-16-2011 07:58 AM
I am using LV2011 (32bit) on Windows 7 (64bit) and with NI-RIO 4.0. I also confirmed the presence of this block of code in LV2010.
Chris
09-19-2011 06:30 PM
Hello,
I have documented this behavior in CAR 315798 with R&D.
Regards,
Patricia B.
01-11-2012 01:24 AM
I can confirm that this problem still exists running LabView 2011.
Setting binary mode to on the FTP Put File vi to true uploads ascii, setting it to false uploads binary.
I cannot confirm the cRio version number (it is no longer physically with me).