Modbus protocol introduction:

Modbus protocol is a data communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Modbus protocol has become a de facto standard communication protocol and is now a commonly available means of connecting industrial electronic devices.

Modbus protocol is prevalent in industrial environments because it is openly published and royalty-free. It was developed for industrial applications, such as Building management systems (BMS), Industrial applications, etc. it is relatively easy to deploy and maintain compared to other standards and places few restrictions on transmitting the data format.

The Modbus protocol uses character serial communication lines, Ethernet, or the Internet protocol suite as a transport layer. Modbus supports communication to and from multiple devices connected to the same cable or Ethernet network. For example, there can be a device that measures temperature and another measures humidity connected to the same cable, communicating measurements to the same computer via Modbus.

Master-Slave

At the message level, the Modbus protocol applies the master-slave principle
even though the network communication method is a peer–to–peer. If a controller
originates a message, it does so as a master device and expects a response from
a slave device. Similarly, when a controller receives a message, it constructs a
slave response and returns it to the originating controller.

The Query:

The function code in the query tells the addressed slave device what
action to perform. The data bytes contain any additional information
the slave will need to perform the function. For example, function code 03 will
query the slave to read holding registers and respond with their contents. The
data field must contain the information telling the slave which register to start at
and how many registers to read. The error check field provides a method for the
slave to validate the integrity of the message contents.

The Response:

If the slave makes a normal response, the response’s function code echoes the query’s function code. The data bytes contain the
data collected by the slave, such as register values or status. If an error occurs,
the function code is modified to indicate that the response is an error response,
and the data bytes contain a code that describes the error. The error check field
allows the master to confirm that the message contents are valid

Modbus Network

one master that controls the Modbus data transactions with multiple slaves that respond to the master’s requests to read from or write data to the slaves. 

A standard Modbus serial network has one master and as many as 247 slaves, each with a unique slave address. Modbus TCP is typically implemented on an Ethernet network, and data transactions from a Modbus client are directed toward a Modbus server via an IP address.

Most common protocol versions

 

• • Modbus RTU (Remote Terminal Unit) – used in serial communication and is the most common implementation available for Modbus. Modbus RTU uses a compact, binary data representation for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure data reliability. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.

• • Modbus ASCII – used in serial communication and uses ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. A leading colon frames Modbus ASCII messages (“:”) and trailing newline (CR/LF).

• • Modbus TCP/IP or Modbus TCP – a Modbus variant used for communications over TCP/IP networks, connecting over port 502. It does not require a checksum calculation, as lower layers provide checksum protection.

Modbus Slave object types

The following object types may be provided to a Modbus server by a Modbus client device:

The Modbus Slave reflects its state using these datatypes; you can think of it as a simple database with four tables.

For example, suppose we are the manufacturer of a sensor that measures humidity and temperature. In that case, we might choose to reflect the measured values using to addresses of the Holding register table:

Address 0 holds the humidity current value (assume in unsigned int 16 types)

Address 1 holds the temperature current value (assume in 2’s complement format)

The other “Tables” values are not in use.

Now any Modbus master connected to our sensor can quarry these two registers at any time to get the sensors measured values.

Let’s try it out

To stimulate a connection between a Modbus master and Modbus slave, we’ll need to download two software:

1. QModMaster: a Modbus master software: Download Link
2. PyModSlave: a Modbus slave software: Download Link

   After downloading is done, operate these the software in parallel:

   

   Then:

3. In pyModSlave: Options -> Modbus TCP, ensure the IP is set to localhost 127.0.0.1 and the port to 502 (you can choose another port).
4. In the dropdown, choose TCP protocol and set the unit id to 1:
    
5. Press on connect:
   
6. Do the same (1 to 3) in QModMaster.
7. After the connection is established in pyModSlave, go to the “Holding Registers” table and change some values of the table:



8. In the QModMaster dropdown, choose “Read Holding Registers”:



9. Set “Number of Registers” to 50, which allows us to read 50 values from the Holding registers table of the slave/
10. Press Read/Write:



11. You should see the slave’s current state in the master:
    

Sources

• https://en.wikipedia.org/wiki/Modbus
• https://embeddedtechsolutions.com/modbus-protocol/
• https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html