TLServer File Services and On-line Monitoring

[garysdickinson]

I'm working with T100MD+1616 hardware and would like to log PLC data to a PC using the TLServer and the <APPEND xxx.txt> mechanism.

The problem that I am having is that I'm using the same COMM #1 port for both debug (online monitoring) and the <APPEND xxx.txt> activity.  It believe that the data streams for the <APPEND xxx> file services are getting intermixed with the On-Line Monitoring requests to "see" what's going on with the PLC.

The TLServer help files state:

The TLServer will close the file after it receives the end-of-service tag "</>" from the PLC and it will in turn send a "<OK>" tag to the PLC to acknowledge that the APPEND  request has been successfully completed. It is up to your PLC program to check for the "<OK>" tag to determine if it the service it requested have been completed successfully.

The Help file gives no suggestion on how the PLC program should check for the "<OK>" tag.

I use the following code to read the <OK> tag I really mess up the On-Line Monitoring:

' Get Response from TLServer
'
A$=""
N=0
I = INCOMM(1)
WHILE I<>-1
    A$=A$+CHR$(I)
    N=N+1
    I = INCOMM(1)
ENDWHILE

Is there a special (correct) way to check for the "<OK>" token?

Is the <OK> tag buffered differently from the commands send/received as a result of the On-Line Monitoring?  Is there a special TLBasic function that I should use?

Would I have less problems if I used the XServer rather than the RS-232 connection?

[support]

If TLServer is performing online monitoring then it is actually using the COM port actively to send command strings and receive response string from the PLC. It expects certain response string when it send certain command string but if your PLC slip in some text such as trying to open a file then it can cause problem to the communication.

If you can avoid using TLServer for online monitoring if it is to be used to provide file and email services to the PLC that will be the best choice. You can perform online monitoring via the XServer which connects to the other comm port (e.g. connects to COMM3 via Auto485) and perform online monitoring via the XServer and let the TLServer do the data acquisition.

If you want to use the TLServer for both online monitoring and file and email services, then a compromise solution is to perform "arbitration" protocol which is to send a certain command to advise the TLServer to temporarily put on hold online monitoring and to process the requests from the PLC. Please refer to the XServer installation guide on the arbitration protocol. There are example programs in the XServer folder that demonstrate the use of the arbitration method. This will greatly reduce the error cause to online monitoring but may not eliminate it 100%.

[support]

You may want to check the user manual of the F-series PLCs that you have requested. The built-in Ethernet port uses different "pipes" for processing the online monitoring and network services request from the PLC and there will not be any interference issue and no arbitration is needed.

[garysdickinson]

Thanks for reminding me about the F-Series PLCs, this may be the best solution.

I have been experimenting with the STX/ACK arbitration and clearly understand that it doesn't work reliably.  This makes the use of the NS commands very difficult if the same COMM port is used for On-line monitoring.

I do have one question, "What is an XA command?"

In some cases where the STX/ACK arbitration appears to work, then I issue the NS command for Apending to a file, I sometimes find in the PLC Comm #1 input buffer the following string:

     "@01XA58"

The next string in the the buffer is "<OK>", however the NS command did not complete correctly and the data appended to the file is corrupt.

I believe that this "XA" command was sent by the TLServer to the PLC after sucessfully arbitrating with the STX/ACK handshake.  It seems as if the TLServer grants control of the COMM port (STX/ACK) but then forgets and resumes sending commands to the PLC without waiting for the "</>" terminator or a significant timeout.

I can't find any reference to the "XA" command.

Thanks for your advice.

[support]

XA command is used by TRiLOGI to request for data in a compacted form. It is not a published command and is not to be used by normal user.

[garysdickinson]

Thanks for the info on the XA command.  I suspect that these XA commands are used by the On-Line monitoring and that the XA commands  transfers binary (not just printable ASCII) data.  This behavior precludes the use of STX/ACK arbitration.

Is there any mechanism that the PLC can use to detect if On- line monitoring is in progress?  An undocumented TBasic command or a special bit that ladder logic could "look at" would be great.

I've worked with the sample code that was provided for the XServer and found that these algorithms do not work with On-line monitoring.  I've spent a couple of days attempting to develop more reliable algorithms but the XA command seems to be the one problem that I cannot work around.

Thanks again for your help.

[support]

The PLC can check to see if its serial buffer is being continuosly filled with characters to know if an online monitoring is in progress. First the PLC should flush the buffer by running the INCOMM command until it receives a -1. Then waits for 1 second or longer and if INCOMM still returns a -1 immediately that means that the serial port is quiet and it can perform the file and email service command.