Versions Compared

Version Old Version 9 New Version 10
Changes made by

Sylvain Ménard

Sylvain Ménard

Saved on

Key

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

...

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

...

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.

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

...

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