WIZCON Modbus over GPRS (TCP/IP) Q?


Thread Starter


Could someone advice me about communication setting, because the bad experiment now I tested.
some question topic:
1. How to define block setting timeout.
2. Method of tunning communication for modbus (TCP/IP)

Thank you

Lynn A Linse

If you are using Modbus/RTU in TCP - best of luck :)-) - cellular systems have huge latency issues. I've been doing a lot of work with cellular and say I send 1000 polls, 995 will perhaps obtain responses within 2 seconds. But the other 5 will take from 3 to 30 seconds. And since you are using TCP/IP you are guarrenteed the response (even if it takes 60+ seconds) will return. Thus your Master MUST never send a 2nd request if there is a risk of misunderstanding the 1st response coming back too late.

The cellular systems also aren't fully TCP/IP compatible. For example, on some carriers if a TCP socket sits idle longer than 5 minutes ... it
just goes away. I don't mean it closes, I mean the "middle" of the connect goes away without any TCP RST or FIN. Both ends are happy, thinking they are connected, but next time either end tries to send a TCP packet it just goes into the bit bucket - no response. So you'll get into the full TCP retry/backoff issue. And all of the time, every TCP packet is chewing 40+ bytes out of your data plan. Only after you've exhausted your TCP retries does the active end understand the socket is gone - but keep in mind the OTHER end of the connection is unaware of this. It never saw any TCP requests or retries.

You didn't meantion the product vendor you are using, but there could be many other issues occuring.

For example, the Digi cellular devices keep the IP link up all the time at no cost. Thus opening sockets may be slower than normal, but not unreasonable so. Many other vendors let the cell modem "sleep" when idle to save power. However this greatly increases the time required to
open a TCP socket. Many applications won't wait long enough and you end up with the first open failing and a 2nd working due to the modem being
awake. However, how many TCP apps expect this behavior on Ethernet?

Speaking of opening sockets - that is another big problem. Windows seems to default to assume a socket opens in 3 seconds or less. That is pretty fast for a cellular system, so you can end up with a ping-pong effect where Windows opens the socket (sends a [SYN]) but by the time the remote device can return it's [ACK] and [SYN], Windows has given up on that open and sends a [RST]). Worse, if Windows retries the open too fast, you risk the 2nd open [SYN] reaching the remote device before the first [RST] since they are different sockets and thus the remote device
STILL THINKS the first socket is active and rejects the 2nd open just in time to receive the 1st delayed [RST]. And on it goes.

Anyway - you can tell I've had a LOTS of fun trying to make sense of IP-enabled cellular. Bottom line you can not trust that any program (in your case WIZCON Modbus in TCP) will work with IP-enabled cellular if WIZCOM hasn't tweaked Windows away from it's default TCP/IP behavior. I have both Modbus and Rockwell PLC up on one of our cellular products and I allow partners to test their app against them. So I know that Kepware OPC works, but cannot comment on others.

best regards
- LynnL, Industrial Specialist, www.digi.com