This guide focuses on using the rexhip library, not on general Modbus theory. Topics such as Modicon addressing details, data length inference, byte/word ordering, concurrency limits, and protocol-level RTU vs TCP differences are intentionally omitted where they are handled internally by the library or are covered in standard Modbus documentation.

The “mb_query” Function Block

Concept

The mb_query FB defines a Modbus request that gets sent by a Modbus master FB. Each defined query gets passed into the master block, where it is automatically handled one at a time. Queries can be defined independent of Station Blocks (SBs), but are often defined within SBs because of their improved diagnostic and troubleshooting features. We will cover this more in-depth later.

mb_query FB Input Parameters

The following parameters are passed into mb_query to define a query:

mb_addr: Modbus device address (slave address/unit identifier)

mode: This is the Modbus function code. The following are pre-defined tags in mb_query for the supported function codes:

Table 1: mb_query Modes

data_addr: This is the starting address of the desired data within the Modbus data area. The rexhip library uses zero-based addressing.

Note: Some Modbus devices display registers as one-based, so if values are off by one register, this is probably why.

data_addr does not refer to values such as 40001, which are often found on datasheets.

Table 2: data_addr Examples

dara_ptr: This is an Input/Output where the data that will be sent or received is stored. It can be any data type, including arrays and UDTs.

data_len: This is the length of the data in the query – the number of either bits or 16-bit registers for coils/holding registers, respectively, that will be read/written, starting at data_addr.

This is an optional, generally discouraged parameter to specify; it will be automatically calculated from the length of data_ptr by default.

If you want to override the automatic calculation, assign data_len to the desired length, and then set it back to automatic after the mb_query function call using #mb_query.data_len :=  #mb_query.c.auto_len

Modicon Addressing Convention

The rexhip library supports the Modicon convention for data addressing with the following static tags in mb_query to be used when declaring the mode of the query:

Table 3: Modicon Convention Modes

When using one of the above modes, data_addr declarations take the form found on datasheets (e.g., 40005).

Examples of mb_query Calls

The following is an example of mb_query function calls modified from one of the station blocks included in the rexhip library. In this scenario, three queries are being configured, two of which read input registers and one of which reads holding registers. 

The following example shows an mb_query function call used to configure a request that writes multiple values to Modbus holding registers. The values are consolidated into an array, which is then passed to mb_query as a single data_ptr. The first array value will be written to the register at data_addr, the second value will be written to the register at data_addr + 1, and so on.

The “mb_query_bits” Function Block

The mb_query FB is designed to process data in bytes, so any queried booleans must total to whole bytes. If the number of queried bits does not equal complete bytes, either query a Boolean array with a length divisible by 8 (leaving unused bits as needed) or use the mb_query_bits FB instead.

Station Blocks

Concept

SBs group queries together, so the master block treats them as belonging to the same Modbus device. Device-level execution context is helpful for both tracking device communication and handling query timeouts.

If a device encounters communication errors, queries inside the SB can be skipped together with occasional retries, while other devices keep running.

This prevents one problematic device from interfering with the entire bus. Also, it is easy to set up multiple devices of the same type by creating multiple instances of the SB.

Implementation

SBs contain an SB header and footer, which are functions included in the rexhip library. The header marks the start of the SB, and all mb_query calls that follow it are tagged as belonging to that device. The footer closes the station context. Both the header and the footer take an mb_query instance and a tag of type mb_station_block_udt as arguments.

As previously mentioned, there are many pre-configured SBs in the rexhip library, as well as the header and footer functions that allow the creation of custom SBs.

The Station Block UDT

The tag of type mb_station_block_udt in an SB provides useful information and configuration options for a device’s queries and is one of the primary reasons to use SBs.

Configuration (conf):

• skip_code: Both the station block header and footer immediately return, preventing all query scheduling, execution, and result handling for that station.
• disable: Soft stop for the SB handled by the footer, allowing the station to complete its normal end-of-cycle logic before it stops participating further.

Table 4: skip_code vs disable functionality

