Difference between revisions of "Protocol decoder:Modbus"
(Added information on how to use the decoder) |
(Looking back at the capture I was talking about, the trick I mentioned here didn't actually work, so I shouldn't mention it.) |
||
| Line 41: | Line 41: | ||
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. | 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. | ||
Properly terminating the RS485 bus can do a lot to improve signal quality. | Properly terminating the RS485 bus can do a lot to improve signal quality. | ||
Revision as of 21:14, 28 July 2015
 | |
| 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 RS485 for simple networks of devices. It can also be used over RS232.
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.
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→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 RS485 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 RS485 bus to a signal line (relative to ground). In practice you can get away with other solutions.
Properly terminating the RS485 bus can do a lot to improve signal quality.
RS232
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.
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, 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Ω resistor in series with the probe.