When NOT to Use Modbus

I’ve been writing about Modbus, Modbus RTU and Modbus TCP since I had hair, and that’s a very long time now. I’ve written about data representation, about the function code structure, about its history, certification, testing and so much more.

Today, I’m writing about when NOT to use Modbus, Modbus RTU or Modbus TCP. Yes, there are times when Modbus makes sense and times when it doesn’t. This is about when it doesn’t make any sense. Here’s my list.

1. Don’t use Modbus TCP if you want to go through a firewall. You could open a pinhole in the firewall and let an application talk to a device within your factory, but lighting your trousers on fire would have a similar result. Anyone on that side of the firewall would have access to not only that Modbus device but everything else on that network.
2. Don’t use Modbus RTU if you need fast data response. Yes, you can push the Modbus RTU baud rate to 56K baud, or maybe even 115K, but you’re still looking at a response time of 25 milliseconds or more for each device on the link. The baud rate is usually the least effective mechanism for generating faster response on a Modbus RTU link. The majority of delays between the transmission of a Modbus request and the reception of a response is the processing time with the Modbus slave node, not the time on the wire. And the more slave nodes, the longer the cycle time of the entire multi-dropped RTU network.
3. Don’t use Modbus if you need any event-oriented responses. Modbus doesn’t do events. A Modbus master (RTU) or a Modbus client (TCP) simply sends requests and get responses. These are not networks that can quickly respond to an alarm condition.
4. Don’t use Modus for sensitive data transfers. Modbus doesn’t support any kind of security. Anyone getting access to the network can read the data transmitted on the network.
5. Don’t use Modbus if you have a lot of data to transfer. The packets are limited to around 120 bytes maximum. Transferring 1K requires almost ten messages. It’s just not efficient for any kind of large data transfer. That recommendation doesn’t change for Modbus TCP. Even though Modbus TCP is contained with a TCP packet, you can only transfer the same 120 bytes in a Modbus message.
6. Don’t use Modbus to download new firmware (see #4).
7. Don’t use Modbus to represent any kind of complicated data model with any kind of interrelated data. If you have a pump with motor data, flow data, temperature data and I/O, it doesn’t make much sense to represent that pump in a Modbus register table. All you have is registers and coils and there is no way to group Pump #1 data and logically separate it from Pump #2 data.
8. Don’t use Modbus in control applications. Modbus is just an ok control protocol. Because Modbus RTU operates in a half-duplex mode (request out – response in, next node and repeat) the cycle time through all the nodes varies with the number of nodes. It should be used only in applications where timing and response times are not a consideration.
9. Don’t use Modbus RTU if you anticipate having a large number of nodes. Modbus RTU devices are wired in a daisy-chained fashion where each node connects to the two wires of the preceding node and the two wires of the successive node. A large number of Modbus RTU devices use screw terminals, which become loose over time. One loose screw terminal in a large network of devices means hours of troubleshooting.

Modbus is great for small control applications where a small amount of data needs to be transferred from Point A to Point B. It requires little code space and almost no RAM, so it is perfect for small embedded applications. Use it only where it’s going to be effective, given its limitations.