Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. 

...

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

  • Modbus ID: ID of the Modbus slave. In RTU mode, many slaves can be connected on the same physical serial link. Because of that, each Modbus slave must be configured with a unique identification number.

    • 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

    ratio

    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 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 Dashboards 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.

    ...

    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.

    ...

    • Modbus ASCII is not supported.

    • A BlueStorm RS-485 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.