Protocol decoder:Modbus

Modbus

Name	Modbus RTU
Description	Modbus RTU
Status	supported
License	GPLv3+
Source code	decoders/modbus
Input	uart
Output	Modbus
Probes	—
Optional probes	—
Options	channel

The modbus decoder supports the Modbus bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus ASCII.

Protocol

Modbus RTU is a single client, multi-server protocol that is normally used over RS-485 for simple networks of devices. It can also be used over RS-232.

It can be used in several different setups, but normally it's used with the following settings:

Baud rate

19200

Parity

none or even

Stopbits

1 or 2

Modbus RTU is a client/server (or master/slave) protocol, where one device on the bus is a client, and the rest are servers. The client makes a request and (usually) a client responds; there is no other communication. Every server has an id between 1 and 247, these have to be set in advance.

Every message starts with the server ID (or 0 for broadcast messages), then the function code. It ends with a 2 byte CRC. Because both client→server and server→client messages have the same format, it can be impossible for a logic sniffer to determine which is which.

Modbus is an open protocol that is managed by the Modbus organization. The newest version of the specification at the time of writing is v1.1b3

Decoding

The decoder always decodes the TX output from the UART decoder as client→server.

The channel setting determines which channel will be interpreted as server→client, RX or TX.

RS-485

Most Modbus RTU happens over a RS-485 bus. The problem is that the decoder can't tell if a message is meant to be client→server or server→client. The solution Sigrok uses is to decode it as both, and let the user decide which of the two outputs it the correct one for that message.

So for RS-485 you usually have only one UART channel, and that should be set to TX. Server→client communication is on the TX channel, so set the option in the Modbus decoder to TX.

For the physical interface, the neatest thing to do is to use some kind of converter to convert the differential RS-485 bus to a signal line (relative to ground). In practice you can get away with other solutions.

Properly terminating the RS-485 bus can do a lot to improve signal quality.

RS-232

In some applications the client will be connected though a RS-232/RS-485 converter. In these cases it's easier to probe the signal on the RS-232 side. So the TX line of the UART decoder should be set to the client's TX line.

In this case the server→client communication is on the RX line, so set the channel setting to RX.

You probably have to invert the signals, and you can do this with the UART decoder.

Some logic analyzers are not rated for the high voltages that RS-232 is allowed to reach. For their older models, Saleae recommended putting a 10 kΩ resistor in series with the probe.