• read_only: Only allows read queries to be executed.
• max_comm_error: The number of consecutive communications faults that must occur before a communication error is thrown.
• exec_x_quries: The number of queries in the SB to be executed in each loop.

The “out” struct provides information about the station’s current operational status rather than historical data.

• error: General error flag which stays true until all queries in the SB complete successfully in one cycle.
• error_comm: True if consecutive communication errors exceed max_comm_error.
• finish: True for one scan when the SB passes execution to the next device.

The “log” struct provides historical, cumulative data about query execution and error conditions for diagnostics and analysis.

• connected_time: Timestamp of when a device last regained communication.
• disconnected_time: Timestamp of when a device last lost communication.
• done_cnt: The number of successful queries.
• error_comm_cnt: The number of communication errors.
• error_exception_cnt: The number of non-communication-related errors.
• error_status: The error status code of the most recent failed query.
• error_data_addr: The data address associated with the most recent failed query.

The “z” struct is used for the internal workings of the rexhip functions and is not intended for logic, diagnostics, or configuration.

Station Block Troubleshooting Tools

The mb_station_block_udt “log” struct allows engineers to quickly identify communication issues and respond appropriately. The following examples demonstrate how it could be used to troubleshoot faulty device communications. 

Table 5: Example “log” Struct Use Cases

Modbus RTU Setup

The Modbus Master Block

The rexhip library includes two RTU master function blocks, mb_master_1200_ctrl and mb_master_1500_ctrl, for Siemens 1200 and 1500 PLCs, respectively. This guide will use a 1200-series PLC as an example. The 1500-series master block includes an additional operating_mode input that is mapped to the operating mode of the underlying comm_load instruction.

The master control block takes inputs for the hardware ID and baud rate, and an input/output of type mb_query. In the instance data of the master block, the static struct “conf” contains the parity, retries, timeout gain, and timeout offset parameters.

Timeout

The timeout is automatically calculated as follows:

Timeout = (total bits transmitted ÷ baud rate ) x timeout gain + timeout offset

The result is clamped to 5 ms ≤ result ≤ 65 s.

This calculation scales the timeout based on the amount of information being transmitted. Setting gain = 0 disables auto-calculation and uses the offset as a fixed timeout.

Integrating Queries with the Master Block

Below is an example of one way to load queries into a Modbus master block using station blocks.

This example will use the fbModbus function block shown above, and its instance memory data block “instance_fbModbus.” It will also use two pre-configured station blocks from the rexhip library–AUMA Valve and ABB AquaMaster 3 flowmeter.

OB1 (Main) will call fbModbus, which holds the Modbus master block, and fbDevices, which holds the station blocks.

This example system will have three valves and two flowmeters, so three valve station blocks and two flowmeter station blocks are called in fbDevices. Each one is given a unique Modbus address, and mb_query is set to “instance_fbModbus.mb_query” for all five devices.

The Path of the Query

1. The query starts in an SB where it is configured, and is then passed out of the SB.
2. It is then passed to fbModbus’s instance data block via fbDevices.
3. It then gets loaded into the Modbus master block.

Each query loaded into the master block is automatically placed in a queue and handled one at a time by the master block.

Modbus TCP Client Setup

The rexhip library provides a wrapper for the Modbus TCP client function native to TIA Portal, mb_tcp_ctrl (which may be called mb_client_ctrl depending on the library version). The library does not provide a wrapper for the Modbus TCP server function, so if configuring a server, use the native TIA Portal function MB_SERVER.

The mb_tcp_ctrl block takes inputs for the hardware interface, connection ID (should match the server connection ID), server IP address, TCP port, timeout, and an input/output of mb_query. Below is an example of an mb_tcp_ctrl block call.

Queries are loaded into the TCP control block in the exact same way as the RTU control blocks, and query statuses can similarly be monitored in the instance memory of SBs.

Conclusion

