Lantronix xPico IAP APS: Modbus Protocol User Guide - Page 31

10: Troubleshooting and Technical Support Only Slave ID #1 can be polled Your application is setting the Modbus/TCP Unit ID field to 0. This causes the IAP Device Server firmware to automatically map this to 1. Every 2nd poll seems to fail Most likely you are using RS485, but regardless, your device probably cannot accept a new poll as fast as the IAP Device Server firmware is sending it. TCP/IP is a full-duplex channel, and since you can have up to 8 active sockets, it is very easy to have a new request already waiting as your last response is being returned. The only solution to this is to slow down your Modbus/TCP masters so they never poll before the last response has been seen. This manually creates the time delay between polls your device expects.  My IAP Device Server runs fine - for about 10 minutes and then my applications start reporting slaves going off-line.  My IAP Device Server runs fine - until a slave goes off-line; then I tend to lose all the slaves or they all poll only intermittently.  Sometimes my IAP Device Server returns the wrong data from the wrong slave.  After a while, the IAP Device Server seems to take longer and longer to answer - after a few hours, it takes 10 minutes or more for systems changes to propagate up to the master/client. All these relate to the same issue - a mismatch in queuing behavior and expectation by the master/client to the new realities of Ethernet. (It is not the IAP Device Server behaving poorly.) Resetting the IAP Device Server fixes the problem (flushes the bloated TCP queues full of stale requests). The core problem is that the master/client is using the old RS485 serial assumption that no answer means poll was lost. However, in the IAP Device Server case, it could also mean the IAP Device Server has not had time to answer (is being overworked). Also remember that TCP is reliable - the IAP Device Server receives all polls sent without error. The result is that the master/client retries, which makes it harder for the IAP Device Server to catch up. Here is the scenario that is causing the problem: 1. Master sends out MB/TCP Poll #A with a timeout of 1000 msec. 2. IAP Device Server receives the poll, but the serial link is busy so it waits - possibly another MB/TCP master is being serviced or timeouts waiting on off-line stations are creating a backlog of new requests. 3. After approximately 850 msec, the serial link is now free and the IAP Device Server forwards the MB/RTU request. 4. The IAP Device Server receives the response, and since the timeout on the IAP Device Server and master are not inherently synchronized, the IAP Device Server sends the MB/TCP response into the TCP socket. 5. In the best of times, it may take 5-10 msec for this response to actually go down the IAP Device Server's TCP stack, across the wire, and up the master's TCP stack. If a WAN or satellite is involved, it could take 750 msec or longer. 6. Meanwhile, before the master receives the Response #A, it gives up and makes the Modbus/RTU assumption that the request must have been lost. The master sends out a new MB/TCP Poll #B. Modbus Protocol User Guide 31