TLServer 3.15 READ command strips out both CR and LF characters

[garysdickinson]

I'm attempting to use the READ file service provided by TLServer V3.15

I'm using an old T100MD+1616 r42 PLC.  I'm using the XServer to conenct the PLC's RS-232 to ethernet.  I'm using TLServer V3.15.  The PC is running Vista (32bit)

I've created a ASCII file that contains two lines of text that are terminated with CR/LF pairs:

    01 Text<cr><lf>
    02 Text<cr><lf>


The READ command returns the following:

    01 Text02 Text<OK><cr>

I have used both INPUT$(1) and INCOMM(1) commands to verify this behavior.

What I see is that ALL line termination characters are stripped from the text file.  I understand that the "<OK><cr>" is the acknowledgement string from the TLServer.

This behavior is not what is documented in TLServer "Help":

Upon receiving this command and if the specified [filename] is successfully opened, the TLServer will begin sending all the ASCII characters contained in the text file to the PLC. Note that line breaks in a text file are sent to the PLC as CR character only and not as a CR+LF pair. As such, your PLC program can easily use the INPUT$(1) command to read in all the CR-terminated text string one string at a time and then interpret or convert the data as necessary. After sending out the last byte in the data file to the PLC, the TLServer will send a CR-terminated acknowledgement string "<OK>" to the PLC to signal that the READ command have been properly completed.

[support]

Are you sure your file contained CR +LF?  TLServer will send the CR character but will strip out the LF character.

I just tested by creating a text file using Notepad. I then send a <READ TESTFILE.TXT> command from another PC in HyperTerminal and receive all the characters including CR character but no LF character received.

[garysdickinson]

Yes my file contains both CR and LF

This is the contents of my one line file in ASCII and HEX:

ABCD                   <-- ASCII
414243430D0A   <-- Hex dump          

This is what the PLC "sees" after Arbitration with STX/ACK, sending the <REMOTE> and <READ ReadFile.txt> then waiting 1 second:

ABCD<OK>
414243443C4F4B3E0D

This is the TBASIC code that I use to display the results of the READ file service on the LCD:

        A$ = ""
   H$ = ""
   I = INCOMM(1)
   WHILE I<>-1
      A$ = A$ + CHR$(I)
      H$ = H$ + HEX$(I,2)
      I = INCOMM(1)
   ENDWHILE

   SETLCD 2,1,A$               ' Display ASCII String
   SETLCD 3,1,H$               ' Display HEX String

I'm using the INCOMM(1) command as it does less processing to the characters received on the COMM1 port.

Is there a possibility that the changes to support Unicode characters have affected the TLServer 3.15?

[support]

I created a file exactly like yours with only ABCD followed by CR and LF.

I then created a trilogi program using your code fragment. When it reads the line the LCD shows the following:

   ABCD[symbol]<OK>  '[Symbol] is some non ascii char
   414243440D3C4F4B

So it behaves exactly as expected.

Is your file saved in ASCII or Unicode? It could be an issue if it is saved in Unicode. You can use a binary file viewer such as "PX Binary Viewer" (google to download) to check if the data in the file is binary or unicode.

Also you may like to use a CPU with a newer firmware to test. Older firmware may have some bugs that have already been corrected in the later firmware so it may not show up when tested with a PLC with newer firmware.