Page Content

1 Description
2 Supported Features
3 Configuration
- 3.1 General configuration
- 3.2 Slave(s) Configuration
- 3.3 Coils
- 3.4 Discrete Inputs
- 3.5 Holding Registers
- 3.6 Input Registers
4 Connections
5 Limitations

Description

The Modbus Slave driver allows the simulator to communicate with one or multiple pieces of equipment configured with a Modbus master interface. The simulator can instantiate multiple slaves to which masters can connect and send read/write commands.

The Modbus Slave interface can operate over TCP/IP using an Ethernet physical link or over RTU using a serial link. The user must select the communication protocol matching the network configuration.

Standard coils, discrete inputs, and registers with UINT16, INT16, UINT32, INT32 and FLOAT32 operations are supported. See additional details in the Configuration and Connections sections below.

Supported Features

The following is a list of the features supported by the driver:

Standard registers:
- Coils: Available as a model output, a model input (controlled by the master) or both
- Discrete inputs: Available as a model output
- Input registers: Available as a model output. The supported data types are UINT16, INT16, UINT32, INT32 and FLOAT32
- Holding registers: Available as a model output, a model input (controlled by the master) or both. The supported data types are UINT16, INT16, UINT32, INT32 and FLOAT32
Supports TCP and RTU modes
Allows multiple-slave instantiation
- Configurable TCP port when operating over TCP mode
- Configurable serial port parameters when operating over RTU mode
Supports reconnection with the master device(s) if a connection is lost
TCP mode supports connecting multiple masters to the same slave
TCP mode supports having multiple slaves with the same IP address and TCP port combination; in this scenario, the slave ID is used as the differentiator

Configuration

The driver is entirely configurable via the RT-LAB interface. Users can add, delete, and duplicate Modbus slave devices. Configuring holding registers, input registers, discrete input or coils is also an easy task.

General configuration

The first parameters to be configured are found below:

Use an RT core for asynchronous computation

If set to true, the driver reserves a real-time CPU core for its communication system and is able to handle a bigger amount of data.

If set to false, the communication system defaults to core 0.

Verbose

If enabled, additional information is displayed during the loading of the model.

Slave(s) Configuration

By default, the driver is configured with one TCP slave configured to listen on the internal loopback network on port 1504 and one RTU slave configured on /dev/ttyS0 serial port.
Adding another Modbus slave is easily doable through the RT-LAB GUI.

The following shows a slave configured with TCP/IP.

Each slave device has multiple parameters:

Mode	Select "TCP" or "RTU" depending on how the Modbus slave device is configured to communicate.
Slave ID	ID of the Modbus slave. Each slave must be configured with a unique identification number. This is due to the fact that: In TCP mode, many slaves can use the same IP address and TCP port combination. In RTU mode, many slaves can be connected on the same physical serial link.
TCP specific parameters	NIC name: The desired network interface name. The proper interface name should be selected based on the information given by the Linux command "ifconfig". If a Modbus master is running on the same machine as the Modbus slave, the loopback network interface must be used ('lo'). If the driver is running on Windows this field will be ignored. IP address: The IP address of the Modbus slave. If a Modbus master is running on the same machine as the Modbus slave, the loopback IP address must be used (127.0.0.1). TCP port: Select the TCP port on which the slave will wait for a connection.
RTU specific parameters	Serial port: Path to the serial interface to be used. The default serial interface name of the first port on a SuperMicro motherboard is "/dev/ttyS0". Serial baud rate: Speed at which Modbus RTU slave is configured to communicate. Serial data bits: Number of data bits the Modbus RTU slave is configured to communicate. Serial stop bits: Number of stop bits the Modbus RTU slave is configured to communicate. Serial parity: Parity at which the Modbus RTU slave is configured to communicate.
Cycle output rate (ms)	Defines the rate (in milliseconds) at which the data from the model is written in the slave's outputs (coils and holding registers). When the slave's outputs are controlled from the model and from the master, this parameter must be set to a value greater than the time step of the model. Otherwise, the write operations made by the master will never be reflected in the model.
Byte Order	Defines how 32 bits data is encoded. Any of the byte ordering cases are possible (ABCD, BADC, CDAB, DCBA). ABCD refers to the network byte order.
Permit read/write requests with address gaps	From the lowest address to the highest address configured, this option creates dynamically new coils, discrete inputs, holding registers and input registers at every address that is not defined by the user and assigns a value of 0.

For each slave instance, the inputs and outputs must be configured. The slave will reply to the master's requests continuously as fast as possible.

The four next sub-sections describe the available data mapping options for the Modbus Slave driver.

Coils

The coil configuration is shown in the image below.

The four modifiable fields are:

Name	A specific name to recognize the coil.
Address	The address at which the slave holds that coil.
Initial value	If the coil is only controlled by the master, it will take this value (as a binary number) at the beginning of the simulation. Otherwise, the initial value will come from the model.
Control from	Three options are available. Master: The coil is a model input and can only be changed by a Modbus master. Model: The coil is a model output and can only be changed by the model. A Modbus master can read this coil and if it writes a value to it, it is overwritten automatically by the model. Both: The coil is directly connected to the model input and a from model data point is instantiated. This one will overwrite the coil value at the interval specified by the cycle output rate (ms) parameter

