Modbus: Difference between revisions

From BMSpedia
Jump to navigation Jump to search
← Older edit
AlexDriv (talk | contribs)
Bureaucrats, Interface administrators, Administrators
75 edits
VisualWikitext
No edit summary
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Modbus =
= Modbus =


== Overview ==
== Overview ==
Line 106: Line 105:
[[File:modbus_baudrate_diagram.png|thumb|400px|right|Diagram showing how baud rate affects the time width of each bit on the signal line. A higher baud rate means narrower bit windows and faster data transmission.]]
[[File:modbus_baudrate_diagram.png|thumb|400px|right|Diagram showing how baud rate affects the time width of each bit on the signal line. A higher baud rate means narrower bit windows and faster data transmission.]]


'''Baud rate''' defines the number of signal changes (symbols) per second on the communication line. In the context of Modbus serial communication, one symbol corresponds to one binary bit, so baud rate is effectively the number of bits transmitted per second (bps).
'''Baud rate''' defines the number of signal changes per second on the communication line. In Modbus RTU, one symbol = one binary bit, so baud rate = bits per second.


==== Common Baud Rate Values ====
==== Common Baud Rate Values ====
Line 133: Line 132:
The default baud rate for Modbus RTU is '''9600 bps''', though 19200 bps is very common in BMS environments.
The default baud rate for Modbus RTU is '''9600 bps''', though 19200 bps is very common in BMS environments.


==== How Baud Rate Looks in Binary ====
==== How Baud Rate Affects the Signal ====


Each bit occupies a fixed time window called the '''bit period''', calculated as:
Each bit occupies a fixed time window called the '''bit period''', calculated as:
Line 139: Line 138:
<code>Bit Period = 1 / Baud Rate</code>
<code>Bit Period = 1 / Baud Rate</code>


At 9600 baud, each bit lasts approximately '''104 microseconds'''. At 115200 baud, each bit lasts approximately '''8.7 microseconds'''.
At 9600 baud each bit lasts approximately '''104 microseconds'''. At 115200 baud each bit lasts approximately '''8.7 microseconds'''.
 
{{Mbox
|type=notice
|text=
'''Modbus RTU — Bit-Level Breakdown: Single Byte at 9600 Baud, 8N1'''
 
The byte <code>0x41</code> (decimal 65) on the RS-485 wire at 9600 baud:
 
<pre>
Bit:    Start  D0  D1  D2  D3  D4  D5  D6  D7  Stop
Value:    0    1    0    0    0    0    0    1    0    1
µs each: 104µs per bit window
</pre>
 
* '''Start bit''' (1 bit, always 0): Pulls line LOW — signals receiver to begin reading
* '''D0–D7''' (8 bits): Binary data, transmitted LSB first. <code>0x41</code> = <code>01000001</code> → wire order: 1,0,0,0,0,0,1,0
* '''Stop bit''' (1 bit, always 1): Returns line HIGH — marks end of byte
 
Total frame = 10 bits × 104µs = '''1.04ms per byte'''
}}


{{Mbox
{{Mbox
|type=notice
|type=notice
|text=
|text=
'''Binary Signal Breakdown — Baud Rate Example'''
'''Modbus RTU — Full Message Example: FC03 Read Holding Register'''


Below is what the byte <code>0x41</code> (decimal 65, ASCII "A") looks like on the wire at 9600 baud in Modbus RTU (8N1 framing):
Master reads 1 holding register (address 0x0000 = register 40001) from slave address 0x01.


'''Frame in hex — 8 bytes total:'''
<pre>
<pre>
Bit:   Start D0  D1  D2  D3  D4  D5  D6  D7  Stop
Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ]
Value:   0    1    0    0    0    0    0    1    0    1
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [QtyHi] [QtyLo] [CRCLo] [CRCHi]
        ___                          ___
Hex:   [ 0x01 ] [0x03 ] [0x00 ] [0x00 ] [0x00 ] [0x01 ] [0x84 ] [0x0A ]
    ____|  |________________________|   |________  (idle high = 1, start bit pulls low)
</pre>
</pre>


What each position means:
'''Each byte in Modbus RTU binary (8N1, LSB first, 9600 baud):'''
* '''Start bit''' (1 bit): Always logic 0. Signals the beginning of a byte. Pulls the line LOW.
<pre>
* '''D0–D7''' (8 bits): The actual data byte, transmitted LSB (least significant bit) first. For <code>0x41</code> = <code>01000001</code> binary, the wire sends: 1, 0, 0, 0, 0, 0, 1, 0 (LSB first).
Byte 1 — Slave Address 0x01 (00000001):
* '''Stop bit''' (1 bit): Always logic 1. Returns line HIGH, signalling end of byte.
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  1  0  0  0  0  0  0  0  1
 
Byte 2 — Function Code 0x03 (00000011):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  1  1  0  0  0  0  0  0  1
 
Byte 3 — Register Address High 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  0  0  0  0  0  0  0  0  1
 
Byte 4 — Register Address Low 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  0  0  0  0  0  0  0  0  1
 
Byte 5 — Quantity High 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  0  0  0  0  0  0  0  0  1
 
Byte 6 — Quantity Low 0x01 (00000001):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  1  0   0  0  0  0  0  0  1
 
Byte 7 — CRC Low 0x84 (10000100):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  0  0  1  0  0  0  0  1  1
 
Byte 8 — CRC High 0x0A (00001010):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
  0  0  1   0   1  0   0   0   0   1
 
[S] = Start bit (always 0)  [P] = Stop bit (always 1)
</pre>
 
'''What each field does:'''
{| class="wikitable"
|-
! Bytes !! Field !! Value !! Purpose
|-
| 1 || Slave Address || 0x01 || Target device on the RS-485 bus
|-
| 2 || Function Code || 0x03 || Instruction: Read Holding Registers
|-
| 3–4 || Starting Address || 0x0000 || Begin at register 0 (Modbus register 40001)
|-
| 5–6 || Quantity || 0x0001 || Read 1 register (16-bit value)
|-
| 7–8 || CRC-16 || 0x0A84 || Error check — slave silently discards frame if CRC fails
|}


Total bits per byte at 8N1 = 10 bits (1 start + 8 data + 1 stop).
'''Transmission time at 9600 baud, 8N1:'''
At 9600 baud, one full byte takes: 10 × 104µs = '''1.04 milliseconds'''.
8 bytes × 10 bits = 80 bits → 80 × 104µs = '''8.32ms''' to send the full request frame
}}
}}


Line 168: Line 235:
Higher baud rates require better quality cabling and are more sensitive to signal degradation over distance. As a general rule:
Higher baud rates require better quality cabling and are more sensitive to signal degradation over distance. As a general rule:


* 9600 baud — reliable up to approximately 1200 metres on good RS-485 cable
* 9600 baud — reliable up to approximately 1200 metres on shielded RS-485 cable
* 19200 baud — reliable up to approximately 600 metres
* 19200 baud — reliable up to approximately 600 metres
* 115200 baud — reliable up to approximately 100 metres
* 115200 baud — reliable up to approximately 100 metres
Line 176: Line 243:
=== Parity ===
=== Parity ===


[[File:modbus_parity_diagram.png|thumb|400px|right|Diagram illustrating Even, Odd, and No parity bit positions within a serial data frame. The parity bit is inserted between the last data bit and the stop bit.]]
[[File:modbus_parity_diagram.png|thumb|400px|right|Diagram illustrating Even, Odd, and No parity bit positions within a Modbus RTU serial data frame. The parity bit is inserted between the last data bit and the stop bit.]]
 
'''Parity''' is a basic error detection mechanism. It adds a single extra bit to each transmitted byte, allowing the receiver to detect single-bit transmission errors.


The parity bit is placed after the 8 data bits and before the stop bit(s). It adjusts the total number of 1s in the data frame to be either always even (Even parity) or always odd (Odd parity).
'''Parity''' adds a single calculated bit after the 8 data bits in each Modbus RTU character frame, providing basic single-bit error detection at the byte level. CRC-16 handles error detection at the full message level.


==== Parity Modes ====
==== Parity Modes ====
Line 186: Line 251:
{| class="wikitable"
{| class="wikitable"
|-
|-
! Mode !! Abbreviation !! Description
! Mode !! Code !! Description
|-
|-
| Even Parity || E || The parity bit is set so that the total number of 1 bits in the data byte + parity bit is '''even'''
| Even Parity || E || Parity bit set so total count of 1s in data + parity = '''even'''
|-
|-
| Odd Parity || O || The parity bit is set so that the total number of 1 bits in the data byte + parity bit is '''odd'''
| Odd Parity || O || Parity bit set so total count of 1s in data + parity = '''odd'''
|-
|-
| No Parity || N || No parity bit is transmitted. Error checking relies on CRC only. Requires 2 stop bits in Modbus RTU to maintain frame timing.
| No Parity || N || No parity bit. Error checking relies on CRC-16 only. 2 stop bits recommended per Modbus spec.
|-
|-
| Mark Parity || M || Parity bit is always 1, regardless of data. Rarely used.
| Mark Parity || M || Parity bit always 1. Rarely used.
|-
|-
| Space Parity || S || Parity bit is always 0, regardless of data. Rarely used.
| Space Parity || S || Parity bit always 0. Rarely used.
|}
|}


The Modbus specification recommends '''Even parity''' as the default. However, '''8N1''' (8 data bits, No parity, 1 stop bit) is extremely common in practice and is the de facto standard for most BMS devices.
The Modbus RTU specification recommends '''Even parity''' as the default. However '''8N1''' (no parity, 1 stop bit) is the de facto standard for most BMS devices in practice.
 
==== How Parity Looks in Binary ====


{{Mbox
{{Mbox
|type=notice
|type=notice
|text=
|text=
'''Binary Signal Breakdown — Parity Bit Example'''
'''Modbus RTU — Bit-Level Breakdown: Parity Bit Calculation'''


Example byte: <code>0x31</code> = binary <code>00110001</code>
Example byte: <code>0x31</code> = binary <code>00110001</code>
Count of 1-bits in data = 3


Count of 1 bits: 3 (three 1s in the data byte)
'''Even Parity (8E1)''' — 3 is odd, so parity bit = 1 to reach even total (3+1=4):
<pre>
Bit:  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1  0  0  0  1  1  0  0    1    1
</pre>


'''Even Parity:'''
'''Odd Parity (8O1)''' — 3 is already odd, so parity bit = 0 to keep total odd (3+0=3):
Since there are already 3 ones (odd count), the parity bit is set to '''1''' to make the total even (3 + 1 = 4, which is even).
<pre>
Bit:  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1  0  0  0  1  1  0  0    0    1
</pre>


'''No Parity (8N1)''' — no parity bit, one stop bit only:
<pre>
<pre>
Bit:   Start D0   D1   D2   D3   D4   D5   D6   D7   Par Stop
Bit:   [S] D0 D1 D2 D3 D4 D5 D6 D7  [P]
Value:   0    1   0   0   0   1   1   0   0   1   1
Value: 0    1   0   0   0   1   1   0   0    1
</pre>
</pre>


'''Odd Parity:'''
'''No Parity (8N2)''' — no parity bit, two stop bits to maintain 11-bit frame:
Since there are already 3 ones (odd count), the parity bit is set to '''0''' to keep the total odd (3 + 0 = 3, which is odd).
 
<pre>
<pre>
Bit:   Start D0   D1   D2   D3   D4   D5   D6   D7   Par Stop
Bit:   [S] D0 D1 D2 D3 D4 D5 D6 D7  [P1] [P2]
Value:   0    1   0   0   0   1   1   0   0    0   1
Value: 0    1   0   0   0   1   1   0   0    1   1
</pre>
</pre>


'''No Parity (8N1):'''
[S] = Start bit  [Par] = Parity bit  [P] = Stop bit
No parity bit at all. An extra stop bit is added to maintain frame length.
}}
 
{{Mbox
|type=notice
|text=
'''Modbus RTU — Full Message Example: FC03 Request with Even Parity (8E1)'''
 
Same request as the Baud Rate example — slave 0x01, FC03, register 0x0000, quantity 0x0001, CRC 0x840A — shown with Even parity applied to every byte.
 
Parity rule: count the 1s in D0–D7. If count is odd → parity bit = 1. If count is even → parity bit = 0.


<pre>
<pre>
Bit:    Start D0  D1  D2  D3  D4   D5   D6   D7   Stop Stop
Byte 1 — Slave 0x01 (00000001) — one 1-bit → parity = 1:
Value:    0    1    0    0    0    1   1    0    0   1    1
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
  0   1  0  0  0  0  0  0  0    1    1
 
Byte 2 — FC 0x03 (00000011) — two 1-bits → parity = 0:
  [S] D0 D1  D2  D3  D4  D5  D6  D7  [Par] [P]
  0    1  1  0  0  0  0  0  0    0    1
 
Byte 3 — RegHi 0x00 (00000000) — zero 1-bits → parity = 0:
   [S]  D0  D1 D2  D3  D4  D5  D6  D7  [Par] [P]
  0    0  0  0  0  0  0  0   0    0    1
 
Byte 4 — RegLo 0x00 (00000000) — zero 1-bits → parity = 0:
  [S]  D0  D1  D2 D3  D4  D5  D6  D7  [Par] [P]
  0    0  0  0  0  0  0  0   0    0    1
 
Byte 5 — QtyHi 0x00 (00000000) — zero 1-bits → parity = 0:
  [S]  D0  D1  D2  D3 D4  D5  D6  D7  [Par] [P]
  0    0  0  0   0   0   0   0   0    0    1
 
Byte 6 — QtyLo 0x01 (00000001) — one 1-bit → parity = 1:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    1   0  0  0  0  0  0  0   1    1
 
Byte 7 — CRCLo 0x84 (10000100) — two 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   0  1  0  0  0  0  1   0    1
 
Byte 8 — CRCHi 0x0A (00001010) — two 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   1  0  1   0  0  0  0   0    1
</pre>
</pre>


What each position means:
8E1 framing = 11 bits per byte (1 start + 8 data + 1 parity + 1 stop)
* '''Start bit''': Always 0. Triggers the receiver to start reading.
8 bytes × 11 bits = 88 bits → at 9600 baud = '''9.17ms''' to transmit the full request
* '''D0–D7''': The 8 data bits (LSB first).
 
* '''Parity bit''': Calculated from the data bits. Used to detect single-bit errors.
The parity bit is recalculated independently for each byte — it is not a fixed value across the frame.
* '''Stop bit(s)''': Always 1. Marks the end of the character frame.
}}
}}


==== Parity Limitation ====
==== Parity Limitation ====


Parity can only detect an '''odd number''' of bit errors. If two bits flip simultaneously (double-bit error), the parity check will still pass even though the data is wrong. This is why Modbus RTU also uses CRC-16 at the message level — the two mechanisms complement each other.
Parity can only detect an '''odd number''' of bit errors. If two bits flip simultaneously the parity check still passes even though the data is corrupted. This is why Modbus RTU also uses CRC-16 at the message level — the two mechanisms complement each other.


----
----
Line 251: Line 358:
=== Data Bits ===
=== Data Bits ===


[[File:modbus_databits_diagram.png|thumb|400px|right|Diagram showing the position of data bits within a serial frame. Data bits D0 through D7 carry the actual payload, transmitted LSB first.]]
[[File:modbus_databits_diagram.png|thumb|400px|right|Data bit positions D0–D7 within a Modbus RTU character frame. Data bits carry the actual payload and are transmitted LSB first.]]
 
'''Data bits''' refers to the number of bits used to represent each unit of data (one character or byte) within a single serial frame.


In Modbus, this value is virtually always '''8 data bits'''. Using 8 bits allows each frame to carry one full byte of information, which aligns directly with how Modbus RTU encodes its binary protocol data.
'''Data bits''' refers to the number of bits carrying actual payload within each Modbus RTU character frame. This is always '''8''' in Modbus RTU. 8 bits = 1 byte = values 0–255 per frame. For values larger than 255, Modbus RTU uses two consecutive bytes (one 16-bit register) or four bytes (two registers for 32-bit floating point values).
 
The only exception is Modbus ASCII, which can operate with 7 data bits because it uses only printable ASCII characters (all of which fit within 7 bits).
 
==== How Data Bits Look in Binary ====


{{Mbox
{{Mbox
|type=notice
|type=notice
|text=
|text=
'''Binary Signal Breakdown — Data Bits Detail'''
'''Modbus RTU — Bit-Level Breakdown: Data Bit Weighting'''


Example byte: <code>0xB4</code> = decimal 180 = binary <code>10110100</code>
Example byte: <code>0xB4</code> = decimal 180 = binary <code>10110100</code>


The 8 data bits are transmitted '''LSB first''' (D0 is the least significant bit):
Modbus RTU transmits data bits LSB first (D0 transmitted first, D7 last):
 
<pre>
<pre>
Bit position:  Start D0   D1   D2   D3   D4   D5   D6   D7   Stop
Bit:  [S] D0 D1 D2 D3 D4 D5 D6 D7 [P]
Binary value:     0    0   0   1   0   1   1   0    1    1
Value: 0    0   0   1   0   1   1   0   1   1
</pre>
</pre>
Reading the data bits from D0 to D7: 0, 0, 1, 0, 1, 1, 0, 1
Reversing to MSB order (D7 to D0): 1, 0, 1, 1, 0, 1, 0, 0 = <code>10110100</code> = <code>0xB4</code> ✓
'''What each data bit position represents:'''


{| class="wikitable"
{| class="wikitable"
|-
|-
! Bit !! Position !! Binary Weighting !! Notes
! Bit !! Wire Order !! Weight !! Bit Value in 0xB4 !! Contributes
|-
|-
| D0 || Least Significant Bit || 2⁰ = 1 || Transmitted first on the wire
| D0 || 1st transmitted || 2⁰ = 1 || 0 || 0
|-
|-
| D1 || — || 2¹ = 2 || —
| D1 || 2nd || 2¹ = 2 || 0 || 0
|-
|-
| D2 || — || 2² = 4 || —
| D2 || 3rd || 2² = 4 || 1 || 4
|-
|-
| D3 || — || 2³ = 8 || —
| D3 || 4th || 2³ = 8 || 0 || 0
|-
|-
| D4 || — || 2⁴ = 16 || —
| D4 || 5th || 2⁴ = 16 || 1 || 16
|-
|-
| D5 || — || 2⁵ = 32 || —
| D5 || 6th || 2⁵ = 32 || 1 || 32
|-
|-
| D6 || — || 2⁶ = 64 || —
| D6 || 7th || 2⁶ = 64 || 0 || 0
|-
|-
| D7 || Most Significant Bit || 2⁷ = 128 || Transmitted last, before parity/stop
| D7 || 8th (last) || 2⁷ = 128 || 1 || 128
|-
| '''Total''' || — || — || — || '''4+16+32+128 = 180 = 0xB4 ✓'''
|}
|}
}}


The total possible values representable by 8 data bits = 2⁸ = 256 (values 0–255).
{{Mbox
|type=notice
|text=
'''Modbus RTU — Full Message Example: FC03 Slave Response with Register Decoding'''
 
Slave 0x01 responds to the FC03 request. Register 40001 holds value 0x0190 (decimal 400), representing a supply air temperature of 40.0°C with a scale factor of ÷10.
 
'''Response frame in hex — 7 bytes total:'''
<pre>
Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ]
Field: [Slave ] [ FC  ] [ByteCt] [DatHi] [DatLo] [CRCLo] [CRCHi]
Hex:  [ 0x01 ] [0x03 ] [ 0x02 ] [0x01 ] [0x90 ] [0xF8 ] [0x4B ]
</pre>
 
'''Critical bytes expanded in Modbus RTU binary (8N1, LSB first):'''
<pre>
Byte 3 — Byte Count 0x02 (00000010):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
  0    0  1  0  0  0  0  0  0    1
  D1 = 2¹ = 2 → 2 data bytes follow (one 16-bit register) ✓
 
Byte 4 — Data High Byte 0x01 (00000001):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
  0    1  0  0  0  0  0  0  0    1
  D0 = 1 → high byte value = 1
 
Byte 5 — Data Low Byte 0x90 (10010000):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
  0    0  0  0  0  1  0  0  1    1
  D4 = 16, D7 = 128 → 16+128 = 144 = 0x90
</pre>
 
'''Reconstructing the 16-bit register value (Big Endian — high byte first):'''
<pre>
High byte:  0x01 × 256  =  256
Low byte:  0x90        =  144
                          ─────
Register value:            400  =  0x0190
 
Applied scale factor ÷10:  400 ÷ 10  =  40.0°C
</pre>
 
Modbus RTU always sends the high byte of a 16-bit register before the low byte. This is Big Endian byte order. Some devices deviate from this — always check the device register map.
}}
}}


Line 309: Line 448:
=== Stop Bits ===
=== Stop Bits ===


[[File:modbus_stopbits_diagram.png|thumb|400px|right|Diagram comparing 1 stop bit vs 2 stop bits in a serial frame. The stop bit(s) are the final element of a character frame, returning the line to the idle HIGH state.]]
[[File:modbus_stopbits_diagram.png|thumb|400px|right|Diagram comparing 1 stop bit vs 2 stop bits in a Modbus RTU character frame. Stop bits return the RS-485 line to idle HIGH after each transmitted byte.]]
 
'''Stop bits''' mark the end of a character frame. After the data bits (and optional parity bit) have been transmitted, the transmitter sends one or two stop bits by holding the line in the HIGH (idle) state for the duration of those bit periods.


Stop bits give the receiver time to process the incoming byte and prepare for the next start bit. They also provide a guaranteed idle state between characters so that the receiver can reliably detect the falling edge of the next start bit.
'''Stop bits''' return the RS-485 line to the idle HIGH state after each Modbus RTU character frame. The receiver requires this idle period to correctly detect the falling edge of the next start bit.


==== Stop Bit Configurations ====
==== Stop Bit Configurations ====
Line 319: Line 456:
{| class="wikitable"
{| class="wikitable"
|-
|-
! Configuration !! Stop Bits !! When Used
! Config !! Stop Bits !! Parity !! Total Bits per Frame !! Notes
|-
|-
| 8N1 || 1 stop bit || No parity — most common Modbus RTU configuration
| 8N1 || 1 || None || 10 || Most common Modbus RTU configuration in BMS
|-
|-
| 8E1 || 1 stop bit || Even parity
| 8E1 || 1 || Even || 11 || Modbus RTU spec default — even parity + 1 stop
|-
|-
| 8O1 || 1 stop bit || Odd parity
| 8O1 || 1 || Odd || 11 || Odd parity + 1 stop
|-
|-
| 8N2 || 2 stop bits || No parity — provides additional recovery time; used on noisy lines
| 8N2 || 2 || None || 11 || No parity, 2 stops — maintains 11-bit frame on noisy lines
|}
|}


The Modbus specification states: if no parity is used, 2 stop bits are recommended to maintain equivalent frame length. In practice however, 8N1 (1 stop bit, no parity) is by far the most common configuration encountered in BMS installations.
{{Mbox
|type=notice
|text=
'''Modbus RTU — Bit-Level Breakdown: Stop Bit Comparison'''
 
Example byte: <code>0x55</code> = binary <code>01010101</code> — four 1-bits (even count)


==== How Stop Bits Look in Binary ====
'''8N1 — No Parity, 1 Stop Bit (10 bits total):'''
<pre>
Bit:  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
Value:  0    1  0  1  0  1  0  1  0    1
        ←————————————— 10 bits ——————————————→
</pre>
 
'''8E1 — Even Parity, 1 Stop Bit (11 bits total):'''
Four 1-bits in data = even count → parity bit = 0
<pre>
Bit:  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1  0  1  0  1  0  1  0    0    1
        ←—————————————— 11 bits ———————————————→
</pre>
 
'''8N2 — No Parity, 2 Stop Bits (11 bits total):'''
<pre>
Bit:  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P1] [P2]
Value:  0    1  0  1  0  1  0  1  0    1    1
        ←—————————————— 11 bits ———————————————→
</pre>
 
If the line goes LOW before the stop bit period ends, the receiver flags a '''framing error''' and discards the byte. The resulting CRC mismatch causes the master to timeout with no response.
}}


{{Mbox
{{Mbox
|type=notice
|type=notice
|text=
|text=
'''Binary Signal Breakdown — Stop Bit Comparison'''
'''Modbus RTU — Full Message Example: FC06 Write Single Register'''
 
Example byte: <code>0x55</code> = binary <code>01010101</code>


'''8E1 — Even Parity, 1 Stop Bit:'''
Master writes value 0x0064 (decimal 100 = setpoint 10.0°C at scale ÷10) to register 40002 (address 0x0001) on slave 0x01.
Number of 1s in data = 4 (even), so parity bit = 0


'''Request frame in hex — 8 bytes:'''
<pre>
<pre>
Bit:   Start D0  D1  D2  D3  D4  D5  D6  D7  Par Stop
Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8 ]
Value:   0    1    0    1    0    1    0    1    0    0    1
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [ValHi] [ValLo] [CRCLo] [CRCHi]
        ←————————————————— 11 bits total ——————————————————→
Hex:  [ 0x01 ] [0x06 ] [0x00 ] [0x01 ] [0x00 ] [0x64 ] [0x49 ] [0xA4 ]
</pre>
</pre>


'''8N2 — No Parity, 2 Stop Bits:'''
'''Full frame in Modbus RTU binary, 8N1 (LSB first):'''
 
<pre>
<pre>
Bit:   Start D0   D1   D2   D3   D4   D5   D6   D7   Stop Stop
          [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
Value:   0   1   0   1   0   1   0   1   0   1   1
Byte 1 0x01: 0 1  0  0  0  0  0  0  0  1  ← Slave address
        ←————————————————— 11 bits total ——————————————————→
Byte 2 0x06: 0  0  1  1  0  0  0  0  0  1  ← Write Single Register
Byte 3 0x00: 0  0  0  0  0  0  0  0  0  1  ← Register address high
Byte 4 0x01: 0  1  0   0   0   0   0   0   0   1   ← Register address low (reg 40002)
Byte 5 0x00: 0  0  0  0  0  0  0  0  0  1  ← Value high byte
Byte 6 0x64: 0 0  0  1  0  0  1  1   0   1   ← Value low byte (100 decimal)
Byte 7 0x49: 0 1   0  0   1   0   0  1   0  1   ← CRC low
Byte 8 0xA4: 0  0  0  1  0  0  1  0  1  1  ← CRC high
</pre>
</pre>


Both configurations result in 11 bits per character frame, maintaining the same total frame length and timing compatibility.
On a successful FC06 write the slave echoes the '''entire 8-byte request frame back unchanged''' as its response. If the stop bit on any byte is corrupted, that byte is discarded as a framing error, the CRC check fails, and the master receives no response.


'''Key rule:''' The line must be idle (HIGH) for the entire stop bit period before the next start bit (LOW) can be recognised. If the line goes low before the stop bit period ends, the receiver flags a '''framing error'''.
Transmission time at 9600 baud, 8N1: 8 bytes × 10 bits × 104µs = '''8.32ms'''
}}
}}


Line 367: Line 535:
=== Flow Control ===
=== Flow Control ===


[[File:modbus_flowcontrol_diagram.png|thumb|400px|right|Diagram showing hardware flow control signals RTS and CTS on a serial connection. In RS-485 half-duplex operation, RTS is used to switch the driver between transmit and receive mode.]]
[[File:modbus_flowcontrol_diagram.png|thumb|400px|right|RS-485 RTS direction switching during a Modbus RTU request/response cycle. The master asserts DE HIGH to transmit, then releases the bus before the slave responds.]]


'''Flow control''' is a mechanism that manages the rate of data transmission between devices, preventing a fast sender from overwhelming a slow receiver. In Modbus serial communication, flow control is relevant primarily in RS-232 connections and in RS-485 half-duplex bus switching.
'''Flow control''' in Modbus RTU on RS-485 is almost always set to '''None''' in software. The physical RS-485 half-duplex bus requires direction switching between transmit and receive, but this is handled by the hardware driver enable (DE) pin on the RS-485 transceiver, not by a software flow control protocol.


==== Flow Control Types ====
==== Flow Control Types ====
Line 375: Line 543:
{| class="wikitable"
{| class="wikitable"
|-
|-
! Type !! Method !! Description
! Type !! Method !! Compatible with Modbus RTU
|-
|-
| None || — || No flow control. The most common setting for Modbus RTU on RS-485.
| None || — || ✓ Standard for RS-485 Modbus RTU
|-
|-
| Hardware (RTS/CTS) || Physical signal lines || The sender asserts RTS (Request To Send); receiver replies with CTS (Clear To Send). Data flows only when CTS is active.
| Hardware RTS/CTS || Physical signal lines || Only on RS-232 point-to-point connections
|-
|-
| Software (XON/XOFF) || In-band control bytes || Special ASCII characters (0x11 = XON, 0x13 = XOFF) are inserted into the data stream to pause and resume transmission. Not compatible with binary protocols like Modbus RTU.
| Software XON/XOFF || In-band bytes 0x11 / 0x13 || ✗ Incompatible — Modbus RTU is a binary protocol
|-
|-
| RTS toggle (RS-485) || RTS line used for direction control || In half-duplex RS-485, the RTS line is used to switch the transceiver between transmit mode and receive mode. This is a driver enable signal, not true flow control.
| RTS as DE toggle || RTS drives RS-485 DE pin || ✓ Used by USB-RS485 adapters for direction switching
|}
|}


==== RS-485 and Half-Duplex Direction Control ====
{{Mbox
|type=notice
|text=
'''Modbus RTU — Bit-Level Breakdown: RS-485 Half-Duplex Direction Control'''
 
In Modbus RTU on RS-485, the driver enable (DE) signal controls which device owns the bus. Only one device may drive the bus at any time.


RS-485 is inherently a half-duplex medium — devices cannot transmit and receive simultaneously. To prevent bus contention, the RS-485 driver must be enabled only when transmitting and returned to receive mode immediately after.
<pre>
              MASTER TRANSMITTING              MASTER LISTENING
DE (Master):  ________________________
            |                        |________________________________
            ^ DE asserted HIGH        ^ DE released LOW


In many Modbus RTU implementations, the RTS signal from the UART is wired to the DE/RE (Driver Enable / Receiver Enable) pins of the RS-485 transceiver chip. This is often called '''RTS flow control''' in software configuration, even though it is technically a bus direction control mechanism rather than data flow control.
TX (Master):  [ Start bits of frame...data bytes...CRC ]
            |←————————————————————————————————————————→|
 
                                      ↑
                              3.5 character-time
                              silent gap (~3.6ms at 9600 baud)
                              marks end of Modbus RTU frame
 
DE (Slave):                                        ______________________
                                                  |
                                                  ^ Slave asserts its DE HIGH
 
RX (Master):                                      [ Slave response frame ]
</pre>
 
* DE HIGH = RS-485 driver active, device is transmitting
* DE LOW = RS-485 driver disabled, device is listening
* The 3.5 character-time silent gap is how Modbus RTU detects frame boundaries — there is no delimiter byte
* If DE is not released fast enough, the master's driver will collide with the slave's response on the bus
}}


{{Mbox
{{Mbox
|type=notice
|type=notice
|text=
|text=
'''Binary Signal Breakdown — RS-485 RTS/Direction Control'''
'''Modbus RTU — Full Message Example: FC03 Read 2 Registers — Complete Request/Response Cycle'''
 
Master reads 2 holding registers from slave 0x02, starting at address 0x0010 (registers 40017 and 40018). These could represent, for example, active power high and low bytes from an energy meter.
 
'''Master request frame — 8 bytes:'''
<pre>
Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ]
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [QtyHi] [QtyLo] [CRCLo] [CRCHi]
Hex:  [ 0x02 ] [0x03 ] [0x00 ] [0x10 ] [0x00 ] [0x02 ] [0xC4 ] [0x38 ]
</pre>


Sequence when a Modbus master sends a request:
'''Slave response frame — 9 bytes:'''
<pre>
Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ] [  9  ]
Field: [Slave ] [ FC  ] [ByteCt] [R1Hi ] [R1Lo ] [R2Hi ] [R2Lo ] [CRCLo] [CRCHi]
Hex:  [ 0x02 ] [0x03 ] [ 0x04 ] [0x00 ] [0xC8 ] [0x01 ] [0x2C ] [0x77 ] [0xDF ]
</pre>


'''Both frames in Modbus RTU binary, 8N1 (LSB first):'''
<pre>
<pre>
Time →
REQUEST:
          [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
0x02 Addr:  0  0  1  0  0  0  0  0  0  1
0x03 FC:    0  1  1  0  0  0  0  0  0  1
0x00 RegHi: 0  0  0  0  0  0  0  0  0  1
0x10 RegLo: 0  0  0  0  0  1  0  0  0  1
0x00 QtyHi: 0  0  0  0  0  0  0  0  0  1
0x02 QtyLo: 0  0  1  0  0  0  0  0  0  1
0xC4 CRCLo: 0  0  0  1  0  0  0  1  1  1
0x38 CRCHi: 0  0  0  0  1  1  1  0  0  1
 
[— 3.5 char silent gap (~3.6ms at 9600 baud) — master releases bus — slave responds —]


RTS:    ___________________
RESPONSE:
      |                  |
          [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
_______|                  |_______   (RTS HIGH = transmit mode enabled)
0x02 Addr:  0  0  1  0  0  0  0  0  0  1
0x03 FC:    0  1  1  0  0  0  0  0  0  1
0x04 BytCt: 0  0  0  1  0  0  0  0  0  1
0x00 R1Hi:  0  0  0  0  0  0  0  0  0  1
0xC8 R1Lo:  0  0  0  0  1  0  0  1  1  1
0x01 R2Hi:  0  1  0  0  0  0  0  0  0  1
0x2C R2Lo:  0  0  1  1  0  1   0  0  0  1
0x77 CRCLo: 0  1  1  1  0  1  1  1  0  1
0xDF CRCHi: 0  1  1  1  1  1  0  1  1  1
</pre>


TX:   |  [Modbus Frame Data............] |
'''Decoding the two register values from the response (Big Endian — high byte first):'''
      ^                                  ^
<pre>
    RTS asserted                      RTS released
Register 1 (40017):
    (driver enabled)              (driver disabled, line released)
  High byte 0x00 = 0 × 256  =  0
  Low  byte 0xC8 =          = 200
  Value = 0 + 200            = 200


RX:   _______________________________________
Register 2 (40018):
                                              |
  High byte 0x01 = 1 × 256  = 256
                                              | ← Slave response begins here
  Low  byte 0x2C =          =  44
  Value = 256 + 44          = 300
</pre>
</pre>


'''What each signal does:'''
If these were active power registers with a scale factor of ÷10:
* '''RTS asserted HIGH:''' Enables the RS-485 driver. The master ''owns'' the bus and transmits its request frame.
Register 1 = 20.0 kW, Register 2 = 30.0 kW
* '''TX line:''' Carries the actual Modbus RTU binary data (address, function code, data, CRC).
* '''RTS released LOW:''' Disables the RS-485 driver. The master releases the bus and switches to receive mode.
* '''RX line:''' The slave's response arrives. The master reads it with its receiver enabled.


Timing of RTS is critical — releasing too early can truncate the last stop bit of the frame. Releasing too late blocks the slave response. Most modern USB-RS485 adapters handle this automatically.
'''Transmission times at 9600 baud, 8N1:'''
<pre>
Request:    8 bytes × 10 bits × 104µs  =  8.32ms
Silent gap:                            ≈  3.60ms
Response:  9 bytes × 10 bits × 104µs  =  9.36ms
                                          ───────
Total cycle time:                      ≈  21.28ms
</pre>
 
The silent gap between the master frame and slave response is critical. If the master releases its driver too late it will collide with the slave's response. If the slave responds before the gap completes, the master will misinterpret the response as a continuation of its own transmission.
}}
}}
In most BMS applications using RS-485, flow control is set to '''None''' in the software configuration, with the hardware adapter managing direction control automatically. Only when using older RS-232 point-to-point wiring is explicit hardware flow control (RTS/CTS) typically required.


----
----
Line 437: Line 675:
Coils are single-bit read/write values. They represent binary output states such as a relay, a digital output, or an on/off command. The address range is 1–9999 (using 1-based Modbus convention) or 0x0000–0xFFFF (using the 0-based PDU addressing).
Coils are single-bit read/write values. They represent binary output states such as a relay, a digital output, or an on/off command. The address range is 1–9999 (using 1-based Modbus convention) or 0x0000–0xFFFF (using the 0-based PDU addressing).


Examples in BMS: Fan on/off command, valve open/close output, alarm reset.
Examples in BMS: fan on/off command, valve open/close output, alarm reset.


=== Discrete Inputs ===
=== Discrete Inputs ===
Line 443: Line 681:
Discrete inputs are single-bit read-only values. They represent binary input states such as a digital sensor, a status contact, or a switch position. Address range: 10001–19999.
Discrete inputs are single-bit read-only values. They represent binary input states such as a digital sensor, a status contact, or a switch position. Address range: 10001–19999.


Examples in BMS: Door open sensor, high temperature alarm contact, filter dirty status.
Examples in BMS: door open sensor, high temperature alarm contact, filter dirty status.


=== Holding Registers ===
=== Holding Registers ===
Line 449: Line 687:
Holding registers are 16-bit read/write registers. They are the most commonly used data type in Modbus and can hold values such as setpoints, configurations, and output values. Address range: 40001–49999.
Holding registers are 16-bit read/write registers. They are the most commonly used data type in Modbus and can hold values such as setpoints, configurations, and output values. Address range: 40001–49999.


A single holding register holds values from 0 to 65535 (unsigned) or -32768 to 32767 (signed). For larger values (e.g. floating point temperatures or energy readings), two consecutive registers are used together to form a 32-bit value.
A single holding register holds values from 0 to 65535 (unsigned) or -32768 to 32767 (signed). For larger values such as floating point temperatures or energy readings, two consecutive registers are used together to form a 32-bit value.


Examples in BMS: Temperature setpoint, VFD speed reference, valve position command.
Examples in BMS: temperature setpoint, VFD speed reference, valve position command.


=== Input Registers ===
=== Input Registers ===
Line 457: Line 695:
Input registers are 16-bit read-only registers. They represent measured or computed values provided by the slave device. Address range: 30001–39999.
Input registers are 16-bit read-only registers. They represent measured or computed values provided by the slave device. Address range: 30001–39999.


Examples in BMS: Supply air temperature, room CO₂ concentration, energy meter active power reading.
Examples in BMS: supply air temperature, room CO₂ concentration, energy meter active power reading.


----
----
Line 463: Line 701:
== Function Codes ==
== Function Codes ==


Function codes tell the slave device what action to perform. They are carried in the second byte of every Modbus frame.
Function codes tell the slave device what action to perform. They are carried in the second byte of every Modbus RTU frame.


=== Read Functions ===
=== Read Functions ===
Line 516: Line 754:
=== CRC and LRC Checking ===
=== CRC and LRC Checking ===


'''CRC-16 (Cyclic Redundancy Check)''' is used in Modbus RTU. It is a 16-bit error detection value calculated from all bytes in the message (excluding the CRC bytes themselves). The master calculates the CRC before sending, and the slave recalculates it upon receipt. If the values do not match, the message is discarded silently — no response is sent, and the master will timeout.
'''CRC-16 (Cyclic Redundancy Check)''' is used in Modbus RTU. It is a 16-bit error detection value calculated from all bytes in the message excluding the CRC bytes themselves. The master calculates the CRC before sending, and the slave recalculates it upon receipt. If the values do not match, the message is discarded silently — no response is sent, and the master will timeout.


The CRC polynomial used is: <code>0xA001</code> (reflected form of CRC-16-IBM).
The CRC polynomial used is: <code>0xA001</code> (reflected form of CRC-16-IBM).


'''LRC (Longitudinal Redundancy Check)''' is used in Modbus ASCII. It is calculated as the two's complement of the sum of all byte values in the message. It is simpler but less robust than CRC-16.
'''LRC (Longitudinal Redundancy Check)''' is used in Modbus ASCII only. It is calculated as the two's complement of the sum of all byte values in the message. It is simpler but less robust than CRC-16.


=== Exception Codes ===
=== Exception Codes ===
Line 538: Line 776:
| 04 || 0x04 || Slave Device Failure || An unrecoverable error occurred in the slave
| 04 || 0x04 || Slave Device Failure || An unrecoverable error occurred in the slave
|-
|-
| 05 || 0x05 || Acknowledge || Slave accepted the request but needs more time (long operation)
| 05 || 0x05 || Acknowledge || Slave accepted the request but needs more time
|-
|-
| 06 || 0x06 || Slave Device Busy || Slave is busy processing a previous request
| 06 || 0x06 || Slave Device Busy || Slave is busy processing a previous request
Line 568: Line 806:
=== Wiring and Topology ===
=== Wiring and Topology ===


Modbus RTU on RS-485 uses a '''daisy-chain bus topology'''. Devices are connected in series from the first to the last node. The two conductors of the RS-485 pair are labelled A (−) and B (+), though manufacturers often use inconsistent naming (some label them D− / D+, or even reverse the A/B convention).
Modbus RTU on RS-485 uses a '''daisy-chain bus topology'''. Devices are connected in series from the first to the last node. The two conductors of the RS-485 pair are labelled A (−) and B (+), though manufacturers often use inconsistent naming — some label them D− / D+, or even reverse the A/B convention entirely.


Key wiring rules:
Key wiring rules:
* '''Termination resistors''' of 120Ω must be fitted at both physical ends of the RS-485 bus to prevent signal reflections. Only the two end devices are terminated — never intermediate devices.
* '''Termination resistors''' of 120Ω must be fitted at both physical ends of the RS-485 bus to prevent signal reflections. Only the two end devices are terminated — never intermediate devices.
* '''Bias resistors''' (typically 560Ω to 1kΩ) are recommended to hold the bus at a defined state when no device is transmitting, preventing false start bit detection.
* '''Bias resistors''' (typically 560Ω to 1kΩ) are recommended to hold the bus at a defined state when no device is transmitting, preventing false start bit detection on an idle line.
* '''Maximum cable length''' depends on baud rate (see Baud Rate section), but 1200 metres at 9600 baud is a typical practical limit for standard twisted pair cable.
* '''Maximum cable length''' depends on baud rate (see Baud Rate section), but 1200 metres at 9600 baud is a typical practical limit for standard twisted pair cable.
* The maximum number of addressable slave devices is 247, though the RS-485 electrical standard supports up to 32 unit loads on a single segment without repeaters (256 with 1/8 unit load devices).
* The maximum number of addressable slave devices is 247, though the RS-485 electrical standard supports up to 32 unit loads on a single segment without repeaters (256 with 1/8 unit load devices).
Line 579: Line 818:
=== Common Issues and Troubleshooting ===
=== Common Issues and Troubleshooting ===


The following are the most frequently encountered Modbus communication problems in BMS installations:
The following are the most frequently encountered Modbus RTU communication problems in BMS installations:


'''No response from slave / timeout'''
'''No response from slave / timeout'''
Line 591: Line 830:
* Check for missing or incorrectly placed termination resistors
* Check for missing or incorrectly placed termination resistors
* Reduce baud rate to test if the issue is speed-related
* Reduce baud rate to test if the issue is speed-related
* Check for ground loops (ensure shield is grounded at one end only)
* Check for ground loops — ensure cable shield is grounded at one end only


'''Intermittent communication'''
'''Intermittent communication'''
Line 600: Line 839:
'''Incorrect register values'''
'''Incorrect register values'''
* Confirm register addressing convention — some devices use 0-based addressing, others 1-based
* Confirm register addressing convention — some devices use 0-based addressing, others 1-based
* Check byte order (endianness) for 32-bit floating point values — some devices use Big Endian, others Little Endian or mixed (''byte-swapped'') formats
* Check byte order (endianness) for 32-bit floating point values — some devices use Big Endian, others Little Endian or mixed (byte-swapped) formats
* Verify scaling factors — a register reading of 1234 may represent 12.34 depending on the device's register map
* Verify scaling factors — a register reading of 1234 may represent 12.34 depending on the device register map
 
----

Latest revision as of 23:47, 24 February 2026

Modbus

Overview

Modbus is an open, serial communication protocol originally developed for use in programmable logic controllers (PLCs). It has since become one of the most widely deployed industrial communication protocols in the world, particularly in Building Management Systems (BMS), SCADA environments, energy metering, and industrial automation.

Modbus operates on a master-slave (also referred to as client-server in newer documentation) architecture, where a single master device initiates all communication and one or more slave devices respond. It is valued for its simplicity, robustness, and vendor-neutral design — making it ideal for integrating devices from multiple manufacturers into a unified control system.

In BMS applications, Modbus is commonly used to communicate with energy meters, variable frequency drives (VFDs), chillers, boilers, air handling units (AHUs), and a wide range of sensors and actuators.

History

Modbus was developed in 1979 by Modicon (now a brand of Schneider Electric) for use with their programmable logic controllers. It was designed as a simple and robust protocol for serial communication between controllers on a production floor.

In 1996, Modbus over TCP/IP (Modbus TCP) was introduced, allowing the protocol to be used over modern Ethernet networks. This dramatically expanded its use cases and kept it relevant into the internet era.

In 2004, the rights to the Modbus specification were transferred to the Modbus Organization, a non-profit trade association that maintains and promotes the standard to this day. The protocol remains publicly available and royalty-free, which is a significant reason for its continued adoption over proprietary alternatives.

Today Modbus exists in three primary variants: Modbus RTU and Modbus ASCII (both for serial communication), and Modbus TCP/IP (for Ethernet communication).

Protocol Architecture

Master-Slave Model

Modbus uses a strict master-slave architecture. There is always one master and up to 247 addressable slave devices on a single serial bus. Each slave is assigned a unique address between 1 and 247. Address 0 is reserved for broadcast messages, which all slaves receive but do not respond to.

The master is always the initiator of communication. A slave device never transmits data unless it has first been queried by the master. This eliminates bus collisions and keeps the protocol deterministic — an important quality in control systems where timing and reliability are critical.

In a BMS context, the master is typically the Building Management Controller (BMC) or a gateway device, and the slaves are field devices such as energy meters, controllers, or sensors.

Request-Response Cycle

Every Modbus transaction follows a simple two-step cycle:

  1. The master sends a request frame to a specific slave address (or broadcast to address 0).
  2. The slave receives the request, processes it, and returns a response frame to the master.

If the slave receives a valid request but cannot comply (e.g. the register address does not exist), it returns an exception response containing an error code. If the master receives no response within its configured timeout window, it may retry the request or log a communication fault.

A full Modbus RTU frame consists of the following fields in order:

