Viper SC+™ IP Router for Licensed Spectrum PN 001-5008-000 Rev. C
| Page 180
APPENDIX J
– VIPER PLC SETUP
PLC AND LADDER LOGIC SETUP
The general information in this section is designed to assist PLC and 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 or
overhead, but often TCP is the only choice available on PLCs. PLC communication via serial lines or serial terminal
server is not covered here, nevertheless the general information provided here may apply.
POLLING REMOTE PLCS WITHOUT UNSOLICITED MESSAGES
When polling multiple PLCs from a master PLC over the RF network, the polling method used has an important
influence. To minimize on-air congestion and collision, it is best to sequentially time the polling to each remote and
have remotes generating none or few unsolicited inbound messages and also making few remote-to-remote PLC
messages or none.
The master should be set up as follows.
Sequentially poll next remote PLC when detecting the ladder logic “done” bit or equivalent message-complete
operation or on the later logic “error” bit or equivalent (could be timeout or other).
Wait for example, 200 milliseconds 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 MES SAGES AND REMOTE -TO-REMOTE PLC MESSAGES
Polling using unsolicited messages is less preferable than polling sequentially each remote from the master only.
In this case more on-air collisions can occur since messages from the master PLC destined for the remote PLC and
messages from any remote destined for the master could have been sent on-air at the same time. These messages will
be retried by the Viper (in 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 made and throughput goes down. The Viper protocol also
has mechanisms to handle contention, but sometimes there is just too much to handle.
When unsolicited 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 set up to give some free air time between each poll to allow
unsolicited messages from remotes or between remotes to use the free air time 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 freeing-up air time to allow others to communicate. Other ways could also be okay,
as long as free on-air time gaps are accomplished often. For example, it may not be good to have a gap every 30
seconds only.
Note:
Sometimes polling less often helps to reduce traffic and improve response.
