Modbus Turnaround Times

Human beings are lucky. We can operate full-duplex. That means we can listen and talk at the same time though most of us do way too much talking and not enough listening (me included). Case in point? This woman who sat next to me on a plane recently. She had the capacity to do full-duplex communication but there was such a fire hose stream of words coming from her mouth that processing her input precluded any sort of communication in the other direction. She wasn’t trying (able?) to speak and then listen (half-duplex) much less listen while speaking (full-duplex).

Let’s look at this “duplexing” stuff. Physical networks can be designed to be full-duplex, half-duplex or either. Serial RS232, for example, is a full-duplex, three wire network where each side has a Transmit line (TX), a Receive line (RX) and a common. Each receive line is connected to the transmit line of the other device—essentially the transmit line and receive lines are crossed between the devices. Since there are two separate physical transmit paths, bits can be streaming in both directions at the same time.

That was the default for a long time until someone decided that it would be nice to have a whole group of devices connected together. RS232 was modified so that messages could flow not only point-to-point but from any device to any other device and, this is important, over just two lines, not three. The common line was dropped.

Bits are transferred across a wire by energizing—either creating a potential between a pair of lines or not creating a potential between the lines. For example, a device that wants to send a “1” drives a voltage across the lines and that voltage can be sensed by other devices on the link. A device that wants to send a “0” doesn’t drive any voltage across the two lines. The absence of a voltage is sensed as a binary 0. Driving a potential across two lines is known as differential transmission. Inherent in this operation is that only one message can be moving at a time. This architecture, known as half-duplex communications, is the basis for RS485.

This leads to a number of interesting problems. First, devices have to be in one of two modes, sensing voltage or driving voltage. If you take a random device, what state should it be in? Well, all devices should start out in passive, sensing mode. The Master device will reconfigure its serial line drivers to drive voltages when it sends out a message. All the other devices, being in sensing mode, will receive that message. They’ll receive the message even though they aren’t the target for the message. This is one of the deficiencies of this architecture: every message has to be processed by every device even though it’s not the target of the message.

The one device that is the target of the message must send a response. Before it can do that, it must change its serial line drivers from sensing (receive) mode to driving (transmit) mode. That also has to happen in reverse in the Master device too. What often happens is that the device sending the response message starts transmitting the first bit of the response before the Master device can change its lines from sending to receiving. The Master misses the first bit or two of the message and the message response is unable to be decoded correctly.

That is the reason that Modbus and other half-duplex RS485 protocols specify a number of bit times—a delay—between the last bit of the outgoing message and the first bit of the response message. Many Modbus RTU failures are due to insufficient bit times or bit times equal to the time it takes to convert the data lines. In that later case, the Modbus RTU message will be received properly only some of the time causing the engineer troubleshooting the connection to pull their hair out.

Unfortunately, when people talk, we don’t have this inter-message delay. We often start speaking prior to the end of the current speaker’s sentence. Or, like the woman I met on the plane, we hijack the communication bus and never let it go. Full-duplex to half-duplex to no duplex!