Lantronix XPort APS: Modbus Protocol User Guide - Page 32

10: Troubleshooting and Technical Support 7. A few msec later, there is a response that looks like a good Response #B, but really is Response #A. If the master does not use a sequence number (which many do not) and has forgotten about pending poll #A, it wrongly assumes this is response #B (possibly with catastrophic results if Poll #B was the same size but different register range). Here is the source of the problem "IAP Device Server returns the wrong data for wrong slave." 8. The master is idle and has no outstanding polls. Yet the IAP Device Server has received Poll #B by TCP/IP. It sends this out to Modbus/RTU slave and gets an answer. The IAP Device Server is doing its job! 9. The IAP Device Server returns Response #B to the master (if the socket is still open) and there it sits in its TCP/IP buffer. The master is not expecting more responses, so it neither receives nor purges the "extra" response. 10. Master sends Poll #C and magically finds "a response" waiting as soon as it looks in the receive buffer - yet this is stale Response #B received before poll #C was even issued. If the master does not implement Modbus/TCP sequence numbers, then it accepts the response #B as satisfying poll #C. Imagine if the master is putting out 300 polls per minute (5 polls per second), but the IAP 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 offline. 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 Modbus Protocol User Guide 32