Difference between revisions of "Protocol decoder:Modbus"

From sigrok
Jump to navigation Jump to search
(Looking back at the capture I was talking about, the trick I mentioned here didn't actually work, so I shouldn't mention it.)
(Some copy editing (e.g. ref. <https://en.wikipedia.org/wiki/RS-485> and <http://en.wikipedia.org/wiki/RS-232>).)
Line 14: Line 14:
}}
}}


The '''modbus''' decoder supports the [https://en.wikipedia.org/wiki/Modbus Modbus] bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus Ascii.
The '''modbus''' decoder supports the [https://en.wikipedia.org/wiki/Modbus Modbus] bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus ASCII.


== Protocol ==
== Protocol ==
Modbus RTU is a single client, multi-server protocol that is normally used over RS485 for simple networks of devices. It can also be used over RS232.
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:
It can be used in several different setups, but normally it's used with the following settings:
Line 25: Line 25:
;Stopbits: 1 or 2
;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.
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&rarr;server and server&rarr;client messages have the same format, it can be impossible for a logic sniffer to determine which is which.
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&rarr;server and server&rarr;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 [http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf V1.1b3]
Modbus is an open protocol that is managed by the Modbus organization. The newest version of the specification at the time of writing is [http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf v1.1b3]


== Decoding ==
== Decoding ==
The decoder always decodes the TX output from the UART decoder as client&rarr;server.
The decoder always decodes the TX output from the UART decoder as client&rarr;server.


The ''channel'' setting determines which channel will be interpreted as server&rarr;client, RX or TX.
The ''channel'' setting determines which channel will be interpreted as server&rarr;client, RX or TX.
=== RS485 ===
Most Modbus RTU happens over a RS485 bus. The problem is that the decoder can't tell if a message is meant to be client&rarr;server or server&rarr;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 RS485 you usually have only one UART channel, and that should be set to TX. Server&rarr;client communication is on the TX channel, so set the option in the modbus decoder to 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&rarr;server or server&rarr;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.


For the physical interface, the neatest thing to do is to use some kind of converter to convert the differential RS485 bus to a signal line (relative to ground). In practice you can get away with other solutions.
So for RS-485 you usually have only one UART channel, and that should be set to TX. Server&rarr;client communication is on the TX channel, so set the option in the Modbus decoder to TX.


Properly terminating the RS485 bus can do a lot to improve signal quality.
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.


=== RS232 ===
Properly terminating the RS-485 bus can do a lot to improve signal quality.
In some applications the client will be connected though a RS232/RS485 converter. In these cases it's easier to probe the signal on the RS232 side. So the TX line of the UART decoder should be set to the clients TX line.
 
=== 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&rarr;client communication is on the RX line, so set the channel setting to RX.
In this case the server&rarr;client communication is on the RX line, so set the channel setting to RX.


You probably have to invert the signals, you can do this with the UART decoder.
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 RS232 is allowed to reach. For their older models, Saleae recommended putting a 10k&Omega; resistor in series with the probe.
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&nbsp;k&Omega; resistor in series with the probe.

Revision as of 18:33, 8 July 2017

Modbus
Pd modbus.png
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.