FILE_WRITE adds extra carriage return CR
ijed
Junior Member
Stumped by this one:
Trying to just write out the response from an IP port to a local file on the NI4100.
so I open a file:
anything coming in I write to the file:
then when transfer is complete I close the file
what I see is everytime there is a CR it's being replaced by 2 CRs
I tried writing out a line at a time:
the strings are fine coming in too - but when I look at what's saved I see 2 0D's when there should be 1.
Funny thing is notepad doesn't seem to mind this - but when I open it in Notepad++ I get a space between each line and in HexViewer I see the offending 0D
Trying to just write out the response from an IP port to a local file on the NI4100.
so I open a file:
_slFileHandle = FILE_OPEN(cLocalFile, FILE_RW_NEW)
anything coming in I write to the file:
DATA_EVENT [dvDATAPORT]
{
STRING:
{
local_var long nBytes
nBytes = length_array(cFTPServerBuffer)
FILE_WRITE(_slFileHandle, get_buffer_string(cFTPServerBuffer, nBytes), nBytes)
}
}
then when transfer is complete I close the file
what I see is everytime there is a CR it's being replaced by 2 CRs
I tried writing out a line at a time:
while(find_string(cFTPServerBuffer, "13, 10", 1))
{
cTemp = remove_string(cFTPServerBuffer, "13, 10", 1)
nBytes = length_array(cTemp)
//SEND_STRING dvDebug, cTemp
FILE_WRITE(_slFileHandle, cTemp, nBytes)
}
or even stripping off any CRLFs and using FILE_WRITE_LINE but it makes no differencethe strings are fine coming in too - but when I look at what's saved I see 2 0D's when there should be 1.
Funny thing is notepad doesn't seem to mind this - but when I open it in Notepad++ I get a space between each line and in HexViewer I see the offending 0D
Comments
-
Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.
-
nicholasjames wrote: »Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.
Not exlusivey an AMX issue. Check to see if the ftp client has been set to asciii or binary mode. Try uploading in the other mode - or set it to auto and forget about it. -
nicholasjames wrote: »Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.Not exlusivey an AMX issue. Check to see if the ftp client has been set to asciii or binary mode. Try uploading in the other mode - or set it to auto and forget about it.
Using Windows 2008 NT FTP Server - NI is just sending commands on one port and sending/retrieving data on another.
Just tried both TYPE A and TYPE I transfer modes with no success
SYST command doesn't give a default type (Just says Windows_NT) and google's not helping me find anyway to change any settings (only options I get are to change directory listings in MS-DOS or UNIX format)...
The weird thing is the buffer looks fine though - it's not until I write the file that it puts in the extra $0DLine 9 (10:56:09):: <session name="Test Session 01" exams="16">$0D$0A Line 10 (10:56:09):: $09$09<preroll chime="1" duration="72"/>$0D$0A Line 11 (10:56:09):: $09$09<reading chime="2" duration="125"/>$0D$0A
It actually looks like it's converting a $0A to a $0D$0A
if I take out the $0D before writing the file:cTemp = remove_string(cFTPServerBuffer, "13, 10", 1) cTemp = left_string(cTemp, length_array(cTemp)-2) cTemp = "cTemp, 10" nBytes = length_array(cTemp) FILE_WRITE(_slFileHandle, cTemp, nBytes)
now looks like this:Line 9 (11:38:12):: <session name="Test Session 01" exams="16">$0A Line 10 (11:38:12):: $09$09<preroll chime="1" duration="72"/>$0A
and writes it out like this, putting the $0Ds back in:3C73657373696F6E206E616D653D2254 6573742053657373696F6E2030312220 6578616D733D223136223E[B]0D0A[/B]09093C 707265726F6C6C206368696D653D2231 22206475726174696F6E3D223732222F 3E[B]0D0A[/B]
Further tests
Arg - so the original file only has a $0D (no $0A) so FTP Server is adding a $0A then FILE_WRITE seems to be adding another $0D ? Now I'm really confused -
FILE_WRITE adds extra carriage return CR
what I see is everytime there is a CR it's being replaced by 2 CRs
I performed several different tests (on an NI-700) and I couldn’t find one case where FILE_WRITE is adding an extra CR. FILE_WRITE is working perfectly as far as I can tell.
Have you tried eliminating your FTP client from the equation? After you write the file, read the file back in and print the contents to the screen.
If you are still having problems please post code that demonstrates your FILE_WRITE issue so we can try it out for ourselves. -
Joe Hebert wrote: »I performed several different tests (on an NI-700) and I couldn’t find one case where FILE_WRITE is adding an extra CR. FILE_WRITE is working perfectly as far as I can tell.
Have you tried eliminating your FTP client from the equation? After you write the file, read the file back in and print the contents to the screen.
If you are still having problems please post code that demonstrates your FILE_WRITE issue so we can try it out for ourselves.
One of the IT guys came in to have a look at it - turned off using FTP via SSL and it all started behaving.
Thanks for the help
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums
