Resolving Siemens CP341 MODBUS RTU Master Error 0F05

Overview of CP341 MODBUS Master Error 0F05

The Siemens SIMATIC S7-300 CP341 point-to-point communication processor returns status code W#16#0F05 from the SEND block (FB 8 P_SND_RK on STEP 7 V5.x or SFB 60 SEND_PTP on TIA Portal) when MODBUS RTU Master communication fails. The 16-bit STATUS word is structured as 0F (event class = MODBUS protocol-specific error) and 05 (event number = no valid response received within the configured monitoring time). This code indicates the CP341 transmitted a request frame onto the bus but did not receive a syntactically valid MODBUS response before its monitoring window expired, or the response it did receive failed CRC, framing, or address checks.

This error is specific to the loadable MODBUS Master RTU driver operation and requires the hardware dongle 6ES7870-1AB01-0AA0 to be installed in the CP341 rear socket. Without the dongle, the Master driver cannot be loaded to the module and the CP will not execute MODBUS Master requests — every SEND call returns a 0900h hardware/license error rather than 0F05, which is a useful disambiguation in the diagnostic buffer.

The troubleshooting approach must follow a strict hierarchy: physical layer (cable, termination, bias, shield) → slave configuration (baud rate, parity, stop bits, address, function code support) → CP341 hardware configuration (frame, monitoring time, protocol variant, inter-frame delay) → application data block (LEN, request frame layout, LADDR) → driver/firmware version and dongle integrity. The 0F05 error in 95% of field cases is a slave non-response caused by LEN parameter mismatch, monitoring time too short for slow slaves, or incorrect frame parameters between CP341 and slave.

CP341 Hardware Variants and Required Dongle

The CP341 family comprises three hardware variants that differ only in physical interface and integrated license options:

For MODBUS RTU Master on -AH02 or -BH02, insert the dongle 6ES7870-1AB01-0AA0 into the CP341 rear connector labelled "MODBUS Master" before commissioning. The dongle contains an EEPROM that the firmware checks at startup; if missing or corrupt, the driver load fails and the CP reports protocol startup errors in the diagnostic buffer (typically event ID 0x0900).

Verify the dongle physically: power down the S7-300 station, remove the CP341 from the rack, look at the rear of the PCB, and confirm the small 8-pin EEPROM module is firmly seated in the socket with the notch aligned. Re-seat it if the error is intermittent after thermal cycling.

Status Word Format: Decoding the CP341 Error

The CP341 STATUS output from SFB 60 / FB 8 is a 16-bit word with this bit-field structure:

For STATUS = W#16#0F05:

• Event class = 0F = MODBUS protocol-specific error
• Event number = 05 = No valid response received within monitoring time (timeout, frame error, or CRC failure on response)

Event class 0F is reserved by Siemens for protocol-stack errors that cannot be categorized as general send/receive faults (event classes 01-0E). Sub-codes within 0Fxx indicate specific failure modes of the MODBUS state machine: timeout (05), CRC error in response (0E), exception response (14), and others depending on the driver version.

Root Cause Analysis: Why 0F05 Appears

Based on the symptom reported in the field report and on Siemens documentation of the CP341 MODBUS Master state machine, 0F05 means the CP341 issued a valid MODBUS request frame, transmitted it on the bus, and either received no response or a corrupted response within the configured monitoring window. Common causes in order of frequency observed in the field:

