Owners manual

6: Troubleshooting and Technical Support
Modbus Protocol User Guide 27
Device Server can only process on average 290 of those per minute and some
carry over. After 10 minutes, you may have up to 100 “stale” responses waiting in
your master’s TCP buffer. This makes it appear as though there is now a 20-
second “lag” in data reaching the master. Here is the source of your “data
taking longer and longer to propagate to Master/Client” problem.
However, if the master does implement Modbus/TCP sequence numbers, then
the stale responses are rejected. If the master is smart enough to resynchronize
itself (Response #B does not kill poll #C, but master waits more), then this
resynchronization will manifest itself as the slaves going off-line and back on-
line intermittently. If the master is not smart enough to resynchronize, once this
out-of-sync behavior occurs, your slaves go permanently off-line.
As you can see, this Modbus/TCP master is out of sync and the only cure may be to
either restart the master or power cycle the IAP Device Server. Both actions close the
socket and purge the backlogged messages.
Our Network-to-Serial product brings out this shortcoming in master/client
Modbus/TCP designs, but even a pure MB/TCP-to-MB/TCP network would suffer
from this problem if the poll cycle approached the average response time. Any
Modbus/TCP network going through WAN will discover this.
Ideally all Modbus/TCP master applications must implement the sequence number
and gracefully handle receipt of stale responses with unexpected sequence numbers.
Unfortunately, the Modbus/TCP specification says that this sequence number is
optional and can be used by a master to match responses to requests; however it
can usually be just left as zero. The Modbus/TCP slave just echoes this back in the
response. So most Modbus/TCP OPC servers today do not implement the sequence
number.
Fortunately, a second generation of Modbus/TCP masters is starting to come that
understands the issues of dealing with an IAP Device Server to serial. So what is
your solution if your Modbus/TCP master is first generation?
 Slow down your poll rate. You have to consider the worst-case response time
– assume all polls timeout. If you have five slaves that normally answer in
less than 100 msec each, but you must use a 250-msec message timeout,
then polling each of the five 1.25 sec is the only promised safe rate.
 If you are only polling a single slave (or poll one slave at a time), then you
can try the “Disable Pipeline” option in the IAP Device Server firmware. This
will either help or make things hopelessly worse. If your OPC server or host
application relies on pipelining to send more than one outstanding poll at
once, then disabling the pipeline will essentially stop all data communication.
(In which case, you can just turn the pipeline back on!)
 The ideal solution (the 2nd generation solution) is for your Modbus/TCP
master/client to not only support the Sequence Number, but also support the
receipt of the 0x0A and 0x0B extended Modbus/TCP exception response.
Then the master/client never needs to do retries – for each poll, it will
receive either a value Modbus/TCP response or a Modbus/TCP exception
that the slave is unreachable or timed out. This prevents the master/client
from sending more polls than the IAP Device Server can process and
building the TCP buffer queue up in the first place.