...
You can find more information about this protocol by following this link. The feature allows KNOT to act as a TCP bridge and read data from Modbus-supported devices connected to a 2-pin terminal block on the board. Modbus clients (slaves) can access the data from the Modbus server (master - KNOT) using the 502/TCP port.
The Modbus-supported device should be connected to the RS485 port. A two-wire connection (A+/B-) is supported by the device (a 2-pin terminal block).
It is important to note that both pins should not be mixed up. Inverting the "A" and "B" connections (incorrect polarisation) will result in communication failure.
Another thing to keep in mind is the Modbus cable distance. If the cable length is less than 50 meters - there should be no issues. If 50+ meters cable is used, 120 Ohm termination resistance should be installed at the end of the cable.
The KNOT supports:
- Modbus TCP server scenario, which allows you to use 3d-party Modbus clients to send function code commands to the KNOT's IP address using Modbus TCP/IP connection (TCP port 502). You can use any Modbus Client software (there are plenty on the internet) or it can be easily written/configured in Python. In this case, the KNOT "translates/bridges" Modbus TCP/IP requests to Modbus RTU.
- Modbus RTU controller scenario (available only starting with 7.10beta5), which allows you to send function code commands directly from the RouterOS command line via Modbus/RTU.
Modbus TCP packet structure
The query packet consists of Transaction ID, Protocol, Length, Unit ID, Function Code and Function Parameters fields and the maximum size is 260 bytes.
- Transaction ID - integer from 0 to 65535 used to identify the answer to the specific query;
- Protocol - 0x0000 stands for Modbus;
- Length - shows how many bytes will follow the Length field;
- Unit ID - usually called "Device address", 0x00-0xff. Each end-device in the specific system should have a unique ID;
- Function Code - describes which function will be called. Each device has multiple registers and these functions are used to interact with the registers. Codes are defined by the standards but the manufacturers can also implement their own functions with specific codes;
- Function Parameters/data - usually specifies register address, data length and data to be written in case the "write" function is used.
Default Unit ID, Function Codes and Parameters can be found in the datasheet for the specific product. Answer messages are structured similarly and should be described in the product-datasheet as well.
Configuration
Once the board is connected to the Modbus device, the only thing that needs to be altered/checked in the settings is the "Modbus" port configuration:
|
By default, a port with the name "modbus" is assigned to the Modbus service, but the service itself is disabled. In order to activate the "Modbus" service, you need to issue the command, as shown below:
|
Additionally, since the when you want to allow Modbus clients to communicate with the Modbus server using TCP(502)/IP protocol, you need to make sure that the IP address is configured accordingly and that this IP+502 TCP port is accessible from the outside (in case "slave" devices are connecting from the WAN side). You can find information on how to configure the firewall using the firewall manual.
Modbus clients
In order to send commands to the end-device, Modbus Client should be used. You can use any Modbus Client software (there are plenty on the internet) or it can be easily written/configured in Python. Run the software and make sure that TCP/IP (502 port) connection gets established.
Modbus TCP packet structure
The query packet consists of Transaction ID, Protocol, Length, Unit ID, Function Code and Function Parameters fields and the maximum size is 260 bytes.
- Transaction ID - integer from 0 to 65535 used to identify the answer to the specific query;
- Protocol - 0x0000 stands for Modbus;
- Length - shows how many bytes will follow the Length field;
- Unit ID - usually called "Device address", 0x00-0xff. Each end-device in the specific system should have a unique ID;
- Function Code - describes which function will be called. Each device has multiple registers and these functions are used to interact with the registers. Codes are defined by the standards but the manufacturers can also implement their own functions with specific codes;
- Function Parameters - usually specifies register address, data length and data to be written in case the "write" function is used.
Default Unit ID, Function Codes and Parameters can be found in the datasheet for the specific product. Answer messages are structured similarly and should be described in the product-datasheet as well.
Reading MODBUS data using RouterOS
...
Sending function code commands using RouterOS
| Info |
|---|
| Available only starting with 7.10beta5. |
Sub-menu: /iot modbus transceive
| Property | Description |
|---|---|
| address (integer:0..255; Default: ) | Specify device address or unit ID. |
function (integer:0..255; Default: ) | Specify the function code. For example:
|
| data (string, max length 504; Default: ) | Input data string that usually specifies register address and data to be sent. For example:
The data string is 4 bytes long. "0x2000" is the command to the register (2 bytes long) and "0x0001" (2 bytes long) is the device's address. See the Modbus device's specifications for the exact data string that needs to be sent. |
values (integer:0..4294967295; Default: ) | An alternative way to send the data (see data parameter above). In this case, each value specified represents 1 byte of the data payload/string. For example:
Equals to the output of data=20000001. 32(dec)=0x20(hex), 0(dec)=0x00(hex), 0(dec)=0x00(hex), 1(dec)=0x01(hex) → 0x20000001. |
An example of sending function code 3 command using the "transceive" feature:
| Code Block | ||
|---|---|---|
| ||
/iot modbus transceive address=1 function=3 data=20000001
address: 1
function: 3
data: 01030164
values: 100
time: apr/27/2023 14:05:15
status: ok |
From the output above, we can tell that Modbus connected device replied with a value "100" or data "01030164" (01→ address; 03→ function code; 01→ number of bytes; 64 (hex to dec=100)→ the reply).
Specifically for function code 3 (this will not work for any other function codes), you can use an additional option, like shown below:
| Code Block | ||
|---|---|---|
| ||
[admin@device] > {:local output [/iot modbus read-holding-registers slave-id=0x03 num-regs=0x1 reg-addr=0x0 as-value once];:put [($output->"values")]}
2349
[admin@device] > {:local output [/iot modbus read-holding-registers slave-id=0x03 num-regs=0x5 reg-addr=0x0 as-value once];:put [($output->"values")]}
2353;3;500;75;38 |
Parameters that can vary are "reg-addr" (address in the data string), "num-regs" (data string command to the register/number of registers), and "slave-id" (device address or unit ID). All of them depend on which values are supported by the MODBUS-connected device.
...