Modbus device emulation using IOT‐Tree message net flow [Modbus Slave nodes]
IOT-Tree message flow function is in the regularization of access to a variety of device data after the function block combination configuration support (intuitive and fast), through her you can in most occasions to quickly realize the processing of data - storage, conversion, sending and so on.
This example is rather specific, assuming that you have deployed an IOT-Tree device and the items inside have access to the field data in a canonical list of tags. At this point, you may have a special need where other devices in the field (e.g., PLCs or DTUs) want to access some special data in the IOT-Tree device for process control improvements.
At this point, you can simulate a Modbus RTU device for use by a relatively simple PLC or DTU in the field by running the RS485 interface or Ethernet interface provided by the IOT-Tree device.
The Modbus standard protocol is arguably the simplest protocol in the industrial world. Please refer to the technical documentation on the web for more information.
This section, too, will not be repeated in this article, so if you are not familiar with it, please refer to documents.
If you are already familiar with the Modbus protocol and IOT-Tree connector and data organization, you can configure the Modbus Slave protocol conversion (i.e., Modbus device simulation) in the corresponding project. In the following example, the data access and tags have already been configured. We will only specifically introduce the configuration process of Modbus Slave.
Double-click the Modbus Slave node you just added to bring up the configuration interface. You can make detailed configurations within it.
A Modbus Slave node represents a Modbus bus, on which one or multiple Modbus devices can be configured (with each device having a unique address). Therefore, in the configuration dialog popped up by the node, the upper part is the Devices area, where you can add multiple devices.
Please note: According to the Modbus protocol, each device address must be unique, and should be set within the range of 1-254
Click the "Add New Device" or "Edit Existing Device" button. A detailed configuration interface for a single device will pop up, as shown in the figure
Each device can be configured with multiple address segments as needed. For each address segment, you can select a function code (FC) specified by the Modbus protocol, which also defines the value type (bool switch value, int16 word data) of each data item within the address segment. Additionally, you can set the starting address and quantity of this address segment. As shown below:
After completion, click on a certain address segment (Segment) on the left, and you will see a table of all Modbus data items for that address segment on the right.
In the Modbus data item list, by clicking on the blank space corresponding to a specific row (representing a particular Modbus data) and the Bind Tag column, you can bring up the tag selection window for the current project. You can choose a specific tag, and upon confirmation, you can bind the project's real-time tag to this data item. During operation, the IOT-Tree will automatically refresh the real-time tag data to the Modbus address space.
By simply repeating the above steps, you can easily configure one or multiple Modbus devices and their internal data segments.
Next, you can configure how external devices access your Modbus Slave bus, as well as attach one or more devices to it. This is done by adding configurations in the Connector area.
When clicking the "Add" button, you can see the following options: Tcp Server, COM, and Tcp Client
This method involves the Modbus bus providing a Tcp Server listening port to the outside world. External devices or programs actively establish a Tcp connection by creating a Tcp Client, and then access the bus corresponding to our node in the role of a Master device over this Tcp connection
Please note: Although based on TCP connections, the packet format of the current protocol still belongs to Modbus RTU, rather than Modbus TCP packets
If the device running IOT-Tree has a serial port COM (RS232 or RS485), you can choose the corresponding serial port number to provide external access. An external device or program connects to this COM port (physical connection via RS232 cable or 485 twisted pair), and then accesses the bus corresponding to our node as a master device over this connection.
This approach is the reverse of TCP Server. Our node actively connects to a remote TCP Server. Once the connection is established, the remote program or device accesses the bus corresponding to our node as a Master device over this connection
This method can support on-site non-fixed IPs, actively connecting to servers with fixed IPs in the cloud. Then, the server program obtains the bus device data defined by this node in a master device mode through the Modbus RTU protocol.
To support the cloud's differentiation of current connections, a connection ID (Conn ID) can be set. When a new TCP connection is established, it will be sent immediately, and the server can determine the identity of the current connecting device through this ID.
After confirming all the above configurations, you can see that this Modbus Slave module node will automatically generate several associated nodes, and each device on the bus will have two corresponding nodes. You can view the operating status in the expanded window of these nodes, and also conduct more detailed debugging and control through the message flow.
After starting the project, the Modbus slave node will enter the running state. At this point, you can test this Modbus device through Modbus-related software.
