 |
Viper General PLC Setup
Overview
This guide with general information is designed to assist PLC/system setup and for Ladder logic program setup. The focus is on TCP communication. UDP is often friendlier to on-air networks since it requires less handshaking/overhead. But often TCP is the only choice available on PLCs. PLC communication via serial lines or serial terminal server is not covered here, never the less the general information could apply.
General
POLLING REMOTE PLCS WITHOUT UNSOLICITED MESSAGES
When polling from a master PLC multiple remote PLCs over the RF network, the polling method used has an important influence. To minimize on-air congestion / collision, it is best to sequentially time the polling to each remote and have remotes doing none or few unsolicited inbound messages, also doing few or none remote-to-remote PLC messages.
The master should be setup:
Sequentially poll next remote PLC when detecting the ladder logic "done" bit or equivalent message complete operation, or on the ladder logic "error" bit or equivalent (could be timeout or other).
Wait for example 200 msec before polling the next remotes. This allows TCP handshaking to complete. For some systems it may be more or less, and therefore may require tuning afterwards.
POLLING REMOTE PLCS WITH UNSOLICITED MESSAGES AND REMOTE-TO-REMOTE PLC MESSAGES
Polling using unsolicited messages is less preferred then when polling sequentially each remote from the master only.
In this case more on-air collisions can occur since messages from the master PLC destined to the remote PLC and messages from any remote destined to the master could have been sent on-air at the same time. These messages will be retried by the Viper (router mode) and if successful all is fine. If the system traffic is loaded by many remotes and masters sending messages, then many message retries are done and throughput goes down. The Viper protocol has mechanisms to handle contention, but sometimes there is just too much to handle.
When unsolicited and/or remote-to-remote PLC messaging is required, then it is important to time or limit the amount of these messages.
For example, the master sequential poll could be setup to give some free airtime between each poll to allow unsolicited messages from remotes or between remotes to use the free airtime to exchange messages. The time to wait between messages depends on overall network load and may only be adjusted once the system is running. Maybe start by using a one second gap between polls, or derive a value based on the project traffic load.
There are different ways to achieve free-up on-air time to allow others to communicate. Other ways could also be ok as long as free on-air time gaps are often accomplished. For example it may not be good to have a gap every 30 seconds only!
Sometimes polling less often helps to reduce traffic and improve response.
POLLING REMOTE PLCS NON-SEQUENTIALLY
Polling messages non-sequentially, where several poll requests are initiated asynchronously overlapping each other is not recommended since it is less efficient. But if the system cannot be converted or designed with sequential polling, then some of the approaches used above for unsolicited messaging control (adding free on-air time) may need to be applied.
MESSAGING WITH TCP AND TCP CONNECTION TIMEOUT
TCP is a stream protocol where lost parts of the data stream are being retried by the low level TCP driver of the PLC.
Often the higher-level application of the PLC can function with TCP, UDP or other. These applications therefore have message timeouts to allow retransmission of a presumed lost or delayed message. With TCP this is not really required since the low level driver will keep on trying and will only terminate the connection when tries are exhausted.
It is important to set the application message timeout long enough to minimize the application retrying above the TCP driver retries. For example if the reply for message 1 was not received in time due to temporarily network congestion or outage, and the TCP low level driver still keeps on trying, then the application could end-up sending additional messages (2, 3 and so on). During this congestion or temporarily short network outage period, the retried messages by the application could result in a backlog of outstanding messages and then on recovery resulting in a temporary sort of network storm that may take some time to recover or sometimes turns into a TCP connection failure/termination.
For this case it's better for the application to wait longer than trying to resend the message too quickly resulting in possible multiple responses or connection problems. The application message timeout should not be made way too long since it may be used by the PLC application to terminate the connection.
A good value for TCP connections timeout that seems to work well is 20 seconds. This gives 20 seconds time to make a new TCP connection. On busy or temporarily congested / multi hop system, 25 or 30 seconds works better. These settings are required for master PLC and remote PLCs.
For message timeout 10 seconds is often good, but on busy or temporarily congested / multi hop system, 15 seconds works better. These settings are required for master PLC and remote PLCs.
If the system is often overloaded then monitoring is required to determine the cause and the delays. Traffic could be reduced or timeout needs to be increased.
OPENING A NEW CONNECTION WHILE PREVIOUS TCP CONNECTION IS STILL IN PROGRESS
The PLC should not re-open a new connection while the last one for the same remote PLC is still in progress.
When a TCP connection is attempted by the application the low level TCP driver will perform several retries to achieve the connection. Often the original TCP connection SYN message is sent then two more are retried using exponential backoff timeouts. This often results in 21 seconds (3 +6+12) for all 3 tries. If the PLC application or sometimes the TCP driver does not wait for the timeout to occur before starting a new connection, then multiple connections to the same destination could be in progress. If the PLC only accepts responses from the last connection attempted, all previous delayed SYN-ACK responses are ignored or terminated.
Note: Making a TCP connection or connection attempt is the initial process to open a TCP connection between two PLCs (also called Endpoints). Once the initial connection message exchanges are completed, the connection is open and ready for data message exchange use.
The above re-open connection scenario can easily occur at: startup of PLC polling, a remote not responding or when temporarily network outage occurs. Having the PLC retrying new connections too quickly and on multiple remotes at the same time results in a sort of message storm, resulting in more congestion.
The PLC application, ladder logic and/or TCP driver should set to wait for the complete connection timeout before starting a new one. Depending on the on-air bandwidth and the number of PLC remotes, only one or a few connection-attempts should be outstanding.
If this cannot be accomplished, then extend the TCP connection timeout to 20 or even 25 seconds. Verify that no other adverse impact occurs.
CLOSING OLD TCP CONNECTION
The PLC should close old TCP connections if no longer required.
When a TCP connection is no longer required, without response or determined not usable, then the PLC should close it. Leaving these unused TCP connections open consumes Viper internal resources (limited) that could have been used for new connections (Viper TCP proxy buffer resource).
SENDING FRAGMENTED MESSAGES
For best performance the PLC should use single request message and the response from the remote should also be a single message.
Sending multiple small or fragmented TCP messages over the on-air network is less efficient than grouping the responses for example into a larger single message. Due to TCP/IP message overhead and radio on-air overhead, a small user message with its overhead is much less efficient than multiple small user messages grouped into a single slightly larger message. Also the on-air protocol often has to negotiate the on-air medium to be able to transmit a message, depending on collision/retries and traffic, the performance is further affected.
HEARTBEAT MESSAGES
Sending heartbeat messages is generally not recommended.
Heartbeat messages should be disabled where possible. If this is not possible then heartbeat messages should only be sent from one endpoint. Their interval should be 4 minutes and start 4 minutes after connection idle time (no data sent in either direction).
If heartbeats are used, depending on the number of connections using them and their interval, the resulting traffic load needs to be evaluated to assess their impact on the on-air network traffic.
AVOID UN-NECESSARY TRAFFIC OVER THE AIR NETWORK
MONITORING REMOTE PLCS WITH MONITORING APPLICATION TOOLS
Continuously monitoring remote PLCs for monitoring purposes only via the on-air network adds additional traffic. This should be avoided unless required. Some of these software tools are made to run on local networks (high bandwidth) rather than over the air. If used set their timeouts as described above in “Messaging with TCP and TCP connection timeout”.
Some applications when closed still leave their TCP communication layer running. So even if the main display is closed background monitoring still occurs. If suspected use Wireshark to capture if communication persists, or turn the monitoring PC temporally off to view impact.
REMOTE ALIVE CHECK
Sometimes the PLC could perform pings in parallel to the communication connection. The ping result may be used to determine the presence of the remote or the master. This should be disabled where possible. If required, change ping interval to every 5 or 10 minutes. Check with PLC manufacturer for advice.
MESSAGING WITH TCP - OPEN AND CLOSING TCP CONNECTION FOR EACH POLL
Opening and closing TCP connection for each poll is not recommended.
Opening and closing a TCP connection requires 2-3 times more in and out messages then messages for a simple poll. This increases the on-air traffic and adds extra delays for the polling.
It is best to open all the TCP connections at the beginning when starting the poll and closing the TCP connection when poll is stopped. Unsolicited messages done at non-regular intervals and more than 4 minutes apart for the same remote should open and close the TCP connection for each message group.
Having a polling interval of more than 4 minutes for the same remote PLC or having a mixed (more than 4 minutes and less than 4 minutes) interval for unsolicited messages, the TCP connection should be opened and closed each time. With the Viper in proxy mode, after 5 to 10 minutes of inactivity, the Viper will remove the internal proxy context and resume the connection without proxy. Therefore the benefit for proxy is lost.
When opening and closing is required than the additional traffic load for TCP open and closing needs to be planned into the system design.
SAFE LADDER LOGIC – (SUGGESTION)
When on PLC controls remotely important operations of another PLC, it would be good to have ladder logic protection in case of communication failure with remote.
For example one PLC is at the pump station, the other at the tank station. To avoid tank overflow in case of communication loss, it could be possible to design the logic for the pump PLC to detect that if no data message were received for over 10 minutes from the tank PLC, to turn its pumps off if they were running.
For example the remote PLC inactivity timeout could trigger this or some other method of detection.
PLC LADDER LOGIC ON RESTART OPENS ALL CONNECTIONS AT ONCE INSTEAD OF SEQUENTIALLY
When PLC ladder program is setup to have at startup all write message rungs set to true, all TCP connections are triggered "simultaneously". This creates an overload of TCP SYNs and somewhat could congest the on-air traffic depending on the system.
It is recommended to setup the ladder write message rungs not to start up simultaneously. Write messages should be setup to open the TCP connection sequentially. For more information it may be required to contact your PLC provider.
Viper
SETUP VIPER IN ROUTER MODE (INSTEAD OF BRIDGE MODE)
Info: Viper Bridge mode cannot filter keepalive and cannot operate in TCP proxy mode.
If the system has very few units and few messages Viper Bridge mode could be used. But for larger systems and PLC doing many keepalives, or on-air network being contentious, it may be required to use router mode. Router mode allows retransmission of messages lost due to on-air contention. Bridge mode only does broadcasts without retries. In Bridge mode the application needs to retry lost messages.
FILTERING TCP KEEPALIVE WITH VIPER TCP PROXY MODE
When using TCP protocol and having PLCs where the TCP keepalive rate cannot be controlled, it is important to enable Viper TCP (OIP proxy) mode. This requires that all Vipers are configured in router mode (Viper Bridge mode cannot filter keepalive and cannot operate in TCP proxy mode).
Note: For PLCs where the keepalive can be controlled and are required, set keepalive to 4 minutes.
One of the Viper's TCP proxy mode usages allows filtering of keepalive messages and prevents them to be sent over the air. Without this filtering, several PLCs sending keepalive messages could easily load the on-air network.
See Viper User Manual and Web pages to enable proxy. By default Viper proxy mode is enabled. See Viper Web page Advanced setup -> OIP optimizations. Also under Network management -> Neighbor Tables (neighbor management) make sure that neighbors are configured with the proxy attribute.
REPLACING OR RESETTING A VIPER USING PROXY MODE WITHOUT RESTARTING POLLING
When replacing or resetting: a remote Viper, a Viper used as a repeater, or even a master Viper connected through a switch, the Viper proxy context is lost and will operate without the proxy benefit.
To reestablish TCP proxy context for the TCP connection, the PLC needs to close the old TCP connection and re-open a new TCP connection. Therefore normally after doing Viper maintenance the master PLC needs to be restarted. Future Viper firmware may reestablish proxy automatically.