Blocking Network Commands?

[garysdickinson]

I'm working with a FMD1616-10 with firmware r82A

I've noticed that the network DNS command:

PRINT #4 "<DNS time.nist.gov>"

Has a blocking behavior.  The PRINT #4 command does not return until the TCP command has completed (or failed).

I've used the following code to verify this behavior:

' Demo of DNS Blocking command behavior
'
Print #4 "</>"
DELAY 100

A$ =  "<DNS time.nist.gov>"
a = status(21)               ' timestamp
PRINT #4 A$                   ' Send DNS command
b = status(21)               ' timestamp
A$ = INPUT$(4)
while (len(A$) = 0)
   A$ = INPUT$(4)
endwhile
c = status(21)

print #1 " Print #4 time: " + str$(b-a)
print #1 "INPUT$(4) time: " + str$(c-b)
print #1 "  Cmd Response: " + A$

[/color]
This is what I see when the DNS command is successful:

 Print #4 time: 520132
INPUT$(4) time: 1812
  Cmd Response: 24.56.178.140
[/color]

This shows that the Print #4 command took about 52 mS.  The entire loop polling for command completion took about 180 uS. It appears that this is no reason to poll for the response from the DNS command

This is what I see when the DNS command fails because I pulled the Ethernet cable from the PLC (command time out):

 Print #4 time: 20013005
INPUT$(4) time: 2012
  Cmd Response: ERR:07-DNS Unresolvd
[/color]

I observe that the Print#4 statement took 2 seconds to fail.  The issue is that the ladder logic is locked up for 2 seconds. The loop to check for the response took about 200 uS. This adds to the evidence the that Print #4 command is blocking and does not complete until either the command completes or the TCP/IP stack times out.

So I have the following questions:

1. Is there a special setting to make the Print #4 command non-blocking?  I would like to have the PRINT #4 command execute quickly and periodically poll for the result.  Non blocking, yes?

2. Is there a very fast way to determine if the PLC can communicate with the network without locking the PLC up for 2 seconds? Ping?

3. Do other TCP commands have this same blocking behavior?  I'm would like to be able to connect to FTP servers and time servers without locking the PLC up until stuff completes.

4. Why does the Nano-10 manual programming example  for "DNS command:" use polling when the commands blocks? No need to poll.

PRINT #4 “<DNS tri-plc.com>“
FOR I = 1 to 10000
  A$ = INPUT$(4)
  IF LEN(A$) <> 0
    SETLCD 1,1,” IP=”+A$
    RETURN
  ENDIF
NEXT
[/color]
Thanks,

Gary D.

[support]

You are right that the PRINT #4 "<DNS>" does wait for the DNS listener to return a resolved IP address for up to 2 seconds and if it doesn't get a successful resolution it will report DNS unresolved. This is fixed in the firmware and not user-modifiable.

The other commands that could block for a certain period of time is the <RemoteFS> tag and the <FTP> tag if there is no network connection to the server..

You could test for the server availability by using the <TCPCONNECT> tag to make a connection (using IP address instead of domain name) and if the connection is unsuccessful then do not run the other network command tags that could lead to blocking.

If there are time critical events that need to be handled, then define the relevant input as interrupt inputs or run a periodic interrupt custom function to process time critical event so that they are not affected by the network command blocking action.


 

[garysdickinson]

Thanks for the response.

The blocking/non-blocking behavior of the network commands are simply not documented. The programming examples suggest that the commands are non-blocking.

I will try to figure out how to make a system tolerate a minimum of 2 seconds of lockup (ladder logic scanner not running).  This is not an easy thing to accommodate nor explain to a customer.  The idea that a customer's system will, periodically become non-responsive to INPUTs for several seconds, will be a very difficult to explain as being a good thing.

Gary D.