Siemens CP341 Modbus Master FC04: Register Address Mapping

Overview

The Siemens CP341 is a point-to-point (PtP) communication module for the S7-300 family that supports Modbus RTU master and slave protocols through a loadable firmware driver. One of the most common integration issues encountered when commissioning a CP341 Modbus master is the incorrect calculation of the starting register address for Function Code 04 (Read Input Registers). The CP341 reports a slave timeout, a no-response condition, or a Modbus exception 02 (Illegal Data Address) not because the slave device is defective, but because the master frame contains a data-link-layer address that the slave cannot resolve to a physical register.

This reference documents the two-layer Modbus addressing model, the FC04 PDU structure, the CP341 hardware and software prerequisites, the STEP 7 configuration flow, and the byte-level corrections required when a Modbus slave vendor specifies input registers by their application-layer number (30001-based) rather than the data-link-layer offset expected by the Siemens Modbus driver.

Modbus Addressing Model: Data Link vs Application Layer

Modbus defines two distinct address reference layers. The distinction is the single most common source of FC04 communication failures on the CP341, and the root cause of nearly every "slave timeout" report encountered during commissioning.

Application Layer Address

The application layer is the human-readable register number used in device datasheets, vendor documentation, and operator interfaces. For each Modbus function code family, the application layer uses a fixed numerical range:

When a slave vendor states that input registers are "at address 30001 to 39999" or specifies a starting register such as "32462", they are referring to the application-layer address.

Data Link Layer Address

The data link layer (PDU addressing) is the zero-based offset actually transmitted in the Modbus frame. The conversion is:

data_link_address = application_address - base_offset

Where base_offset equals:

For example, application address 32462 corresponds to data link address 32462 - 30001 = 2461.

Siemens CP341 Convention

