Differences

This shows you the differences between two versions of the page.

--- en:sw:01-mervis:setting-modbus-server-hidden [2018/06/18 05:55]
martin_kudlacek [Setting a datapoints]
+++ en:sw:01-mervis:setting-modbus-server-hidden [2023/05/10 11:15] (current)
avsetula [Setting ModbusRTU server (slave)]
@@ Line 1: / Line 1: @@
 ====== Setting a Modbus server (slave) ======
-So far in other tutorials, we used a UniPi controller as a Modbus master device. That is the download / upload of data to Modbus slaves (UniPi extensions, energy meters,...) were initiated by the UniPi controller.  In this tutorial, we will demonstrate how to set UniPi as Modbus server, or in other terminology Modbus slave.
+<WRAP group>
+<WRAP half column 81%>
+So far in other tutorials, we used a Unipi controller as a Modbus master device. That is the download / upload of data to Modbus slaves (Unipi extensions, energy meters,...) were initiated by the Unipi controller.  In this tutorial, we will demonstrate how to set Unipi as Modbus server, or in other terminology Modbus slave.
+</WRAP>
+<WRAP half column 15%>
+;;#
+<html><span class="dev-tag dev-patron">Patron</span></html> \\
+<html><span class="dev-tag dev-neuron">Neuron</span></html> \\
+<html><span class="dev-tag dev-gate">Gate</span></html> \\
+<html><span class="dev-tag dev-unipi11">Unipi&nbsp1.1</span></html> \\
+<html><span class="dev-tag dev-axon">Axon</span></html>
+;;#
+</WRAP>
+</WRAP>
 ===== Physical layer =====
-As a first thing, we need to decide, what type of physical layer we will use. On UniPi running a Mervis, we can pick either from RS485 (ModbusRTU) or ethernet (ModbusTCP). The decision will be based on the rest of your existing infrastructure and the capabilities of devices, which will communicate with your UniPi.
+As a first thing, we need to decide, what type of physical layer we will use. On Unipi running a Mervis, we can pick either from RS485 (ModbusRTU) or ethernet (ModbusTCP). The decision will be based on the rest of your existing infrastructure and the capabilities of devices, which will communicate with your Unipi.
-The RS485 physical layer is typically limited by its speed (115200bps) and nature of the [[https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Half_duplex|half-duplex communication]], which limits the speed even further. On the other hand, the RS485 is easy to implement and still very popular in industrial automation.
+The RS485 physical layer is typically limited by its speed (115200 bps) and nature of the [[https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Half_duplex|half-duplex communication]], which limits the speed even further. On the other hand, the RS485 is easy to implement and still very popular in industrial automation.
 To achieve communication between master and slave, some sort of addressing has to be used. In ModbusRTU, each slave device has to have unique ID or **address**, which is a number 0-255.
@@ Line 18: / Line 32: @@
 ===== Setting ModbusRTU server (slave) =====
-In our tutorial, we will use UniPi Neuron L503 which is equipped with two RS485 ports. Let's start with generic project in **Full mode** - attached PLC, one FBD program, configured task and set autogen on the UniPi device. Make sure, that the build and deploy works without any problem. Your workspace should look like this.
+In our tutorial, we will use Unipi Neuron L503 which is equipped with two RS485 ports. Let's start with generic project in **Full mode** - attached PLC, one FBD program, configured task and set autogen on the Unipi device. Make sure, that the build and deploy works without any problem. Your workspace should look like this.
 {{ :en:sw:01-mervis:modbus-server-01-workspace.png?direct |}}
@@ Line 27: / Line 41: @@
 <WRAP center round info 60%>
-We are used to add **channel**, instead of **server channel**. **Channel** is for communication initated by UniPi controller. **Server channel** is for communication initiated by some other device to which the UniPi will respond to.
+We are used to add **channel**, instead of **server channel**. **Channel** is for communication initated by Unipi controller. **Server channel** is for communication initiated by some other device to which the Unipi will respond to.
 </WRAP>
-A new **server-channel** will appear under the **PLC**. Double click on it and on the **Properties panel** change the name to something more descriptive. The channel will be for ModbusRTU master communication, so the name **ModbusRTU-master** makes sense.
+A new **server-channel** will appear under the **PLC**. Double click on it and on the **Properties panel** change the name to something more descriptive. The channel will be for ModbusRTU slave communication, so the name **ModbusRTU-slave** makes sense.
 {{ :en:sw:01-mervis:modbus-server-03-channel-name.png?direct |}}
@@ Line 46: / Line 60: @@
 {{ :en:sw:01-mervis:modbus-server-06-add-server-device.png?direct |}}
-A new device will appear under the channel **ModbusRTU-master**. Double click on it and in the **Properties panel** change the **Device address** to something meaningful. We could change the **Name** as well, but on this channel we will have only one device.
+A new device will appear under the channel **ModbusRTU-slave**. Double click on it and in the **Properties panel** change the **Device address** to something meaningful. We could change the **Name** as well, but on this channel we will have only one device.
 {{ :en:sw:01-mervis:modbus-server-07-device.png?direct |}}
@@ Line 62: / Line 76: @@
 <WRAP center round info 60%>
-We are used to add **channel**, instead of **server channel**. **Channel** is for communication initated by UniPi controller. **Server channel** is for communication initiated by some other device to which the UniPi will respond to.
+We are used to add **channel**, instead of **server channel**. **Channel** is for communication initated by Unipi controller. **Server channel** is for communication initiated by some other device to which the Unipi will respond to.
 </WRAP>
@@ Line 97: / Line 111: @@
 No we prepared everything we need to allow other devices to read and set variables in our PLC via ModbusTCP. The last thing is to define the Modbus registers and coil and their mapping to our variables.
 ===== Defining registers and coils =====
-The Modbus communication is for exchanging data only. The master reads and sets datapoints configured in the slave. In Modbus, there are four types of datapoints you can read or write, but they have only two data types: boolean and word (16bit integer). This is due to the age of the Modbus protocol (more than 40 years), and to keep the communication as simple as possible. Any other datatype (32bit real, string,...) has to be converted to 16bit value, for example by using more datapoints.
+The Modbus communication is for exchanging data only. The master reads and sets datapoints configured in the slave. In Modbus, there are four types of datapoints you can read or write, but they have only two data types: boolean and word (16 bit integer). This is due to the age of the Modbus protocol (more than 40 years), and to keep the communication as simple as possible. Any other datatype (32 bit real, string,...) has to be converted to 16 bit value, for example by using more datapoints.
 ==== Datapoints  ====
@@ Line 130: / Line 144: @@
 The properties are:
   - **Starting element** is the **address of the register**. The address cannot be changed
-  - **Simple transform** offers a way how to transform the value from mapped variable to the Modbus register
+  - **Simple transform** offers a way how to transform the value from mapped variable to the Modbus register, e.g. convert to int, if the mapped variable is real
   - **Function** is the Modbus function by which the register can be read
   - **Mapped variable** contains name of the mapped variable
   - **Type** shows the type of the mapped variable
+To set the **coils** / **inputs** is practically the same, just proceed on the **Digitals** tab.