The rexhip Modbus library provides a structured, consistent way to set up and manage Modbus RTU and TCP communications in TIA Portal. Using standard function blocks and station blocks simplifies configuration, improves readability, and makes troubleshooting easier across a wide range of devices. This approach helps engineers spend less time dealing with protocol details and more time building reliable, maintainable automation systems.

The post Getting Started with the Siemens Modbus Extended Library for TIA Portal appeared first on DMC, Inc..

In this blog, we will take a deeper dive into setting up a project that includes a Siemens G Series VFD. We will begin by adding the device to the project. We will then set up the data blocks to include the proper user-defined types (UDTs), configure the function block call, and configure HMI faceplates for manual control and to display status. This example uses a 1516-3 PLC, TP600 Comfort HMI, and a G120 CU240E. Whether you are using the same hardware or something similar, the same concepts will apply.

Note that although this block is compatible with a 1200 PLC, some functionality such as PLC ramping and power/current monitoring is only available on a 1500 PLC. Also, many of the concepts detailed in this blog are applicable to other blocks in the Open Library.

Step 0

Create your project and add the PLC, HMI, and VFD to the hardware config. Network them together with PN/IE_1 in the Network View.

Step 1

Set up the VFD with the commissioning wizard. Each application has different parameters, so set up your VFD to fit the particular system that it will be used in, unless specifically detailed here.
Setpoint Specification: The drive must be used to control the ramp-up and down control of the motor. Select the ‘Ramp-function inside the drive’ option.

The function block we will be using requires Standard Telegram 1 for PLC-VFD communication. You may also set up the VFD’s local IO for hardwire control in this step. This blog explains the details of hardware control.

Once the drive has been set up with its proper motor parameters and the commissioning wizard is complete, note the hardware ID for the drive. This ID can be found in the system constants in the properties of the drive.

Step 2

Add the udtError_VFD and udtHMI_VFD_Control data types to your data blocks. Per the open library standards, these are typically split into DBs specifically for HMI, and DBs specifically for errors.

Step 3

Now we need to call the function block that is used to control. In our example, the VFD is used to control a pump in the water subsystem. The OB1 calls fbMain which contains all of the calls for the individual subsystem, fbWaterSystem for example. fbWaterSystem then calls fbVFD_GSeries and controls the pump from there.

Lets quickly look that the important details of the interface here:

Step 4

Now to link to the HMI. First, link an HMI tag to the udtHMI_VFD_Control that was created in Step 2 and used in Step 3.

Add the appropriate faceplate to your screen and link the HMI tag.

Then add a popup faceplate to a new popup screen. Link the HMI tag.

Use a transparent button over the pump faceplate in order to show the pop-up. Link it to the ‘ShowPopupScreen’ event with the display mode set to ‘On.’

Also note there is an event attached to the close button in the popup faceplate, see above picture. Also, use the ‘ShowPopupScreen’ event with the display mode set to ‘Off’ as that button is used to close the popup screen.

And congratulations, your G-Series motor is now ready for action!

Learn more about DMC’s partnership with Siemens and our Siemens PLC Programming Services. Contact us for more information.

The post Dissecting the Siemens Open Library: A Deeper Dive into fbVFD_GSeries appeared first on DMC, Inc..

Update Highlights

• Siemens TIA Portal V15 
• Simulation mode for all devices
• V15.1 version will be coming out in the next few months

Siemens Open Library Overview

A free, open source library, the Siemens Open Library was developed by DMC in partnership with Siemens Industry as a resource for consistency, usability, and faster development for the ever-growing Siemens community. With over 1000 hours of time invested, this library is already being put to use in many different types of projects across multiple platforms.

Siemens Open Library sample project

Stay Up To Date

Join our Siemens Open Library group on LinkedIn and stay up to date on all the latest improvements or sign up here to receive an email notification each time the library is updated.

You can submit custom objects to DMC by emailing them to Contribute@OpenPLCLibrary.com.

Are you attending the 2019 Siemens Automation Summit? Stop by any of our presentations and say hello!

The post Siemens Open Library Version 4.0 Release appeared first on DMC, Inc..