modbus rtu or modbus tcp over radio

J

Thread Starter

joey e

we need to connect 30 subsystems via Modbus to the main controller over radio interface. the radio network has a very low bandwidth (max 19kbps).

Considering that Modbus TCP header size is more than Modbus RTU. Does this mean that Modbus RTU over radio is the best solution?

thanks,
joey e
 
In the US, Modbus RTU runs over wireless serial modems that have with 19k baud over-the-air throughput rate.

But Modbus/TCP can be carried by 900MHz industrial ethernet wireless radio modems at 400-500K baud throughput with better range and punch through than 2.4GHz WiFi.

Are you sure this radio you're talking about is Modbus/TCP slowed down to 19k?

I suspect your 19K radio is ready to use with Modbus RTU.
 
Since the difference between a message in the modbus TCP and modbus RTU protocols is 5 extra bytes in the header and dropping the 2 byte crc, its only 3 bytes more in each TCP message.

This is really insignificant since at 19200 bps, it works out to
3bytes = 30 bits (approx with start & stop bits)
30b / 192000bps = 0.00156sec = 1.56 msec
This much extra wouldn't really slow things down.

I'm not sure if you can establish a TCP connection over radios.

If you're not going to send over TCP and therefore not going connect through Ethernet and add the TCP wrapper, it makes sense to go RTU which has the crc for error detection.

I've seen a handful of RTU radio systems, none as fast as 19200. Slowing it down to 9600 baud can sometimes make it more stable and its only half speed. A full 256 byte message would take about a quarter of a second at 9600 baud. Plenty fast enough since they usually don't need to poll that often.
 
L

Lynn August Linse

I think the size is largely irrelevant.

One problem with radio Modbus/RTU has to do with the way most radios 'fragment' data - so a 100 bytes Modbus message might be sent as 2 packets, and you may see a time-gap of say 30-50 msec between the fragments. There ARE radios which understand this and FIX the problem for you - look for radios which are Modbus-aware.

Another problem has to do with 'stale' messages. Suppose you poll slave #3 for 10 registers of data starting at offset 0 (so 4x00001). 2 second later your master gives up and polls slave #3 for 10 registers starting at offset 75 (so 4x00076). When the response of 20 bytes comes back, you have no way to know if the data is really registers #75 - or #0!

One solution is to maintain long enough time-outs to avoid seeing stale responses after the master has timed out the request.

Another solution is to make sure all polls to the same slave are a different length, so in the above case, one block should be 10 registers, and the other 11. That way the Master will see 20 or 22 bytes of data and can detect a mismatch.

Or use Modbus/TCP, which include a 'sequence number' in the header.
 
Hello,

In calculating the amount of data for Modbus TCP/IP you have forgotten include TCP/IP headers and data exchanged on the connection.

Anyway, there is possible to communicate with Modbus TCP/IP even at speed 9600 using the PPP protocol.

Regards
Andrzej
www.modbus.pl
 
E

Eric Ratliff

> There ARE radios which understand this and FIX the
> problem for you - look for radios which are Modbus-aware.

Here is one radio that is Modbus aware http://www.icpdas-usa.com/products.php?PID=3927. It uses ZigBee protocol, and only sends packets up to 50 bytes at once. There is a 'Modbus Mode' that will hold packets in a buffer at the far end till the whole message is present. Then it releases the command.

20 of the 50 byte packets can be transmitted per second. So it is equivalent to about 10K baud.
 
Top