Monitoring Modbus over Half-Duplex Serial Links

Abstract

Half-duplex Modbus communications are not easy to parse due to the packet format specifics. Alas, the Modbus protocol doesn’t define any structural differences in headers of requests and replies – request and replies start with exactly the same sequence of bytes (which in case of a reply usually followed by extra data bytes). In full-duplex links, it doesn’t impose a problem – TX data always contains Master requests, RX – Slave replies. But in half-duplex everything is mixed into a single stream of bytes. Therefore, some heuristics is needed to split this single byte stream into two.

Details

First of all, be sure to set “Stream roles” to “Half-duplex (RX)” or “Half-duplex (TX)”, so that Modbus Analyzer knows that Modbus requests and Modbus replies are all contained in the single stream (RX or TX). Next, it’s time to set up the half-duplex decoder.

The Modbus Analyzer plugin supports two approaches for extracting Modbus requests and replies from half-duplex Modbus links (to switch between the two, use the “Half-duplex mode” setting):

1. Alternating Master/Slave (default);
2. RTS flow-control.

The first method is alternating between requests and replies. Packet #1 is a request, packet #2 is a reply, packet #3 is a request again, and so on.

For the second method, we get a hint from the RTS/CTS lines. This can only work if the link utilizes half-duplex RTS flow control (a node raises RTS before transmitting and drops it when finished). As you can imagine, this method is more reliable than the first, so if your link has RTS flow-control, be sure to use it in Modbus Analyzer, as well.

Otherwise, the default (alternating) heuristics is usually enough.

Fine-tuning The Alternating Method

An important parameter for the alternating method is “Half-duplex” timeout. If the Modbus Analyzer doesn’t receive a reply within the given timeout, it resets its internal state and expect another request once again. The value for this half-duplex timeout should be, on the one hand, greater than the average response time from a Slave device, on the other hand, it should be less than the actual retry timeout of the Modbus Master (or retries will be misinterpreted as replies). Basically, the lower it is, the less are the chances of parsing the next request as a reply; setting it too low will result in the opposite – a real reply can be parsed as the next request. The default timeout is 2000 milliseconds, but finding the “just right” value might require some trial-and-error in each particular case.