Modbus today, is it still a choice?

When evaluating the adoption of a data transfer technology, we almost always focus on finding the "fastest" system, perhaps in real time.

We often forget the engineering approach and the global analysis that involves factors such as TCO (Total Cost of Ownership) which, unfortunately, today also includes the availability of hardware on the shelves of our suppliers.

We should go back twenty-five years, when cutting-edge hardware was very expensive and the use of certain technologies occurred only after a careful evaluation of real needs. With the evolution of microelectronic technologies, the prices of consumer and industrial hardware have collapsed over time, we have forgotten "good practices" and we have started to always select the best hardware available and, even worse, we have no longer trained new designers on the optimization path.

Today, with the reduction of time to market and the need to contain costs, we need to reshape our projects so that they are competitive.

So the question is: can a protocol like Modbus, born in the 70s, have an appeal today for our industrial automation applications?

The answer is yes, but obviously after a careful analysis of the application context.

Modbus is a protocol created in 1979 in Modicon to communicate with their PLCs but thanks to its simple and generic architecture it is perfectly suited to the transfer of data of any type between partners.

Similar to the English language, which today we are all called to know regardless of our nationality, Modbus is present as a native protocol in almost all devices on the market. Where it is not native, being a simple protocol, it is still easy to implement it with very efficient system libraries.

I will not go into the details of the protocol, the specifications are freely downloadable from the organization's website, I prefer to comment on some strategic aspects.

Architecture

Modbus exists in two variants, the first RTU (or ASCII) based on RS232/485. Given the technology, it is the older variant, however it is still quite widespread in panel equipment, such as energy meters or low-cost actuators, where interactions are spaced out in time and therefore speed is not a determining factor. It is also present in many motor drives, even new ones.

All devices receive the request frame at the same time, only the unit whose ID is equal to the Address field of the query will respond.

The second, Modbus/TCP, which, as the name suggests, is based on Ethernet TCP/IP. In this variant the PDU (Protocol Data Unit) is encapsulated in a TCP packet. This variant, in addition to having a higher intrinsic speed thanks to the technology of the transmission medium, is much more efficient than the previous one, being able to overcome, as we will see, some of the limitations of Half-Duplex.

The PDU of both variants consists of a function number and the data associated with it, the functions are not orthogonal, that is, there are functions in reading and others in writing.

Modbus is an Half-Duplex Master/Slave protocol. In an Half-Duplex conversation, at any time, the transmission bus is busy either with the request of the Master (controller) or with the response of the Slave (device), the Master/Slave mode also provides that the devices are polled sequentially one at a time.

These “rules” are mandatory for Modbus RTU, where the means of transport, over time, is exclusive, i.e. not shareable. However, there is a “Broadcast” mode that requires a Query (request from the Master) with a destination address equal to zero, to be received by all slaves, but this is more of an emergency/configuration mode, often difficult to manage with devices from different vendors.

With Modbus/TCP things change, the Master/Slave architecture becomes Client/Server. In this mode it is possible, in a multi-threaded environment, to have multiple Clients operating in parallel, each with “its own” device, the addressing is in fact at the encapsulation protocol level (the IP/Port Tuple that we remember is unique). Furthermore, the most advanced Devices, being intrinsically TCP servers, allow multiple incoming connections and allow to respond to requests from different Clients.

In this way, while maintaining the Half-Duplex transaction, the overall scanning time of the entire periphery is significantly reduced.

Applications

Subject to a thorough analysis of processing times and latency, the rule of thumb for choosing a communication bus follows the intelligence of the devices to be managed.

In essence, each independent device needs software to manage it. If the device is simple, this software will reside in the control CPU and we will need a very intense data exchange with the device for proper timing management.

On the contrary, an intelligent device is equipped with a complex CPU that contains the control software and the control controller generally limits itself to asynchronously parameterizing the cycles, sending Start/Stop and acquiring the results, if any.

In this case, we will not need real-time deterministic communication, since the system latency is negligible compared to the device cycle. It is therefore possible to use an asynchronous protocol such as Modbus.

Let's see some examples.

A non-intelligent drive managed for example with technological objects in the Siemens world involves the use of Profinet IRT, which is a real-time and low-latency synchronous protocol, the only possible one to guarantee the correct management of the regulation loops.

With a digital I/O peripheral, we expect that at the beginning of each Main Program cycle, the physical state of the peripheral has been copied into the virtual I/O variables. The communication processor takes care of this and the transactions must be synchronous to the program scan or at least fast enough to guarantee the correct transfer. Even in this case, the use of a deterministic fieldbus is often necessary.

An intelligent leak test unit typically involves creating test programs with parameters such as fill time, stabilization time, etc. parameters that are set on the main panel of the unit or, if they were transmitted externally, this would be done asynchronously only once.

During the machine cycle, it is usually sufficient to select the program, send a start command and sample the end of test signal with any detected values.

In this case, the use of a fieldbus is not strictly necessary and communication could be via Modbus protocol.

Electric screwdrivers work very similarly: programs and program parameters. Cycle start, cycle end, and torque/angle measurement. And unless you want to implement specific logic related to reading torque or angle in real time, Modbus is also a great solution.

In conclusion:

Pros

The specifications are public and freely downloadable from the organization's website. There are no royalties required for its use.

It is a simple protocol, both to understand and to implement but above all to debug.

It does not require special hardware, such as frontend coprocessors, both in the serial and Ethernet variants, which can be implemented on practically any system that contains a TCP/IP stack.

In the RTU variant it is probably the most widespread serial protocol. Where by protocol I mean a semantically organized way to exchange information.

Cons

In serial transmission (RTU) the method for determining the perimeter of the telegram is not very efficient. In current implementations, RS232/485 hardware and drivers, especially in "complex" systems with operating system, do not always guarantee a constant bit flow over time, data is very often treated as an ethernet flow and is presented when available, in packets, so it is complex to determine inter-frame delays.

It would have been better to think, from the beginning, of a fixed mini-header containing the remaining length of the telegram, just like the TCP implementation does. But, to be honest, in the 70s, one could not think of the problems that USB/RS485 adapters or Linux kernel queues would have introduced.

There is no function for the “raw” transfer of data, everything is typed in bits or words. This is actually a problem that can be easily solved without resorting to custom functions, which require a double implementation in the firmware, both on the controller side and on the device side.

It is sufficient to establish some rules, that is, to consider the transfer of registers as a simple 16-bit aligned transfer, and delegate the conversion and interpretation of the data to the semantics of the application. The only limitation, in fact, is that the memory areas are aligned to the word.

The maximum latency of a transaction is not specified and therefore becomes a parameter of the vendor. This, in the approach phase, could be scary. However, let's not forget that it is not a limit of the protocol, but of the hardware used. In other words, it is sufficient to check, in the design phase, the latencies of the individual devices, a parameter that, since there is no limit "to be respected by specification", must be explicitly reported.

If you want to explore Modbus (RTU/ASC/TCP/UDP, master and slave) with an open source, cross-platform (Win/Linux/BSD), 32/64-bit suite (libraries and tools), check out SnapModbus and this article.