Discrete Inputs

The discrete inputs configuration is shown in the image below.

The two modifiable fields are:

Name	A specific name to recognize the discrete input.
Address	The address at which the slave holds that discrete input.

Holding Registers

The holding registers configuration is shown in the image below.

The five modifiable fields are:

Name	A specific name to recognize the holding register.
Address	The address at which the slave holds that holding register.
Initial value	If the holding register is only controlled by the master, it will take this value at the beginning of the simulation. Otherwise, the initial value will come from the model.
Control from	Three options are available and they work the same way with the holding registers as with the coils. Master: The holding register is a model input and can only be changed by a Modbus master. Model: The holding register is a model output and can only be changed by the model. A Modbus master can read this holding register and if it writes a value to it, it will be overwritten automatically by the model. Both The holding register is directly connected to the model input and a from model data point is instantiated. This one will overwrite the holding register value at the interval specified by the cycle output rate (ms) parameter.
Register type	Multiple options are available. UINT16: This is the standard format of Modbus slave holding registers. INT16: This is a non standard format of Modbus slave holding registers. The support for this type is added to improve usability. UINT32: This is a non standard format of Modbus slave holding registers. The support for this type is added to improve usability. The driver supports multiple byte orderings as described above in the slave configuration. A UINT32 holding register will take two UINT16 registers. This means that there should be an offset of 2 after each UINT32 holding register, otherwise the driver initialization will fail. INT32: This is a non standard format of Modbus slave holding registers. The support for this type is added to improve usability. The driver supports multiple byte orderings as described above in the slave configuration. An INT32 holding register will take two UINT16 registers. This means that there should be an offset of 2 after each INT32 holding register, otherwise the driver initialization will fail. FLOAT32: This type is based on the single-precision floating-point IEEE 754 standard (32 bits). The driver supports multiple byte orderings as described above in the slave configuration. A FLOAT32 holding register will take two UINT16 registers. This means that there should be an offset of 2 after each FLOAT32 holding register, otherwise the driver initialization will fail.

Input Registers

The input registers configuration is shown in the image below.

The three modifiable fields are:

Name

A specific name to recognize the input register.

Address

The address at which the slave holds that input register.

Register type

Multiple options are available. These are the same options available as for the holding registers.

UINT16: This is the standard format of Modbus slave input registers.
INT16: This is a non standard format of Modbus slave input registers. The support for this type is added to improve usability.
UINT32: This is a non standard format of Modbus slave input registers. The support for this type is added to improve usability. The driver supports multiple byte orderings as described above in the slave configuration. A UINT32 input register will take two UINT16 registers. This means that there should be an offset of 2 after each UINT32 input register, otherwise the driver initialization will fail.
INT32: This is a non standard format of Modbus slave input registers. The support for this type is added to improve usability. The driver supports multiple byte orderings as described above in the slave configuration. An INT32 input register will take two UINT16 registers. This means that there should be an offset of 2 after each INT32 input register, otherwise the driver initialization will fail.
FLOAT32: This type is based on the single-precision floating-point IEEE 754 standard. The driver supports multiple byte orderings as described above in the slave configuration. A FLOAT32 input register will take two UINT16 registers. This means that there should be an offset of 2 after each FLOAT32 input register, otherwise the driver initialization will fail.

Connections

Once the driver has been configured as desired and associated with the proper model subsystem, the user will have to connect points in the model to points in the driver by using the designated RT-LAB GUI. This connection panel will show all the driver's and model's connectable points, once the model has been compiled. It is also possible to make connections to LabVIEW panels.
The example model provided with RT-LAB is already packaged with connections between the driver and the model. It can be used as an example to understand how the connections between the model and the driver should be done.

The connection points are classified in the following categories:

Coils
Discrete Inputs
Holding Registers
Input Registers

Under each category, the configured operations will show up with the names that have been given by the user in the driver configuration GUI. If the icon is blue, it is a slave output that can be written by a Modbus master and this signal is returned to the simulation at the beginning of each time step. It means that this signal needs to be connected to an OpInput block of the Simulink model.

If the icon is red, it is a model output. It means that this signal needs to be connected to an OpOutput block of the Simulink model.

Take note that if a slave output is configured to be controlled from Both, there will be two connection points instantiated. One will be from Master (blue icon) and the other one will be from Model (red icon). The data point from Master is always directly mapped to the real slave outputs (holding register or coil) and this output will be overwritten by the from Model data point at a time interval determined by the Cycle output ratio (ms).

In TCP mode, an additional "Connected" connection point is available and can be used in the model to indicate if the Modbus slave is connected to a Modbus master or not. It represents the number of Modbus masters currently connected to the Modbus slave. This value will be the same for all slaves sharing an IP address and TCP port combination.
In RTU mode, an additional "Bus Activity" connection point is available and can be used in the model to indicate if the Modbus slave is receiving requests from a Modbus master.

Limitations

The following is a list of the limitations of the driver:

Modbus ASCII is not supported.
An OP3310 RS-232/422/485 PCIe serial card is needed in case it is required to communicate with multiple slaves on the same physical bus in RTU mode.