763  Modbus Frame Structure

Understanding Modbus RTU, TCP, and ASCII frame formats with CRC/LRC checksums

animation
modbus
industrial
protocols

763.1 Learning Objectives

By the end of this chapter, you will be able to:

  1. Identify the structure of Modbus RTU, TCP, and ASCII frames
  2. Understand the role of CRC-16 and LRC checksums in error detection
  3. Recognize the differences between frame formats for each Modbus mode
  4. Build and interpret Modbus request/response frames at the byte level

763.2 Introduction

Modbus communication relies on well-defined frame structures that encapsulate commands and data. Understanding these frame formats is essential for debugging industrial communication issues, implementing protocol analyzers, or developing custom Modbus applications. This chapter provides an interactive visualization of how Modbus frames are constructed across RTU, TCP, and ASCII modes.

Think of a frame like an envelope for a letter:

  • Address: Who the message is for (slave device)
  • Content: The actual command or data (function code + data)
  • Checksum: A verification code to detect errors (like a wax seal)

Each Modbus mode wraps the same “letter” in slightly different “envelopes”!

763.3 Frame Structure Visualizer

Configure the parameters below to see how Modbus frames are constructed for different modes and operations.

763.4 Frame Visualization

763.5 Request Processing Flow

%% fig-alt: Process flow diagram showing Modbus master request processing from command to response handling
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#ECF0F1'}}}%%
flowchart TD
    START([Master Application]) --> CMD[Build Modbus Command]
    CMD --> FC{Function<br/>Code Type}

    FC -->|01-04| READ[Read Request<br/>Address + Quantity]
    FC -->|05-06| WRITE_SINGLE[Write Single<br/>Address + Value]
    FC -->|15-16| WRITE_MULTI[Write Multiple<br/>Address + Qty + Data]

    READ --> FRAME[Build ADU Frame]
    WRITE_SINGLE --> FRAME
    WRITE_MULTI --> FRAME

    FRAME --> MODE{Modbus<br/>Mode?}

    MODE -->|RTU| CRC[Add CRC-16]
    MODE -->|ASCII| LRC[Add LRC + Delimiters]
    MODE -->|TCP| MBAP[Add MBAP Header]

    CRC --> TX[Transmit to Slave]
    LRC --> TX
    MBAP --> TX

    TX --> WAIT{Response<br/>Received?}

    WAIT -->|Timeout| RETRY{Retries<br/>Left?}
    WAIT -->|Yes| VERIFY{Valid<br/>Checksum?}

    RETRY -->|Yes| TX
    RETRY -->|No| ERROR([Communication Error])

    VERIFY -->|No| ERROR
    VERIFY -->|Yes| CHECK{Exception<br/>Response?}

    CHECK -->|Yes| HANDLE_EX[Handle Exception Code]
    CHECK -->|No| PARSE[Parse Response Data]

    PARSE --> UPDATE([Update Application])
    HANDLE_EX --> UPDATE

    style START fill:#2C3E50,color:#fff
    style UPDATE fill:#16A085,color:#fff
    style ERROR fill:#E74C3C,color:#fff
    style PARSE fill:#27AE60,color:#fff

763.6 Knowledge Check

NoteQuick Quiz: Frame Structure

Question 1: In Modbus RTU, what is the byte order for the CRC-16 checksum?

  1. High byte first, then low byte
  2. Low byte first, then high byte
  3. Only one byte is sent
  4. CRC is not used in RTU

b) Low byte first, then high byte - Modbus RTU uses little-endian byte order for the CRC-16 checksum. This is opposite to the data values which are big-endian (MSB first).

NoteQuick Quiz: TCP vs RTU

Question 2: Why doesn’t Modbus TCP include a CRC checksum in its frames?

  1. TCP is faster and doesn’t need error checking
  2. TCP/IP already provides reliable, error-checked delivery
  3. CRC calculation is too slow for Ethernet
  4. Modbus TCP uses LRC instead

b) TCP/IP already provides reliable, error-checked delivery - TCP/IP handles error detection and retransmission at the transport layer, making an application-level CRC redundant. This reduces frame overhead and processing time.

763.7 Summary

  • Modbus RTU frames contain: Slave Address + Function Code + Data + CRC-16 (16-bit)
  • Modbus TCP frames contain: MBAP Header (7 bytes) + Function Code + Data (no CRC needed)
  • Modbus ASCII frames contain: Start delimiter : + Hex ASCII data + LRC + CR LF
  • CRC-16 uses polynomial 0xA001 with initial value 0xFFFF (little-endian output)
  • LRC is a simple two’s complement checksum for ASCII mode
  • Exception responses set bit 7 of the function code (FC | 0x80)

763.8 What’s Next

Continue exploring Modbus with these related topics: