 |
Allen-Bradley PLC for Viper System
Overview
A guide to assist with Allen-Bradley MicroLogix 1400 and 1100 communication setup between master PLC and remote PLC using AB TCP protocol between PLCs. Some information may apply to AB SLC 5 PLC.
PLC communication via serial lines or serial terminal server is not covered here, never the less some of the information could apply.
NOTE: Please consult the “Viper General PLC” app note for important information on systems with PLC setup.
Allen-Bradley Micrologix 1100/1400 (May Apply to SLC 5)
Below is a list of important settings to improve communication when used with a limited bandwidth Viper network. More information on communication can be found in the General PLC app note for Viper system document.
NOTE: When required, contact your PLC provider or Allen Bradley / Rockwell Automation support.
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 contact your PLC provider or Allen Bradley / Rockwell Automation support.
PLC SENDS TO MANY “CIP FORWARD OPEN” AND “CIP FORWARD CLOSE”
After the TCP connection is first established, then the CIP Forward Open command is sent to open the CIP connection. As long as there is always communication activity over that connection within 8 times the “message reply timeout” of channel 1, there will be no more CIP Forward Close commands sent (results in fewer messages sent over the air – good).
Often the channel 1 “Msg Reply Timeout” is set to 3000 ms this would generate additional “CIP Forward Open” and “CIP Forward Close” messages on-air if the polling interval exceeds, 3 sec x 8 = 24 seconds.
When the polling interval is longer, “CIP Forward Open” and “CIP Forward Close” messages add 4 (includes msg reply) extra messages on-air for each unit polled. If each poll is 2 messages (msg and reply) the 4 extra messages increase the message load (on-air) by 200%.
Example:
A system is setup for the PLC to poll the remote PLCs every 120 seconds and is set to wait for the next poll loop if polling is not completed after the 120 seconds, therefore the loop turns into 240 seconds.
Take the 240 seconds and divide it by 8, this gives 30 seconds. Set the “Msg Reply timeout” on channel 1 to 30000 msec or 32000 msec if some margin is required.
More on “Msg Reply timeout”
The message reply timeout is also used for retransmissions of messages in case there is no reply. Since a TCP connection is used the retransmissions are normally not required. Therefore with TCP longer timeouts within reason are ok.
The “Msg Reply Timeout” on channel 1 settings of the PLC should be set as per value determined by the above example and since traffic is on-air and is retried and TCP driver performs its own retries, the:
“Msg Reply Timeout” minimum = 10000 msec
“Msg Reply Timeout” maximum = based on value determined by the above example
With future releases of PLC software/firmware the described operation could change. It is always recommended to be informed on PLC release changes from your PLC provider or Allen Bradley / Rockwell Automation support.
PLC SENDS MANY TCP/IP KEEPALIVE MESSAGES
Seen on MicroLogix 1100, 1400 and on SLC 5.
The PLC sends many IP keepalive messages that are sent on-air. When several PLCs do the same it is possible that a good part of the on-air bandwidth is used up by the keepalive traffic.
We recommend that the Viper is configured in router mode and that TCP proxy is enabled. The Viper TCP proxy feature will filter out the TCP/IP keepalive messages.
Recommended to Allen-Bradley / Rockwell Automation to have an option in the PLC settings to disable keepalive and having user settable keepalive intervals. This could potentially become available in future releases of PLC firmware.
PLC RE-OPENS TCP/IP CONNECTION WITH THE SAME SOURCE PORT
Seen on MicroLogix 1100, 1400 and on SLC5.
When the PLC is re-started it uses the same TCP/IP connection source port previously used.
Note: The SLC5 also uses the same source port for each new connection without PLC restart.
The older Viper firmware, when in router mode and having TCP proxy enabled, does not allow the new TCP connection to go through immediately if the same TCP source port is used and if the PLC did not terminate the old connection. After the old TCP proxy connection timeout the new connections are ok.
Starting with Viper firmware v1.10 and ViperSC firmware v3.2, new enhancement was added to allow new connection created when using the same source port.
Recommended to Allen-Bradley / Rockwell Automation to have the TCP source port randomized when the unit is restarted. This could potentially become available in future releases of PLC firmware.
PLC DETECTING COMMUNICATION FAILURE WHILE VIPER TCP/IP FILTERS KEEPALIVES
The PLC should not re-open a new connection while the last one for the same remote PLC is still in progress.
Seen on MicroLogix 1100 and 1400.
When the MicroLogix PLC sends messages but does not get response messages it will still keep the TCP connection open forever as long as the Viper ACKs the keepalives. Even if the PLC application reports communication loss at the PLC application level, the PLC will not open a new connection. This is often a result after having communication issues with remotes.
New firmware is available from Allen-Bradley / Rockwell Automation for the MicroLogix 1100 and 1400.
Allen Bradley MicroLogix firmware overview at the time of writing this document.
For website downloads:
http://www.ab.com/linked/programmablecontrol/plc/micrologix/downloads.html
MicroLogix 1100 series B (FRN 4 and above are Series B):
MicroLogix 1100 series B before FRN 10 require to be upgraded to FRN 10 (released)
MicroLogix 1400 series A:
MicroLogix 1400 series A before FRN 6 require to be upgraded to FRN 6 or 7 (released)
MicroLogix 1400 series B:
MicroLogix 1400 series B before FRN 11 require to be upgraded to FRN 11 (released)
For other Micrologix models, please contact Rockwell Automation Tech Support help line.
Viper
SETUP VIPER IN ROUTER MODE (INSTEAD OF BRIDGE MODE)
Note: 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.