Support : Knowledge base

Knowledge Base

Welcome to OPAL-RT’s Knowledge Base

OPAL-RT offers a repository of support information for optimal use of its technology.

Loading…

Please note that OPAL-RT knowledge base is not fully optimized for mobile platforms.

For optimal experience, use a desktop computer.

Reference Number: AA-02091// Views: AA-02091// Created: 2022-09-09 15:21:25// Last Updated: 2022-09-30 19:39:53

HowTo

How to use Modbus with OPAL-Boards

Setting up the Modbus Driver

Our OPAL-Boards workflow provides a flexible and easy to use workflow which allows you to map any of your IO ports or communication protocols within your model. Basic knowledge of how to set up OPAL-Boards is recommended before using Modbus, so please take a moment to read through this article: How To use Opal-RT Boards

You will follow most of the steps outlined in the above article, but when you get to the section labeled "I/O Interface", choose Modbus Master or Slave instead of OPAL-RT Board.

Once you've added the Modbus device, the Configuration tab will look like this:

After you've built your model, a list of all of the OpInput and OpOutput boards in the model will appear in the OpInputs & OpOutputs section. Click and drag the OpInputs and OpOutputs to their corresponding Modbus components (coils, registers, etc.).

There are also Modbus example models available in RT-Lab. If you create a project in RT-Lab, you can find them under IO > _Generic_ > Modbus_Master OR Modbus_Slave.

Testing the Modbus Driver

In this section, we will test the Modbus driver in two ways: configuring the target to run as a Modbus slave, and configuring the target to run as both a Modbus master and Modbus slave.

Configuring the target as a Modbus Slave

We will use an application called qModMaster (you can download it from here) to receive Modbus messages from our target that is running the Modbus slave example program, but you can use any external Modbus master program you like. Once you have downloaded qModMaster (or an alternative Modbus master program), import the Modbus slave example model using the directions above. If you open the project and look in the I/O Interfaces and expand Modbus Slave, you will see two slave drivers listed: one for TCP, and one for RTU. We will focus only on the TCP one for this example.

Put the address of your target simulator as the IP address, choose a port, and make sure the NIC name matches your target's. In this example, the TCP port was changed to 502, but the default value will also work as long as the port number is the same in the qModMaster program. You can check what the NIC names of your target are by right clicking on your target, choosing Execute > Command, and then typing in "ifconfig" and pressing Enter:

Once you've entered in your target simulator's IP address and port information, build, load, and execute your model. You should see this information during the loading process in RT-Lab:

Open the qModMaster program, click on Options > Modbus TCP settings, and enter in your target simulator's IP address and port number:

Before we can connect qModMaster to the Modbus slave example running on the target, we need to change the base address setting. Go to Options > Settings and change the Base Addr to 0:

Once these settings have been configured, click OK and then click the Connect button:

A green dot should appear at the bottom left, showing that the connection with the simulated slave has been made properly.

We can now read data from the model using qModMaster. To read the coil at address 40, change Function Code to "Read Coils (0x01), enter in 40 for the Start Address, and make sure Number of Coils is set to 1:

If you click on the Read/Write button (to the right of the Connect button on the top toolbar in qModMaster), you should see a 1 appear. You can also read in data from other Modbus components such as the input register at address 33. Configure the Function Code to "Read Input Registers (0x04), the Start Address to 33, and the number of Registers to 1. If you press the Read/Write button, you should see 32767 appear:

Configuring the target to run as both a Modbus master and Modbus slave

In this example, we will run two models on the target at the same time: the Modbus master example, and the Modbus slave example. In order to run both of the models, you will need an RT-Lab license with more than 1 core enabled.

We will use the Modbus master example to send data to the slave. First, we must configure the target to run multiple models at once. Double click on the target, click on the Simulation Settings tab, then check the box next to "Enable multimodel support":

Next, add the Modbus master example model as a new project in RT-Lab (refer to the directions above). You should have both the Modbus master and slave example in the Project Explorer tab in RT-Lab. Build both models, then open the I/O Interface of the Modbus Master and enter in your target simulator's IP address and port number (we will use 502 once again as the port number, but the default will also work) under Slave_1:

Open the I/O Interface of the Modbus slave and make sure both the IP address and port number match the master's. The master and slave are now configured to communicate with each other. The last thing we need to take care of is assigning cores - by default, both the master and slave model will try to run on the next available core, so we need to manually assign either the master or the slave its own core through RT-Lab. Double-click on the Modbus slave model in the Project Explorer, click on the Assignment tab, then click on Advance. A button with three dots will appear in the Cores column:

Clicking on this button will bring up the core assignation menu. Set Total Number of Allocated Cores to 1 and choose and core after 2.

After you click OK, you will see the number of cores and the number assigned to the core itself in the Cores column:

We are now ready to run the models. Load and Execute both of them. The input registers scope in the SC console of the Modbus master should match the input registers addresses 30 through 33 in the SC console of the Modbus slave:

If you change the values of the input registers in the Modbus slave example, you should see them reflected in the scopes of the Modbus master as well.