Field Size Description
Device Address 1 byte Slave address (1–247), or 0 for broadcast
Function Code 1 byte Defines the type of action requested
Data Variable Register addresses, values, or quantities
CRC 2 bytes Error checking (Cyclic Redundancy Check)

Transmission Modes

Modbus RTU

Modbus RTU (Remote Terminal Unit) is the most common implementation of the protocol in BMS and industrial environments. Data is transmitted as binary bytes over an RS-232 or RS-485 serial connection.

Each byte of data is encoded as a single binary character. The framing of messages is defined by silent intervals (gaps) between characters — a gap of at least 3.5 character times signals the start or end of a message frame.

RTU is preferred over ASCII for most applications because it is more efficient: it transmits the same data in roughly half the number of bytes, making better use of available bandwidth.

Key characteristics:

  • Binary encoding
  • CRC-16 error checking
  • Message framing via inter-character silence (3.5 character times)
  • Physical layer: RS-485 (most common), RS-232, RS-422

Modbus ASCII

Modbus ASCII transmits data as ASCII text characters rather than raw binary. Each byte of data is represented as two hexadecimal ASCII characters (e.g. the byte 0x5B is sent as the characters 5 and B).

ASCII mode uses a colon (:) as a start delimiter and CR/LF characters as an end delimiter. It uses LRC (Longitudinal Redundancy Check) for error checking rather than CRC.

ASCII mode is less bandwidth-efficient than RTU but is easier to debug with simple terminal tools and is more tolerant of timing variations on noisy or slow serial lines. It is rarely used in modern BMS installations.

Modbus TCP/IP

Modbus TCP/IP wraps the standard Modbus PDU (Protocol Data Unit) inside a TCP packet and transmits it over a standard Ethernet network. It uses port 502 by default.

The serial-specific fields (device address and CRC) are replaced by a MBAP header (Modbus Application Protocol header), which contains a transaction identifier, protocol identifier, message length, and unit identifier.

Modbus TCP removes the need for RS-485 wiring and allows Modbus devices to be integrated into IP-based building networks. Many modern BMS gateways and energy meters support Modbus TCP natively or via an RS-485-to-Ethernet converter.

Communication Parameters

Communication parameters are the settings that define how data is physically transmitted between the master and slave devices on a serial Modbus network. All devices on the same bus must be configured with identical parameters — a mismatch in any one setting will cause communication failures.

The parameters covered here apply primarily to Modbus RTU and Modbus ASCII (serial variants). Modbus TCP uses standard IP networking parameters instead.

Baud Rate

File:modbus baudrate diagram.png
Diagram showing how baud rate affects the time width of each bit on the signal line. A higher baud rate means narrower bit windows and faster data transmission.

Baud rate defines the number of signal changes per second on the communication line. In Modbus RTU, one symbol = one binary bit, so baud rate = bits per second.

Common Baud Rate Values

Baud Rate Bits per Second Typical Use Case
1200 1,200 bps Legacy devices, long cable runs with poor quality cable
2400 2,400 bps Older meters and sensors
4800 4,800 bps Moderate speed legacy devices
9600 9,600 bps Most common default — widely supported by all devices
19200 19,200 bps Standard BMS installations with moderate device counts
38400 38,400 bps Higher performance systems
57600 57,600 bps Fast networks, shorter cable runs
115200 115,200 bps Maximum practical speed for RS-485 in most installations

The default baud rate for Modbus RTU is 9600 bps, though 19200 bps is very common in BMS environments.

How Baud Rate Affects the Signal

Each bit occupies a fixed time window called the bit period, calculated as:

Bit Period = 1 / Baud Rate

At 9600 baud each bit lasts approximately 104 microseconds. At 115200 baud each bit lasts approximately 8.7 microseconds.


Modbus RTU — Bit-Level Breakdown: Single Byte at 9600 Baud, 8N1

The byte 0x41 (decimal 65) on the RS-485 wire at 9600 baud: 

Bit:     Start  D0   D1   D2   D3   D4   D5   D6   D7   Stop
Value:     0    1    0    0    0    0    0    1    0     1
µs each: 104µs per bit window
  • Start bit (1 bit, always 0): Pulls line LOW — signals receiver to begin reading
  • D0–D7 (8 bits): Binary data, transmitted LSB first. 0x41 = 01000001 → wire order: 1,0,0,0,0,0,1,0
  • Stop bit (1 bit, always 1): Returns line HIGH — marks end of byte

Total frame = 10 bits × 104µs = 1.04ms per byte


Modbus RTU — Full Message Example: FC03 Read Holding Register

Master reads 1 holding register (address 0x0000 = register 40001) from slave address 0x01.

Frame in hex — 8 bytes total: 

Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ]
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [QtyHi] [QtyLo] [CRCLo] [CRCHi]
Hex:   [ 0x01 ] [0x03 ] [0x00 ] [0x00 ] [0x00 ] [0x01 ] [0x84 ] [0x0A ]

Each byte in Modbus RTU binary (8N1, LSB first, 9600 baud): 

Byte 1 — Slave Address 0x01 (00000001):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   1   0   0   0   0   0   0   0   1

Byte 2 — Function Code 0x03 (00000011):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   1   1   0   0   0   0   0   0   1

Byte 3 — Register Address High 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   0   0   0   0   0   0   0   0   1

Byte 4 — Register Address Low 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   0   0   0   0   0   0   0   0   1

Byte 5 — Quantity High 0x00 (00000000):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   0   0   0   0   0   0   0   0   1

Byte 6 — Quantity Low 0x01 (00000001):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   1   0   0   0   0   0   0   0   1

Byte 7 — CRC Low 0x84 (10000100):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   0   0   1   0   0   0   0   1   1