1. LEN parameter mismatch: The SEND block LEN is set larger than the actual request body. The user in the source has LEN = 16#20 (32 decimal), while a valid FC 03/04 read of 2 registers requires only 6 bytes of request data (slave + FC + start_addr_hi + start_addr_lo + quantity_hi + quantity_lo). The CP341 attempts to send 32 bytes of data, the slave rejects or ignores it, and the CP times out waiting for a response.
2. Monitoring time too short: The CP341 default is 200 ms. Slow MODBUS slaves (some industrial sensors, multi-register reads over slow serial links) require 500 ms to 2 s. With a 200 ms window the response arrives just after the CP341 declares a timeout.
3. Slave not responding: Wrong slave address, wrong function code, wrong register address, or slave in error/initialization state. The slave will not send an exception response if the request is malformed at the transport layer — it will simply not reply.
4. Frame parameter mismatch: Baud rate, parity, or stop bit settings differ between CP341 and slave. The slave's UART either desynchronizes on the first byte and drops the rest, or fails the frame check and ignores the request.
5. Bus contention or termination: RS-485 bus not terminated, bias resistors missing, multiple drivers enabled simultaneously, or a faulty transceiver on the slave.
6. Dongle not detected: MODBUS Master dongle loose, wrong revision, or EEPROM corruption. Without dongle recognition, the driver load fails and 0900h is reported — but a partial dongle fault can cause the driver to load and then fail on the first transaction with a 0F05-class error.
7. Driver/firmware mismatch: Old MODBUS Master driver on the CP doesn't support the slave's MODBUS extensions (e.g., FC 43/14 for MEI type transactions), or driver V2.x and CP341 firmware V1.0 incompatibility.

Prerequisites for CP341 MODBUS Master Setup

Before commissioning, verify the following are in place:

• STEP 7 V5.5 SP4+ (or TIA Portal V13 SP1+ with CM PtP / CP PtP add-on) installed with the CP PtP Param tool
• CP341 module with the correct interface variant for your physical medium (RS-485 strongly recommended for industrial MODBUS RTU networks)
• MODBUS Master RTU dongle 6ES7870-1AB01-0AA0 installed in the rear socket of the CP341
• MODBUS Master RTU driver version V3.1.0 or higher loaded to the CP (downloadable from Siemens support, entry ID 61447613)
• Slave device documentation with complete register map, supported function codes, default frame parameters, and configuration procedure
• Shielded twisted-pair cable with proper termination (120 Ω at each end of the RS-485 bus)
• Bias network (typically 680 Ω pull-up on D1/A and 680 Ω pull-down on D0/B) at exactly one point on the bus

Reference: Siemens CP341 Point-to-Point Communication Manual (entry ID 1117396)

Step-by-Step Diagnostic Procedure

1. Read STATUS at the SEND block output: Monitor DB40.DBW12 (or the relevant instance DB output) online. Confirm the value is exactly W#16#0F05 and not a similar code such as 0E05, 0F04, 0F0E (CRC error), 0F14 (MODBUS exception), 1F05 (send buffer overflow), or 0900h (dongle missing). Each has a different root cause.
2. Check LEN parameter: DB40.DBW10 must equal the number of bytes in the request frame body, NOT the maximum buffer size. For FC 03/04 read of 2 registers: LEN = 6 (slave + FC + addr_hi + addr_lo + count_hi + count_lo). The CP341 driver appends the CRC-16 automatically. The user in the source has LEN = 16#20 (32 decimal), which is the dominant cause of 0F05 on first call.
3. Verify LADDR: DB40.DBW16 and DB41.DBW16 must both contain the logical base address of the CP341 from HW Config. The user has 256 (W#16#100), which is correct if the CP341 is configured at slot with logical address 256. A mismatch with HW Config causes 0900h or 8100h errors rather than 0F05, but a stale LADDR after a hardware reconfiguration is a common source of confusion.
4. Inspect the request frame in DB42: Online view DB42 starting at offset 0:

   DB42.DBB0 = 16#01   // Slave address
   DB42.DBB1 = 16#03   // Function code (Read Holding Registers)
   DB42.DBB2 = 16#00   // Start address high byte
   DB42.DBB3 = 16#8A   // Start address low byte (= 138 decimal)
   DB42.DBB4 = 16#00   // Quantity high byte
   DB42.DBB5 = 16#02   // Quantity low byte (= 2 registers, 4 bytes of data)

   This is the user-side request body. The CP341 driver appends CRC-16 (Modbus polynomial 0xA001, low byte first) automatically. The total on-wire frame is 8 bytes.
5. Increase monitoring time: Open CP PtP Param → Protocol → MODBUS Master → Monitoring Time. Default is 200 ms. Increase to 1000 ms for initial testing. If the slave starts responding, tune down to the minimum value that still produces zero error rate under worst-case bus loading.
6. Verify slave address on the bus: Use a MODBUS master simulator (MODBUS Poll, ModScan, or a custom Python script with pymodbus) on a laptop with a USB-RS485 converter to confirm the slave responds at address 01 with 9600/8/N/2. If the simulator gets a valid response and the CP341 does not, the issue is CP-side or bus-physical.
7. Check RS-485 bus termination: 120 Ω resistor across the A/B terminals at each end of the bus. Many slaves have internal termination that must be enabled via DIP switch or jumper; the CP341 itself does not provide internal RS-485 termination.
8. Verify frame parameters: Both CP341 and slave must match exactly: 9600 baud, 8 data bits, NO parity, 2 stop bits. Mismatched parity or stop bits cause the slave to ignore the frame without sending an error response, producing 0F05 timeout. Use a serial line analyzer or oscilloscope on the bus to confirm the actual bit timing on the wire.
9. Check the CP341 diagnostic buffer: In STEP 7, open the CP341 in online view → Diagnostic Buffer. Look for entries "MODBUS driver startup OK", "Frame sent", and "Response received". Missing "Frame sent" entries mean the driver never left the ready state — usually a dongle or LADDR issue. Present "Frame sent" but absent "Response received" entries confirm the 0F05 timeout interpretation.
10. Replace the dongle: If all other checks pass, swap the dongle 6ES7870-1AB01-0AA0 with a known-good one to rule out EEPROM corruption. Dongles can fail intermittently after years of service in thermally cycled cabinets.
11. Update driver and firmware: Load the latest MODBUS Master RTU driver (V3.2.x or higher as of the CP341 lifecycle) and verify CP341 firmware is V1.0.x or higher. Driver updates are loaded via CP PtP Param → Load to Module; the CP is briefly unavailable (~10 s) during download.

Common Configuration Errors

Three configuration errors account for the majority of 0F05 field incidents:

The user in the source has LEN = 32 (16#20) in DB40.DBW10, which is the dominant cause. Set DB40.DBW10 to W#16#0006 for a 2-register FC 03/04 read. The remaining 26 bytes of the request data area in DB42 are unused; the CP341 driver transmits only the first LEN bytes of the request buffer.

Driver, Firmware, and Dongle Verification

Check the driver version in CP PtP Param → Module Information. Recommended minimum versions for stable MODBUS Master operation on CP341-1AH02/-1BH02:

• MODBUS Master RTU driver: V3.1.0 or higher (V3.2.x recommended for FC 43/14 support)
• CP341 firmware: V1.0.0 or higher (shown in online module information → Firmware)
• STEP 7 CP PtP Param tool: V5.5 SP4 or higher (V5.6 for newer driver support)
• TIA Portal CM PtP: V13 SP1 or higher with HSP for CP341 legacy support

To verify dongle presence without navigating CP PtP Param, look at the diagnostic buffer for the entry "MODBUS Master license detected" (success) or "MODBUS Master license missing" (failure). If missing, the dongle is not recognized — confirm physical seating and revision.

Update procedure: Download the latest MODBUS Master driver from Siemens Industry Online Support entry 1117396 and load it to the CP via CP PtP Param → Driver → Load to Module. The CP will be briefly unavailable during download; existing SEND/RECV calls in the PLC will return DONE=FALSE and ERROR=TRUE until the load completes.

Slave Device Configuration and Wiring

For RS-485 MODBUS RTU, the physical layer is often the root cause of 0F05 errors that are intermittent or appear only when adjacent equipment starts up:

• Cable type: Belden 3106A or equivalent, shielded twisted pair, characteristic impedance 120 Ω, capacitance < 50 pF/m
• Maximum cable length: 1200 m at 9600 baud per EIA-485; shorter runs are better in electrically noisy environments (300 m typical in industrial cabinets with VFDs)
• Termination: 120 Ω across A-B at both ends of the trunk. NOT at intermediate drops; not at any device in the middle of the bus
• Bias: 680 Ω pull-up to +5 V on D1 (A, non-inverting) and 680 Ω pull-down to GND on D0 (B, inverting) at exactly one point on the bus — typically at the master end
• Shield grounding: Ground the shield at one end only (master end preferred) to avoid ground loops that introduce common-mode noise
• Common mode voltage: EIA-485 specifies -7 V to +12 V common-mode range. Exceeding this (e.g., ground potential difference between buildings) requires an isolated repeater

Connect a MODBUS bus analyzer (Witte Software MODBUS Poll, Simply Modbus Master, or a Saleae Logic Pro with MODBUS protocol decoder) at the slave end to verify frames arrive intact. If the analyzer sees valid requests and valid responses but the CP341 still reports 0F05, the issue is in the CP341 side (driver, monitoring time, dongle). If the analyzer sees no requests, the CP341 is not transmitting (LADDR, LEN, driver, or dongle issue).

Monitoring Time, Frame Timing, and Retries

CP341 MODBUS Master has three user-configurable timing parameters in CP PtP Param:

For slow slaves (industrial sensors with 16-bit ADC settling time, or slaves that must process a request and refresh internal data), set monitoring time to 1000-2000 ms during commissioning. For production, tune to the minimum value that still produces zero error rate under worst-case bus loading — typically 2× the 99th percentile measured response time.

The inter-frame delay MUST be at least 3.5 character times per MODBUS RTU standard to mark frame boundaries. At 9600 baud with 8N2 framing (11 bits per character), 3.5 chars = 3.5 × 11 / 9600 ≈ 4 ms. The CP341 enforces this automatically and inserts the silent interval between consecutive requests without user configuration.

Set retries to 2-3 for production links to ride out transient bus errors. Each retry consumes one monitoring time window, so total worst-case transaction time = (retries + 1) × monitoring_time.

Status Code Reference Table

Common CP341 MODBUS Master STATUS codes (16-bit hex) and their meaning:

STEP 7 V5.x vs TIA Portal Configuration Notes

The CP341 is a legacy S7-300 module and is configured differently in STEP 7 V5.x versus TIA Portal:

For TIA Portal projects, install the HSP (Hardware Support Package) for CP341 to enable device catalog entries and configuration dialogs. Without the HSP, the CP341 can still be used as an "unspecific" S7-300 module with limited configuration options.

Inline Diagnostic Flow Diagram

Field-Verified Commissioning Checklist

1. Dongle 6ES7870-1AB01-0AA0 physically installed and recognized in module information
2. CP341 logical base address in HW Config matches DB40.DBW16 and DB41.DBW16
3. LEN parameter (DB40.DBW10) matches the actual request frame size, not the buffer maximum
4. Request frame bytes in DB42 offset 0 contain valid slave address, function code, register address, and count
5. Frame parameters in CP PtP Param exactly match slave: 9600, 8, N, 2
6. RS-485 bus terminated with 120 Ω at each end; bias network at master end only
7. Monitoring time set ≥ 1000 ms during initial commissioning
8. Bus analyzer confirms frames transmitted and responses received without CRC errors
9. Diagnostic buffer shows "Frame sent" and "Response received" entries
10. All function codes supported by slave (e.g., 01, 02, 03, 04, 05, 06, 15, 16) match what the application calls
11. After successful test, monitoring time can be reduced to 2× the observed P99 response time
12. Document final production values of LEN, LADDR, monitoring time, and retry count for future maintenance

Frequently Asked Questions