MODBUS transmission modes

N

Thread Starter

NSR Prasad

Do we have the liberty to choose the Message format as ASCII in MODBUS protocol if nothing is specified by user? Can we choose the transmission method as ASCII in a MODBUS network if the customer does not specify the mode of transmission. Or we should implement RTU mode as default mode and ASCII as optional.
 
P
Hi, I would not bother with Modbus ASCII. I have never seen it used, and have never had a reason to use it. A very long time ago I recall investigating Modbus ASCII and vaguely recall it being pretty restrictive and inefficient. It may have disappeared along with 7bit Serial comms. Very few vendors provide Modbus ASCII, I certainly wouldn't use it as a default.
Cheers, PB
 
RTU seems to be far more common, at least in serial communication. So far I have never needed the ASCII version, as comparation RTU is used in 100+ apps.
 
L

Lynn at Alist

No, $$-wise you do not really have a liberty. I'd guess the following based on about 20 years of Modbus work:
- maybe 1% of devices ONLY speak MB/ASCII
- maybe 40% speak only MB/RTU
- the rest speak either RTU or ASCII at user option

The main value of Modbus/ASCII was with commercial modems couldn't handle 8-bit data. About 10 years ago, some could handle 8-bit data, but only if you didn't send 1 or 2 specific values which caused modem cammands to activate. I don't think that's such a problem anymore, plus more and more systems are using TCP/IP based comms for remote access.

So you should do Modbus/RTU first - add Modbus/ASCII if you have the space but it has little urgent $$$ value in a product.

Best regards
- LynnA Linse, www.digi.com
http://www.iatips.com/contact.html
 
B

Bob Peterson

Most venders I have seen provide both RTU and ASCII. ASCII had a huge advantage when using it compared to RTU as it was much much easier to do a limited scale driver especially with a basic module type device.

Bob Peterson
 
B

Bob Peterson

This is one of those sort of true things. Commercial modems can indeed do Modbus RTU (8 bit), but they cannot handle it if you use the parity bit as well, since it exceeds the fram capacity of the modems. By default most Modbus products use RTU with parity, so they cannot be used over a standrad hayes compatable modem at all. If you can change the parameters of the remote device to no parity, it will work. However, many devices give you only two choices, or only two easy choices, and one of them is ascii which always does work over a modem even with parity since it has one less bit in the frame.

The other problem with modems and RTU is that often the modem will break up a modbus message into multiple packets to use its compression software. This is fine with ascii mode, but can make rtu mode a mess. If you must use RTU
mode over a standrad modem, you often have to turn off compression in the modem.

I am not 100% sure that today's modems have these issues anymore since I have not tried it lately, but there are plenty of old devices and old modems still out there.

ASCII mode is much easier to implement then RTU so there is probably no reason not to do it.

Bob Peterson
 
L

Lynn at Alist

Yes, Bob makes a very good point. Modbus/ASCII would be critical for a software Master (who may see old slaves). And as he says, it is very easy to add. I just felt the original context of the question was should a small slave device under development use RTU or ASCII.

For sure I would NOT build a Modbus/ASCII-only device, but if code space was tight I would build a Modbus/RTU-only device. I guess I should have said it that way.

If the remote slave is "smartly" designed (detecting 'expected' message size as it's received), then even Modbus/RTU thru a modem or wide-area-network works fine. The end-of-message detection is smart enough NOT to be fooled by the time-gap. WAN TCP/IP systems moving encapsulated serial protocols often have more extreme fragmentation than error-correction dialup modems. Time-gaps within packets of TCP/IP encapsulated Modbus/RTU or ASCII can easily be longer than 1 second.

best regards - LynnL www.digi.com, Snr Prin Engineer for email address see: http://www.iatips.com/contact.html
 
Top