Byte 8 — CRC High 0x0A (00001010):
  [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
   0   0   1   0   1   0   0   0   0   1

[S] = Start bit (always 0)   [P] = Stop bit (always 1)

What each field does: {

Effect on Cable Length

Higher baud rates require better quality cabling and are more sensitive to signal degradation over distance. As a general rule:

  • 9600 baud — reliable up to approximately 1200 metres on shielded RS-485 cable
  • 19200 baud — reliable up to approximately 600 metres
  • 115200 baud — reliable up to approximately 100 metres

Parity

File:modbus parity diagram.png
Diagram illustrating Even, Odd, and No parity bit positions within a Modbus RTU serial data frame. The parity bit is inserted between the last data bit and the stop bit.

Parity adds a single calculated bit after the 8 data bits in each Modbus RTU character frame, providing basic single-bit error detection at the byte level. CRC-16 handles error detection at the full message level.

Parity Modes

Mode Code Description
Even Parity E Parity bit set so total count of 1s in data + parity = even
Odd Parity O Parity bit set so total count of 1s in data + parity = odd
No Parity N No parity bit. Error checking relies on CRC-16 only. 2 stop bits recommended per Modbus spec.
Mark Parity M Parity bit always 1. Rarely used.
Space Parity S Parity bit always 0. Rarely used.

The Modbus RTU specification recommends Even parity as the default. However 8N1 (no parity, 1 stop bit) is the de facto standard for most BMS devices in practice.


Modbus RTU — Bit-Level Breakdown: Parity Bit Calculation

Example byte: 0x31 = binary 00110001 Count of 1-bits in data = 3

Even Parity (8E1) — 3 is odd, so parity bit = 1 to reach even total (3+1=4): 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1   0   0   0   1   1   0   0    1     1

Odd Parity (8O1) — 3 is already odd, so parity bit = 0 to keep total odd (3+0=3): 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1   0   0   0   1   1   0   0    0     1

No Parity (8N1) — no parity bit, one stop bit only: 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
Value:  0    1   0   0   0   1   1   0   0    1

No Parity (8N2) — no parity bit, two stop bits to maintain 11-bit frame: 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P1] [P2]
Value:  0    1   0   0   0   1   1   0   0    1    1

[S] = Start bit [Par] = Parity bit [P] = Stop bit


Modbus RTU — Full Message Example: FC03 Request with Even Parity (8E1)

Same request as the Baud Rate example — slave 0x01, FC03, register 0x0000, quantity 0x0001, CRC 0x840A — shown with Even parity applied to every byte.

Parity rule: count the 1s in D0–D7. If count is odd → parity bit = 1. If count is even → parity bit = 0. 

Byte 1 — Slave 0x01 (00000001) — one 1-bit → parity = 1:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    1   0   0   0   0   0   0   0    1     1

Byte 2 — FC 0x03 (00000011) — two 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    1   1   0   0   0   0   0   0    0     1

Byte 3 — RegHi 0x00 (00000000) — zero 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   0   0   0   0   0   0   0    0     1

Byte 4 — RegLo 0x00 (00000000) — zero 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   0   0   0   0   0   0   0    0     1

Byte 5 — QtyHi 0x00 (00000000) — zero 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   0   0   0   0   0   0   0    0     1

Byte 6 — QtyLo 0x01 (00000001) — one 1-bit → parity = 1:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    1   0   0   0   0   0   0   0    1     1

Byte 7 — CRCLo 0x84 (10000100) — two 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   0   1   0   0   0   0   1    0     1

Byte 8 — CRCHi 0x0A (00001010) — two 1-bits → parity = 0:
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
   0    0   1   0   1   0   0   0   0    0     1

8E1 framing = 11 bits per byte (1 start + 8 data + 1 parity + 1 stop) 8 bytes × 11 bits = 88 bits → at 9600 baud = 9.17ms to transmit the full request

The parity bit is recalculated independently for each byte — it is not a fixed value across the frame.

Parity Limitation

Parity can only detect an odd number of bit errors. If two bits flip simultaneously the parity check still passes even though the data is corrupted. This is why Modbus RTU also uses CRC-16 at the message level — the two mechanisms complement each other.

Data Bits

File:modbus databits diagram.png
Data bit positions D0–D7 within a Modbus RTU character frame. Data bits carry the actual payload and are transmitted LSB first.

Data bits refers to the number of bits carrying actual payload within each Modbus RTU character frame. This is always 8 in Modbus RTU. 8 bits = 1 byte = values 0–255 per frame. For values larger than 255, Modbus RTU uses two consecutive bytes (one 16-bit register) or four bytes (two registers for 32-bit floating point values).


Modbus RTU — Bit-Level Breakdown: Data Bit Weighting

Example byte: 0xB4 = decimal 180 = binary 10110100

Modbus RTU transmits data bits LSB first (D0 transmitted first, D7 last): 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
Value:  0    0   0   1   0   1   1   0   1    1

{


Modbus RTU — Full Message Example: FC03 Slave Response with Register Decoding

Slave 0x01 responds to the FC03 request. Register 40001 holds value 0x0190 (decimal 400), representing a supply air temperature of 40.0°C with a scale factor of ÷10.

Response frame in hex — 7 bytes total: 

Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ]
Field: [Slave ] [ FC  ] [ByteCt] [DatHi] [DatLo] [CRCLo] [CRCHi]
Hex:   [ 0x01 ] [0x03 ] [ 0x02 ] [0x01 ] [0x90 ] [0xF8 ] [0x4B ]

Critical bytes expanded in Modbus RTU binary (8N1, LSB first): 

Byte 3 — Byte Count 0x02 (00000010):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
   0    0   1   0   0   0   0   0   0    1
  D1 = 2¹ = 2 → 2 data bytes follow (one 16-bit register) ✓

Byte 4 — Data High Byte 0x01 (00000001):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
   0    1   0   0   0   0   0   0   0    1
  D0 = 1 → high byte value = 1

Byte 5 — Data Low Byte 0x90 (10010000):
  [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
   0    0   0   0   0   1   0   0   1    1
  D4 = 16, D7 = 128 → 16+128 = 144 = 0x90

Reconstructing the 16-bit register value (Big Endian — high byte first): 

High byte:  0x01 × 256  =  256
Low byte:   0x90        =  144
                          ─────
Register value:            400  =  0x0190

Applied scale factor ÷10:  400 ÷ 10  =  40.0°C

Modbus RTU always sends the high byte of a 16-bit register before the low byte. This is Big Endian byte order. Some devices deviate from this — always check the device register map.

Stop Bits

File:modbus stopbits diagram.png
Diagram comparing 1 stop bit vs 2 stop bits in a Modbus RTU character frame. Stop bits return the RS-485 line to idle HIGH after each transmitted byte.

Stop bits return the RS-485 line to the idle HIGH state after each Modbus RTU character frame. The receiver requires this idle period to correctly detect the falling edge of the next start bit.

Stop Bit Configurations

Config Stop Bits Parity Total Bits per Frame Notes
8N1 1 None 10 Most common Modbus RTU configuration in BMS
8E1 1 Even 11 Modbus RTU spec default — even parity + 1 stop
8O1 1 Odd 11 Odd parity + 1 stop
8N2 2 None 11 No parity, 2 stops — maintains 11-bit frame on noisy lines


Modbus RTU — Bit-Level Breakdown: Stop Bit Comparison

Example byte: 0x55 = binary 01010101 — four 1-bits (even count)

8N1 — No Parity, 1 Stop Bit (10 bits total): 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P]
Value:  0    1   0   1   0   1   0   1   0    1
        ←————————————— 10 bits ——————————————→

8E1 — Even Parity, 1 Stop Bit (11 bits total): Four 1-bits in data = even count → parity bit = 0 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [Par] [P]
Value:  0    1   0   1   0   1   0   1   0    0     1
        ←—————————————— 11 bits ———————————————→

8N2 — No Parity, 2 Stop Bits (11 bits total): 

Bit:   [S]  D0  D1  D2  D3  D4  D5  D6  D7  [P1] [P2]
Value:  0    1   0   1   0   1   0   1   0    1    1
        ←—————————————— 11 bits ———————————————→

If the line goes LOW before the stop bit period ends, the receiver flags a framing error and discards the byte. The resulting CRC mismatch causes the master to timeout with no response.


Modbus RTU — Full Message Example: FC06 Write Single Register

Master writes value 0x0064 (decimal 100 = setpoint 10.0°C at scale ÷10) to register 40002 (address 0x0001) on slave 0x01.

Request frame in hex — 8 bytes: 

Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ]
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [ValHi] [ValLo] [CRCLo] [CRCHi]
Hex:   [ 0x01 ] [0x06 ] [0x00 ] [0x01 ] [0x00 ] [0x64 ] [0x49 ] [0xA4 ]

Full frame in Modbus RTU binary, 8N1 (LSB first): 

           [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
Byte 1 0x01: 0  1   0   0   0   0   0   0   0   1   ← Slave address
Byte 2 0x06: 0  0   1   1   0   0   0   0   0   1   ← Write Single Register
Byte 3 0x00: 0  0   0   0   0   0   0   0   0   1   ← Register address high
Byte 4 0x01: 0  1   0   0   0   0   0   0   0   1   ← Register address low (reg 40002)
Byte 5 0x00: 0  0   0   0   0   0   0   0   0   1   ← Value high byte
Byte 6 0x64: 0  0   0   1   0   0   1   1   0   1   ← Value low byte (100 decimal)
Byte 7 0x49: 0  1   0   0   1   0   0   1   0   1   ← CRC low
Byte 8 0xA4: 0  0   0   1   0   0   1   0   1   1   ← CRC high

On a successful FC06 write the slave echoes the entire 8-byte request frame back unchanged as its response. If the stop bit on any byte is corrupted, that byte is discarded as a framing error, the CRC check fails, and the master receives no response.

Transmission time at 9600 baud, 8N1: 8 bytes × 10 bits × 104µs = 8.32ms

Flow Control

File:modbus flowcontrol diagram.png
RS-485 RTS direction switching during a Modbus RTU request/response cycle. The master asserts DE HIGH to transmit, then releases the bus before the slave responds.

Flow control in Modbus RTU on RS-485 is almost always set to None in software. The physical RS-485 half-duplex bus requires direction switching between transmit and receive, but this is handled by the hardware driver enable (DE) pin on the RS-485 transceiver, not by a software flow control protocol.

Flow Control Types

Type Method Compatible with Modbus RTU
None — ✓ Standard for RS-485 Modbus RTU
Hardware RTS/CTS Physical signal lines Only on RS-232 point-to-point connections
Software XON/XOFF In-band bytes 0x11 / 0x13 ✗ Incompatible — Modbus RTU is a binary protocol
RTS as DE toggle RTS drives RS-485 DE pin ✓ Used by USB-RS485 adapters for direction switching


Modbus RTU — Bit-Level Breakdown: RS-485 Half-Duplex Direction Control

In Modbus RTU on RS-485, the driver enable (DE) signal controls which device owns the bus. Only one device may drive the bus at any time. 

              MASTER TRANSMITTING              MASTER LISTENING
DE (Master):  ________________________
             |                        |________________________________
             ^ DE asserted HIGH        ^ DE released LOW

TX (Master):  [ Start bits of frame...data bytes...CRC ]
             |←————————————————————————————————————————→|

                                       ↑
                               3.5 character-time
                               silent gap (~3.6ms at 9600 baud)
                               marks end of Modbus RTU frame

DE (Slave):                                        ______________________
                                                  |
                                                  ^ Slave asserts its DE HIGH

RX (Master):                                      [ Slave response frame ]
  • DE HIGH = RS-485 driver active, device is transmitting
  • DE LOW = RS-485 driver disabled, device is listening
  • The 3.5 character-time silent gap is how Modbus RTU detects frame boundaries — there is no delimiter byte
  • If DE is not released fast enough, the master's driver will collide with the slave's response on the bus


Modbus RTU — Full Message Example: FC03 Read 2 Registers — Complete Request/Response Cycle

Master reads 2 holding registers from slave 0x02, starting at address 0x0010 (registers 40017 and 40018). These could represent, for example, active power high and low bytes from an energy meter.

Master request frame — 8 bytes: 

Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ]
Field: [Slave ] [ FC  ] [RegHi] [RegLo] [QtyHi] [QtyLo] [CRCLo] [CRCHi]
Hex:   [ 0x02 ] [0x03 ] [0x00 ] [0x10 ] [0x00 ] [0x02 ] [0xC4 ] [0x38 ]

Slave response frame — 9 bytes: 

Byte:  [  1  ] [  2  ] [  3  ] [  4  ] [  5  ] [  6  ] [  7  ] [  8  ] [  9  ]
Field: [Slave ] [ FC  ] [ByteCt] [R1Hi ] [R1Lo ] [R2Hi ] [R2Lo ] [CRCLo] [CRCHi]
Hex:   [ 0x02 ] [0x03 ] [ 0x04 ] [0x00 ] [0xC8 ] [0x01 ] [0x2C ] [0x77 ] [0xDF ]

Both frames in Modbus RTU binary, 8N1 (LSB first): 

