Internet PLC Forum

General => Technical support => Topic started by: garysdickinson on July 28, 2014, 03:55:24 PM

Title: NS TCPCONNECT Behaviors
Post by: garysdickinson on July 28, 2014, 03:55:24 PM

I have been testing the behavior of the TCPCONNECT tag to access network timeservers.  The test is being done on an FMD1616 PLC with firmware r82A.

This post is more to provide information on how things work then to ask a question.  

My observations on the behavior of this command are as follows:

• The TCPCONNECT tag is non-blocking. The execution time of the statement,  print #4 "<TCPCONNECT 64.250.229.100:13>" is about 450 us.  I have not observed it to exceed 500 us.
• Polling for command completion using INPUT$(4) can fail.  It is possible to poll forever and not receive either a response from the remote device that you are attempting to connect to nor an error message from the PLC TCP/IP firmware.
• If the PLC TCP/IP firmware does return an error message, this message is received iin 2 seconds or less. This seems to suggest the the TCP/IP firmware does have a 2 second timeout mechanism.
• The results with polling using INPUT$(4) can be different if on-line monitoring is being used vs. the PLC being physically disconnected from the Ethernet bus.
• Status(3) behavior. Immediately after issuing the TCPCONNECT tag, Status(3) returns a value of 0 indicating that the command is being processed.  Status(3) will return a value of 1 when a TCP/IP connection has been established. The actual response message from the server is not available for 40ms after Status(3) indicates a TCP/IP connection.
• In the event that the timeserver drops the connection, Status(3) will go back to a value of 0, but there is no response message from the server and the PLC TCP/IP firmware does not post an error message.  

This is the PLC test code that I was using to make these evaluations and measurements

' Demo of NIST command behavior
'
' the integer variables a,b,c,d and e are used to calculate elapsed time
'
d = 0
e = 0
A$ = "<TCPCONNECT 64.250.229.100:13>"   'Connect to time server

print #1 ">>> "+A$
a = status(21)               ' timestamp: Start
PRINT #4 A$                   ' Send TCP command
b = status(21)               ' timestamp: Command overhead
Print #1 "         Status(3): "; status(3)

' poll for message
'
i = 3000                  ' max poll time in ms
A$ = INPUT$(4)
while i and (len(A$) = 0)
   delay 1

   ' this code is looking for status(3) to go from 0..1
   '  indicating that the there was a connection to the
   '  time server was established
   '
   if (d = 0)            
      if (status(3))
         d = status(21)
      endif
   endif

   ' this code is looking for status(3) to go from 1..0
   '  indicating that the connection to the time server
   '  was dropped
   '
   if (d and (e = 0))            
      if (status(3) = 0)
         e = status(21)
      endif
   endif

   A$ = INPUT$(4)
   i = i -1
endwhile
c = status(21)               ' timestamp: Command complete


print #1 "     Print #4 time: " + str$(b-a)
if (d)
   print #1 "      Connect time: " + str$(d-b)
else
   print #1 "Failed to Connect"
endif
if (e)
   print #1 "Connection dropped: " + str$(e-b)
endif

print #1 "    INPUT$(4) time: " + str$(c-b)
print #1 "      Cmd Response: " + A$
A$ = INPUT$(4)
print #1 "      Cmd Response: " + A$
Print #1 "         Status(3): "; status(3)

Print #4 "</>"               ' close connection
[/font][/color]

The print #1 statements send messages over a serial port that was used to monitor the behaviors.

The following are the descriptions of the test cases, the captured results and my annotations:

/*
   This is what I observed for a successful connection:

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4344         <-- non-blocking TCP command
      Connect time: 434091         <-- TCP connected in 43.4ms
    INPUT$(4) time: 856717         <-- response avialabe in 85.7ms
      Cmd Response:
      Cmd Response: 56866 14-07-28 19:31:53 50 0 0 906.4 UTC(NIST) *
         Status(3): 1            <-- TCP still connected?

   Forced connection failure.  Ethernet cable disconnected. Online monitoring
   not used.

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4394         <-- non-blocking TCP command         
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 19739621      <-- 2 second timout
      Cmd Response: ERR:01-Connect Fail   <-- useful error message
      Cmd Response:
         Status(3): 0            <-- TCP not connected

   Forced connection failure.  Online monitoring established and then the
   Ethernet cable was disconnected.

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4323         <- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 30026965      <-- This is test firmware timout
      Cmd Response:               <-- No error message from TCP/IP stack
      Cmd Response:
         Status(3): 0


   This is what I see if we use a valid URL with wrong port number:

>>> <TCPCONNECT 64.250.229.100>
         Status(3): 0
     Print #4 time: 2487         <-- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 4064         <-- very little delay to error msg
      Cmd Response: ERR:03-Invalid URL   <-- useful error message
      Cmd Response:
         Status(3): 0

   This is what I see if the server initially connects then drops the connection
   without sending the time response:

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0            
     Print #4 time: 4476         <-- non-blocking TCP command
      Connect time: 440977         <-- 44ms to TCP connection indication
Connection dropped: 1262044         <-- 126ms to TCP connection loss
    INPUT$(4) time: 30023768      <-- timeout in test code
      Cmd Response:               <-- No error message
      Cmd Response:
         Status(3): 0
 */
[/font][/color]

Gary D