lamaPLC: Simatic and Modbus

Certainly, I am aware that numerous descriptions of Modbus can be found online and in technical literature. As the oldest and most widely used industrial communication method, it serves as the backbone of industrial connectivity. While newer, more sophisticated communication protocols have emerged, Modbus remains prevalent. In fact, you might even encounter it on the first intergalactic spacecraft.

Although this communication method is widespread and often underestimated, it can lead to unexpected issues during commissioning, usually more negatively than positively. With over 25 years of experience in automation programming, primarily with Simatic systems, I'm sharing my observations. While the following is somewhat subjective, I hope many readers will have an „aha” or facepalm moment, helping them resolve certain problems.

Modbus originated in 1979 and was created by Modicon (now part of Schneider Electric). During this period, industrial automation moved from relay-based systems to digital logic. As the pioneer of the first Programmable Logic Controller (PLC) a decade earlier, Modicon developed Modbus to facilitate communication among these controllers and with external devices via serial lines. The protocol features a straightforward query-response model, in which a “master” (client) initiates communication with one or more “slaves” (servers) to transfer data.

The protocol's emergence as a worldwide industry standard was fueled by several key factors:

• Open and Royalty-Free: Since its inception, Modicon has made the protocol available as an open standard, enabling any manufacturer to implement it without licensing costs.
• Technical Simplicity: Its minimal processing requirements and simple message format facilitated its adoption by hundreds of vendors for applications ranging from sensors to motor controllers.
• Adaptability: Initially designed for serial interfaces such as RS-232 and RS-485, the protocol has evolved to meet industry needs. In 1999, Modbus TCP was introduced, allowing the original protocol to operate over modern Ethernet and TCP/IP networks.

In 2004, Schneider Electric officially transferred the rights to the Modbus Organization, an independent nonprofit that continues to manage and promote it as a public domain standard. Today, it is often called the “grandfather of industrial networking” due to its continued widespread use in both legacy factories and modern IoT systems.

Industrial Automation & Manufacturing

• Control Systems: Connecting Programmable Logic Controllers (PLCs) with sensors, actuators, inverters, and motors to automate assembly lines.
• Data Acquisition: Using SCADA (Supervisory Control and Data Acquisition) systems to monitor real-time production data, such as oven temperatures, vibration levels, and pressure.
• Legacy Integration: Retrofitting older machines to communicate with modern control systems through Modbus-to-IoT gateways.

Smart Buildings & Facility Management

• HVAC Control: Managing heating, ventilation, and air conditioning systems based on occupancy and environmental conditions.
• BMS Integration: Centralizing data from lighting, security, and elevator systems for improved energy efficiency.
• Smart Metering: Connecting Modbus-enabled smart meters to monitor electricity, water, and gas usage across residential or commercial complexes.

Energy Management & Renewables

• Solar & Wind: Monitoring Photovoltaic (PV) inverters, trackers, and batteries to optimize energy generation and storage.
• Electric Vehicles (EV): Integrating charging infrastructure with building energy systems to manage load and prevent grid strain.
• Smart Grids: Enabling real-time communication between grid management systems and remote sensors at substations.

Water & Wastewater Management

• Process Monitoring: Automating chemical dosing units, monitoring pump station status (pressure, flow rate), and checking water quality (pH, conductivity).
• Infrastructure Safety: Detecting sudden pressure changes to identify pipeline leaks or bursts immediately.

In the Modbus protocol, the terms Client and Server specify the roles of devices during communication. These terms are the current, official replacements for the older “Master/Slave” terminology.

Modbus Client (formerly Master)

The Client is the active device that initiates all communication transactions. It's sending questions.

• Action: It sends a “Request” to a specific device to read or write data to it.
• Behavior: It should wait for a response or a timeout before issuing the next command.
• Typical Devices: SCADA systems, HMI panels, or a primary PLC.

Modbus Server (formerly Slave)

The server is a passive device that responds to requests from a client.

• Action: It waits for an incoming message, processes the request (for example, looks up a sensor value), and sends back a “Response”.
• Behavior: It never initiates a conversation; it only responds when spoken to.
• Typical Devices: Sensors such as temperature and humidity sensors, motor drives like VFDs, power meters, or I/O blocks.

The core difference is the transport layer: Modbus RTU is designed for a physical wire (Serial), while Modbus TCP is designed for a network (Ethernet). Before Ethernet's advent, only the RTU (Remote Terminal Unit) protocol was available, primarily using RS-232 and RS-485. The rise of Ethernet greatly expanded options, enabling communication over the faster, more versatile TCP/IP protocol. Today, these two methods serve as the Modbus transport layer.

Although quite different, they can sometimes be integrated, such as in multimaster (hybrid) RTU scenarios. In this scenario, a signal converter needs to be integrated into the TCP network. The converter has its own IP address to receive Modbus/TCP telegrams. It's crucial that the client is aware of the Modbus/RTU network behind the converter, which uses traditional RTU addressing. Often, clients cannot manage both RTU addressing and TCP simultaneously, so verifying the client's capability to do so is essential. The Siemens TIA Portal is suitable for this task, and I will offer an example of its use later.

The transmission options for Modbus/RTU depend on the physical layer, which can be either RS-232 or RS-485. RS-232 is quite uncommon because it only supports point-to-point connections, meaning one Client and one Server. In contrast, RS-485 is a more flexible option; its technical specifications are outlined in the table below.