How Hellpower turned supply crisis into opportunity
Hellpower were forced to think about different ways to implement their communication protocols without causing any undue delay for their customer or, the unthinkable, the project’s cancellation.
At its core, Modbus functions as a request-reply protocol. A single device (the master) initiates queries to which one of the connected devices (a slave) responds. This master-slave dynamic ensures smooth data transfer and network operations.
Data in Modbus is structured around registers. Each register holds a piece of data from a connected device, such as a sensor reading, and these registers can be read by or written to by the master device. The protocol supports multiple data types, including coils or discrete outputs, and holding registers, which can be read and written.
From its roots in factory settings, Modbus has expanded its reach over the decades. Today, it’s used in building automation systems, transportation infrastructure, energy management systems, and many other sectors. Its lasting resilience and adaptability underscore its reliability and the trust industries place in it for seamless communication between devices.
Two predominant Modbus iterations command widespread use: Modbus RTU and Modbus TCP. The former, Modbus RTU, frequently employed over serial lines (either RS-232 or RS-485), represents the classic version of the protocol. In contrast, Modbus TCP caters to Ethernet networks, promising enhanced speed and broader network adaptability. Notably, Modbus TCP typically uses port 502 for communication, making it an essential port to ensure open and secure when deploying Modbus over TCP/IP networks.
Interoperability is a hallmark of Modbus. Its open standard means that it can be used with a vast array of devices regardless of the manufacturer. This, coupled with its simplicity, has led to its extensive adoption in industrial applications.
The communication between devices in Modbus follows a well-defined message structure. Each message (or frame) is composed of different fields confirming the integrity and origin of the message. These fields typically include:
Address Field: This specifies which slave device the message is for (in case of Modbus RTU) or which Modbus application (in case of Modbus TCP).
Function Code: This dictates the type of action to be taken, be it reading, writing, or other diagnostic functions.
Data Field: This contains additional information or parameters needed for the function or any data being transferred.
Error Check (CRC or LRC): In Modbus RTU, a Cyclic Redundancy Check (CRC) or Longitudinal Redundancy Check (LRC) is used to detect any errors in the message.
