What Modbus Doesn’t Do Very Well

I’ve always been a fan of Modbus. It’s simple. I like to think that it has the simplicity of an ice cream cone. I’m a guy that doesn’t want any sprinkles. No whip cream. No chocolate syrup and definitely no waffle cone. I like it as God intended. Chocolate or vanilla in a regular old wafer cone.

Modbus is like that. Simple and without pretensions. It’s that simplicity that has made it ageless. That’s a big reason why it’s still being used 50 years after its introduction.

But like anything, it does have its limitations. It does have its flaws:

1. One of the biggest problems is that it only supports integer and binary data. If you have a temperature in a Modbus holding register, there is no way to know if the value of 25 means 25 degrees Centigrade, 25 degrees Fahrenheit or 25% of the full-scale temperature range of the meter. Unfortunately, that’s not uncommon. EtherNet/IP, PROFINET IO, DeviceNet, and PROFIBUS suffer from the same malady. OPC UA is one of the only communication mechanisms that has a way to fix it. With OPC UA, metadata identifying the data can be attached to every data point. Note that it doesn’t mean that the producer of the data has to use metadata; it’s just there if they want to give you more data than an integer value of 25.
2. Modbus uses master–slave communications. A slave only reports data when replying to a message from its master node. Events, alarms, and data changes can’t be reported until the master asks for them. And the problem gets worse, the more nodes there are in the network. It’s somewhat better with Modbus TCP, but even a Modbus TCP server node can’t report by exception. Again, that’s not unusual. Many of the other industrial communication protocols work the same way.
3. When Modbus was designed in the late 1970s, PLCs supported just a few simple data types, and Modbus followed suit. Over these last 50 years, the number of industrial data types has exploded, and some Modbus vendors have “shoehorned” all sorts of types (floating point, fixed decimal, double integer, and others) into Modbus, but all those homemade type representations are proprietary: the master has to be customized to know that four Modbus registers are really a floating point value.
4. Modbus RTU limits the number of devices on a network to 247 devices. Actually, this isn’t a limit, just the upper bound. In practice, it would be foolish to have more than twenty Modbus devices on an RS-485 network. The response times from the kinds of devices you put on a network are pretty long, so a master, in practice, would only service a slave on one of these big networks in 4–5 seconds or more.
5. And finally, security. Modbus RTU protocol is actually very secure. There is only one master and no way for an outside attacker to gain access to the network without taking the master offline. It’s the reverse for Modbus TCP, one of the most insecure networks around. Modbus TCP supports multiple masters, so an attacker that can get on the network can easily pretend to be a new Master and access any data in any device on the network.

I’ve said for a long time that Modbus is going to live forever. Even with these limitations, I still love it like my double chocolate on a regular old wafer cone.