The CP341 Modbus RTU master driver uses the data link layer offset as the DATA_ADDR parameter. When the slave documentation states "input registers 2462 to 2544", the integrator must interpret this as the data-link offset (or as application addresses 32462 to 32544, depending on the vendor's documentation convention). The Siemens driver then transmits the data link address in the Modbus PDU.

The Beijer Electronics Modbus Interface reference and the Modbus Application Protocol Specification both confirm that FC04 input registers are addressed as a contiguous block starting from a 0-based data link address. The Siemens Industry Online Support portal hosts the CP341 manual and Modbus driver documentation that describe this addressing convention in detail.

Function Code 04 Specification

Function Code 04 (Read Input Registers) reads from 1 to 125 contiguous input registers (16-bit each) in a remote device. The PDU is:

For a request to read 83 input registers starting at data link address 2462 (covering 2462 through 2544), the complete Modbus RTU frame is:

The response PDU contains the function code echoed, a byte count (2 × number of registers), and the register values in network byte order (high byte first).

Maximum Register Count

The Modbus specification limits FC04 to 125 registers per request (250 bytes of payload). Exceeding this limit causes the slave to return exception code 03 (Illegal Data Value) or to ignore the request entirely. If more than 125 registers are required, split the read into multiple FC04 transactions.

Inter-Frame Silence

Modbus RTU requires a silent interval of at least 3.5 character times between frames to mark frame boundaries. The CP341 Modbus driver handles this timing automatically; manual frame transmission via P_SND_RK (FB8) does not enforce the silence interval and may cause the slave to misinterpret concatenated frames.

CP341 Hardware and Modbus Driver Requirements

CP341 Order Numbers

The CP341 is available in three interface variants:

All three variants support the loadable Modbus RTU master and slave drivers.

Modbus Driver Order Numbers

The Modbus RTU driver is a separate licensed firmware that must be loaded into the CP341 module flash memory:

The driver is downloaded to the CP341 along with the STEP 7 hardware configuration.

STEP 7 Version

The CP341 with Modbus driver is supported in STEP 7 V5.x (Classic) with SP2 or later. It is not configured in TIA Portal via the same flow; users migrating to TIA Portal must select an ET 200SP CM PtP module (e.g., 6ES7137-6AA00-0BA0) or a current S7-1200/S7-1500 communication module with the Modbus master library.

Library

The Modbus master driver includes a function block library (typically named "MODBUS" or "MODB_341" depending on the version) that provides:

• Modbus master FB (e.g., MODB_MAST) - High-level Modbus transaction handling
• P_SND_RK (FB8) - Send raw data to CP341 (standard SIMATIC library)
• P_RCV_RK (FB7) - Receive raw data from CP341 (standard SIMATIC library)

The P_SND_RK and P_RCV_RK blocks are required for raw frame transmission when the integrator constructs the Modbus PDU manually (e.g., to integrate a non-standard slave or to implement a custom diagnostic function).

STEP 7 Project Configuration

Hardware Configuration

1. Insert the CP341 in the S7-300 rack configuration at the desired slot.
2. Open the CP341 properties dialog.
3. Select the Parameter tab.
4. Under Loadable Driver, select Modbus Master (or Modbus Slave if implementing slave mode).
5. Configure the interface parameters: baud rate, parity, data bits, stop bits.
6. Save and download the hardware configuration to the PLC.

The Modbus driver is transferred to the CP341 flash memory during the download. A restart of the CP341 may be required to activate the new driver.

Communication Parameters

The CP341 must match the slave's communication parameters exactly. Typical Modbus RTU settings:

Function Block Installation

1. Open the SIMATIC Manager.
2. Navigate to Options > Install Library (or insert the library from the Modbus driver installation media).
3. Open the library and copy the required FBs to the project's master data library or directly to the S7 program blocks container.
4. Instantiate the FBs in OB1 with appropriate instance DBs.

Building the Modbus Request Frame

When using the high-level Modbus master FB, the integrator provides the slave address, function code, starting address, and register count. The FB internally constructs the request frame, appends the CRC-16, transmits the frame, waits for the response, validates the CRC, and returns the data.

High-Level Modbus Master FB Call

CALL "MODB_MAST"
  REQ       := M0.0          // Trigger request (rising edge)
  ID        := 2             // Slave address
  FUNC      := 4             // Function code 04 (Read Input Registers)
  DATA_ADDR := 2462          // Data link start address
  DATA_LEN  := 83            // Number of registers to read
  DATA_PTR  := P#DB42.DBX0.0 BYTE 166  // Receive data buffer (2 bytes per register)
  DONE      := M10.0         // Request complete (no error)
  ERROR     := M10.1         // Error occurred
  STATUS    := MW12          // Error/status code

The DATA_PTR parameter must point to a data area large enough to hold the response: 2 bytes per register for FC04, so 83 registers require 166 bytes of buffer space.

Manual Frame Construction (Low-Level)

If constructing the request frame manually using P_SND_RK and P_RCV_RK, the integrator must build the Modbus PDU in a data block and calculate the CRC-16 checksum manually. The CP341 transmits the raw bytes; it does not append Modbus CRC automatically in this mode.

The correct data area layout for a manual FC04 request (without CRC) is:

Sample STL Code for Modbus Master Request

The following STL excerpts demonstrate the common mistake and the corrected approach for a manual FC04 request frame construction. The scenario is a Modbus slave at address 2 with input registers at data link offset 2462 through 2544 (83 registers).

Incorrect Approach (Common Mistake)

L B#16#2
T DB42.DBB0    // Slave address = 2
L B#16#4
T DB42.DBB1    // Function code = 4
L W#16#2462
T DB42.DBW2    // Start address = 0x2462 (9282 decimal) - WRONG
L W#16#82
T DB42.DBW4    // Quantity = 0x82 (130 decimal) - WRONG
L W#16#6
T DB40.DBW10   // Length = 6 bytes

This attempt fails for two reasons:

1. W#16#2462 interprets the value as hexadecimal, producing 9282 decimal on the wire. The slave expects 2462 decimal = 0x099E. The slave will respond with exception 02 (Illegal Data Address) or simply ignore the request.
2. W#16#82 is 130 decimal, which exceeds the FC04 maximum of 125 registers per request. Even if the address were correct, the slave would respond with exception 03 (Illegal Data Value). The actual register count is 2544 - 2462 + 1 = 83.

Corrected Approach (Decimal Load)

L B#16#2
T DB42.DBB0    // Slave address = 2
L B#16#4
T DB42.DBB1    // Function code = 4
L 2462
T DB42.DBW2    // Start address = 2462 decimal (0x099E) - CORRECT
L 83
T DB42.DBW4    // Quantity = 83 decimal (0x0053) - CORRECT
// CRC calculation follows here (see CRC-16 section)

The decimal value 2462 is loaded as an integer; STEP 7 stores it as 0x099E in the word, which is the correct data link address for FC04.

Alternative Hex Notation

If hexadecimal notation is preferred for code clarity, the hex digits must represent the actual numeric value, not the decimal digits re-typed as hex:

L W#16#099E
T DB42.DBW2    // Start address = 0x099E = 2462 decimal - CORRECT
L W#16#0053
T DB42.DBW4    // Quantity = 0x0053 = 83 decimal - CORRECT

The key distinction: W#16# followed by the decimal value written in hex (e.g., W#16#99E for 2462) versus L 2462 (integer load). Both produce the same bit pattern if the hex representation is correct. The error W#16#2462 is a hex interpretation of the decimal digits "2462", which yields 9282, not 2462.

CRC-16 Calculation for Modbus RTU

Modbus RTU frames require a CRC-16 checksum using the polynomial 0xA001 (reflected representation of 0x8005). The CRC is calculated over the entire PDU (slave address through last data byte) and appended low-byte first.

Algorithm Summary

1. Initialize CRC register to 0xFFFF.
2. For each byte in the PDU: XOR the byte into the CRC low byte.
3. Shift the CRC right 8 times; after each shift, if the LSB shifted out is 1, XOR the CRC with 0xA001.
4. After processing all bytes, the CRC register contains the checksum.
5. Append CRC low byte, then CRC high byte to the frame.

STL Implementation Pattern

// CRC-16 calculation in STL (call as FB for reuse)
// Input: DB42 starting at DBB0, length 6
// Output: CRC appended at DB42.DBW6

      L    0xFFFF
      T    LW20              // CRC accumulator

NEXT: L    LW20
      L    DB42.DBB[LW22]   // Load current byte (index in LW22)
      XOW                    // XOR byte into CRC low byte
      T    LW20

      L    8                 // 8 shifts per byte
      T    LW24

SHIFT: L    LW20
      SRW  1                 // Shift right with carry
      T    LW20
      JC   XOR_POLY          // If carry set, XOR with polynomial
      JU   CONT

XOR_POLY:
      L    LW20
      L    W#16#A001
      XOW
      T    LW20

CONT: L    LW24
      LOOP SHIFT             // Decrement and loop if > 0

      L    LW22
      +    1
      T    LW22              // Increment byte index
      L    LW22
      L    6                 // PDU length (slave + FC + addr + count)
      <I                      // If index < 6, continue
      JC   NEXT

      L    LW20
      T    DB42.DBW6          // Append CRC to frame

Common Addressing Mistakes and Corrections

CP341 Modbus Error Codes and Diagnostics

The CP341 Modbus driver reports status information in the STATUS output of the master FB. Common status codes include:

Modbus Exception Codes

When the slave returns an exception, the CP341 status reflects the exception code in the low byte:

Diagnostic Procedure

1. Check the CP341 diagnostic buffer in STEP 7 (PLC > Module Information > Diagnostic Buffer).
2. Verify the STATUS output of the Modbus master FB using a VAT (Variable Table).
3. Use a Modbus RTU sniffer (serial port tap with terminal software such as Docklight, Modbus Poll, or a protocol analyzer) to observe the raw frames on the bus.
4. Test with a known-good Modbus slave simulator (e.g., Modbus Poll in slave mode, or Diagslave) to isolate master-side issues from slave-side issues.
5. Verify the slave's actual register map by reading a known register (e.g., start at address 0) and incrementing until the slave returns an exception 02, which marks the end of the valid address space.

Verification, Testing, and Migration Paths

Step-by-Step Verification

1. Hardware check: Verify wiring polarity, termination resistors (for RS485), and shield grounding at one end only.
2. Communication parameters: Confirm baud rate, parity, and stop bits match the slave exactly.
3. Slave address: Verify the slave address in the CP341 request matches the physical slave configuration (DIP switches or software setting on the slave).
4. Start address: Confirm the data link layer offset is correct: subtract 30001 from the application-layer address stated in the slave documentation.
5. Register count: Verify the count is ≤125 and does not exceed the slave's actual register count.
6. Frame integrity: Use a serial analyzer to confirm the CRC is correct and the frame is well-formed (slave address, FC, address, count, CRC).
7. Response handling: Verify the receive DB is large enough (2 bytes per register for FC04) and the data is interpreted correctly (high byte first per Modbus byte order).

Test with Modbus Simulator

Before connecting to the production slave, test the CP341 master with a Modbus RTU slave simulator running on a PC with a serial port or USB-to-RS485 converter. This isolates the master configuration from slave-specific issues and confirms the addressing logic before field deployment.

Online Monitoring

In STEP 7, use a VAT to monitor in real time:

• The request DB contents (DB42 in the examples above)
• The Modbus master FB status outputs (DONE, ERROR, STATUS)
• The receive data area (first few words to confirm valid data)

This provides immediate visibility into the communication state during commissioning and troubleshooting.

Migration to Current Siemens Platforms

The CP341 with STEP 7 V5.x is a legacy platform. For new installations, consider:

The TIA Portal Modbus master library uses the same data link layer addressing convention as the CP341, so the addressing logic developed for the CP341 transfers directly to current platforms.

Frequently Asked Questions