REQUEST:
           [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
0x02 Addr:  0   0   1   0   0   0   0   0   0   1
0x03 FC:    0   1   1   0   0   0   0   0   0   1
0x00 RegHi: 0   0   0   0   0   0   0   0   0   1
0x10 RegLo: 0   0   0   0   0   1   0   0   0   1
0x00 QtyHi: 0   0   0   0   0   0   0   0   0   1
0x02 QtyLo: 0   0   1   0   0   0   0   0   0   1
0xC4 CRCLo: 0   0   0   1   0   0   0   1   1   1
0x38 CRCHi: 0   0   0   0   1   1   1   0   0   1

[— 3.5 char silent gap (~3.6ms at 9600 baud) — master releases bus — slave responds —]

RESPONSE:
           [S] D0  D1  D2  D3  D4  D5  D6  D7 [P]
0x02 Addr:  0   0   1   0   0   0   0   0   0   1
0x03 FC:    0   1   1   0   0   0   0   0   0   1
0x04 BytCt: 0   0   0   1   0   0   0   0   0   1
0x00 R1Hi:  0   0   0   0   0   0   0   0   0   1
0xC8 R1Lo:  0   0   0   0   1   0   0   1   1   1
0x01 R2Hi:  0   1   0   0   0   0   0   0   0   1
0x2C R2Lo:  0   0   1   1   0   1   0   0   0   1
0x77 CRCLo: 0   1   1   1   0   1   1   1   0   1
0xDF CRCHi: 0   1   1   1   1   1   0   1   1   1

Decoding the two register values from the response (Big Endian — high byte first): 

Register 1 (40017):
  High byte 0x00 = 0 × 256  =   0
  Low  byte 0xC8 =           = 200
  Value = 0 + 200            = 200

Register 2 (40018):
  High byte 0x01 = 1 × 256  = 256
  Low  byte 0x2C =           =  44
  Value = 256 + 44           = 300

If these were active power registers with a scale factor of ÷10: Register 1 = 20.0 kW, Register 2 = 30.0 kW

Transmission times at 9600 baud, 8N1: 

Request:    8 bytes × 10 bits × 104µs  =   8.32ms
Silent gap:                             ≈   3.60ms
Response:   9 bytes × 10 bits × 104µs  =   9.36ms
                                           ───────
Total cycle time:                       ≈  21.28ms

The silent gap between the master frame and slave response is critical. If the master releases its driver too late it will collide with the slave's response. If the slave responds before the gap completes, the master will misinterpret the response as a continuation of its own transmission.

Data Model

Modbus organises data into four distinct object types, each with a defined address space. The master accesses these objects using function codes.

Coils

Coils are single-bit read/write values. They represent binary output states such as a relay, a digital output, or an on/off command. The address range is 1–9999 (using 1-based Modbus convention) or 0x0000–0xFFFF (using the 0-based PDU addressing).

Examples in BMS: fan on/off command, valve open/close output, alarm reset.

Discrete Inputs

Discrete inputs are single-bit read-only values. They represent binary input states such as a digital sensor, a status contact, or a switch position. Address range: 10001–19999.

Examples in BMS: door open sensor, high temperature alarm contact, filter dirty status.

Holding Registers

Holding registers are 16-bit read/write registers. They are the most commonly used data type in Modbus and can hold values such as setpoints, configurations, and output values. Address range: 40001–49999.

A single holding register holds values from 0 to 65535 (unsigned) or -32768 to 32767 (signed). For larger values such as floating point temperatures or energy readings, two consecutive registers are used together to form a 32-bit value.

Examples in BMS: temperature setpoint, VFD speed reference, valve position command.

Input Registers

Input registers are 16-bit read-only registers. They represent measured or computed values provided by the slave device. Address range: 30001–39999.

Examples in BMS: supply air temperature, room CO₂ concentration, energy meter active power reading.

Function Codes

Function codes tell the slave device what action to perform. They are carried in the second byte of every Modbus RTU frame.

Read Functions

Function Code Hex Name Reads
01 0x01 Read Coils Coils (1-bit, read/write)
02 0x02 Read Discrete Inputs Discrete Inputs (1-bit, read-only)
03 0x03 Read Holding Registers Holding Registers (16-bit, read/write)
04 0x04 Read Input Registers Input Registers (16-bit, read-only)

Write Functions

Function Code Hex Name Writes
05 0x05 Write Single Coil Single coil ON (0xFF00) or OFF (0x0000)
06 0x06 Write Single Register Single holding register
15 0x0F Write Multiple Coils Multiple coils
16 0x10 Write Multiple Registers Multiple holding registers

Diagnostic Functions

Function Code Hex Name Purpose
07 0x07 Read Exception Status Returns device error status byte
08 0x08 Diagnostics Various sub-functions for testing comms
11 0x0B Get Comm Event Counter Returns count of successful messages
17 0x11 Report Server ID Returns device type and status

Error Handling

CRC and LRC Checking

CRC-16 (Cyclic Redundancy Check) is used in Modbus RTU. It is a 16-bit error detection value calculated from all bytes in the message excluding the CRC bytes themselves. The master calculates the CRC before sending, and the slave recalculates it upon receipt. If the values do not match, the message is discarded silently — no response is sent, and the master will timeout.

The CRC polynomial used is: 0xA001 (reflected form of CRC-16-IBM).

LRC (Longitudinal Redundancy Check) is used in Modbus ASCII only. It is calculated as the two's complement of the sum of all byte values in the message. It is simpler but less robust than CRC-16.

Exception Codes

When a slave receives a valid request but cannot fulfil it, it returns an exception response. The function code in the response has its most significant bit set to 1 (i.e. the original function code + 0x80), followed by an exception code byte.

Exception Code Hex Name Meaning
01 0x01 Illegal Function The function code is not supported by this device
02 0x02 Illegal Data Address The register address does not exist on this device
03 0x03 Illegal Data Value The value in the data field is not permitted
04 0x04 Slave Device Failure An unrecoverable error occurred in the slave
05 0x05 Acknowledge Slave accepted the request but needs more time
06 0x06 Slave Device Busy Slave is busy processing a previous request
08 0x08 Memory Parity Error Slave detected a parity error reading extended memory
10 0x0A Gateway Path Unavailable Gateway could not allocate a path (Modbus TCP)
11 0x0B Gateway Target No Response Target device on gateway failed to respond

Modbus in BMS Applications

Typical Devices

Modbus is one of the most commonly encountered protocols when integrating third-party field devices into a BMS. The following device types frequently use Modbus RTU as their primary or secondary communication interface:

  • Energy meters — active power (kW), reactive power (kVAR), energy (kWh), power factor, voltage and current readings via input registers
  • Variable Frequency Drives (VFDs) — speed reference (Hz or %), run/stop command, fault status, output frequency and current feedback
  • Chillers and heat pumps — leaving water temperature, setpoint, mode command, alarm status
  • Air Handling Units (AHUs) — supply/return air temperature, damper position, fan speed feedback
  • CO₂ and air quality sensors — CO₂ concentration (ppm), temperature, humidity
  • Heat meters — flow rate, inlet/outlet temperatures, cumulative energy
  • UPS systems — battery voltage, charge level, load percentage, alarm status
  • Generator controllers — run status, fuel level, output voltage, frequency

Wiring and Topology

Modbus RTU on RS-485 uses a daisy-chain bus topology. Devices are connected in series from the first to the last node. The two conductors of the RS-485 pair are labelled A (−) and B (+), though manufacturers often use inconsistent naming — some label them D− / D+, or even reverse the A/B convention entirely.

Key wiring rules:

  • Termination resistors of 120Ω must be fitted at both physical ends of the RS-485 bus to prevent signal reflections. Only the two end devices are terminated — never intermediate devices.
  • Bias resistors (typically 560Ω to 1kΩ) are recommended to hold the bus at a defined state when no device is transmitting, preventing false start bit detection on an idle line.
  • Maximum cable length depends on baud rate (see Baud Rate section), but 1200 metres at 9600 baud is a typical practical limit for standard twisted pair cable.
  • The maximum number of addressable slave devices is 247, though the RS-485 electrical standard supports up to 32 unit loads on a single segment without repeaters (256 with 1/8 unit load devices).
  • Shielded twisted pair (STP) cable is strongly recommended in BMS environments due to electrical noise from motors, VFDs, and other inductive loads.

Common Issues and Troubleshooting

The following are the most frequently encountered Modbus RTU communication problems in BMS installations:

No response from slave / timeout

  • Verify slave address matches the configured address on the physical device
  • Check baud rate, parity, data bits, and stop bits match on master and slave
  • Check A/B wiring polarity — reversed polarity is a very common installation error
  • Verify termination resistors are fitted at the correct endpoints only

CRC errors / corrupted data

  • Inspect cable routing — avoid running alongside power cables or VFD output cables
  • Check for missing or incorrectly placed termination resistors
  • Reduce baud rate to test if the issue is speed-related
  • Check for ground loops — ensure cable shield is grounded at one end only

Intermittent communication

  • Often caused by missing bias resistors — the bus floats to an indeterminate state when idle
  • Check for multiple termination resistors incorrectly fitted to intermediate devices
  • Investigate RTS/driver enable timing issues if using a custom RS-485 adapter

Incorrect register values

  • Confirm register addressing convention — some devices use 0-based addressing, others 1-based
  • Check byte order (endianness) for 32-bit floating point values — some devices use Big Endian, others Little Endian or mixed (byte-swapped) formats
  • Verify scaling factors — a register reading of 1234 may represent 12.34 depending on the device register map
Retrieved from "https://bmspedia.com/index.php?title=Modbus&oldid=85"