Resolving CP341 Modbus RS422/485 Errors 2072, 2073, 2079

1. Problem Overview: Intermittent CP341 Modbus Master Faults

An SIMATIC S7-300 CP 341 configured as a Modbus master on the X27 RS 422/485 port intermittently logs communication faults to a remote Modbus slave (in this case a Bently Nevada BN 3500 vibration monitor). The driver-level error codes reported by the master block are 16#2072, 16#2073, and 16#2079. Communication is otherwise healthy for tens of minutes to hours between faults, which makes the failure purely transient and indicates a timing, electrical, or buffering problem rather than a hard configuration mismatch.

The behavior is consistent across three Modbus request telegrams sent cyclically by the loadable Modbus master driver (article ID 1174035 on the Siemens Support portal). When the fault occurs, the Diagnostic Buffer of the CP 341 and the corresponding status word on the CFC instance DB reveal which telegram was active when the fault was detected, which is the first diagnostic step to isolate the failing poll.

2. Affected Hardware, Order Numbers, and Firmware

All CP 341 order numbers with the X27 RS 422/485 interface are in scope for the analysis below. The relevant variants for Modbus RS 485 multi-drop are:

Verify the MLFB on the front panel of the module before applying the recommended parameter set. Hardware revisions after 02/2008 support the loadable Modbus master driver (Article ID 189852) and the integrated ASCII/3964(R) driver on the same module.

The applicable firmware functionality (loadable driver kit) is delivered with the STEP 7 point-to-point parameter assignment tool (PtP Param, part of the SIMATIC S7 optional packages). Driver kit revision 5.x or higher is recommended for new installations. Always re-load the driver after a firmware update because the CP 341 stores only one driver at a time.

3. Decoding the Error Codes 2072, 2073, 2079

Codes 0x207x are returned by the loadable driver layer on the CP 341 (not by the user program). They appear in the STATUS output of the Modbus master driver and are mirrored into the CP 341 diagnostic buffer. The full reference is in chapter B.3 X27 (RS 422/485) Interface of the CP 341 of the CP 341 Point-to-Point Communication manual, 04/2011 edition.

4. Root Cause Analysis: Why Intermittent Faults Develop

Intermittent RS 485 Modbus faults almost always have one of three roots. The fact that the link runs for hours before failing is a strong tell that the problem is environmental (noise, ground drift), not parameter-assignment.

4.1 Electrical / Physical Layer

• Termination missing or duplicated. On RS 485 you need exactly one termination (typically 120 Ω) at each end of the trunk. The CP 341 has a built-in termination that is enabled in PtP Param > Interface > RS 485; if the BN 3500 also has internal termination enabled, the bus is double-terminated and reflections corrupt characters intermittently.
• No fail-safe bias. When all transmitters are inactive, an un-biased RS 485 line floats and the receiver can interpret noise as a start bit, producing garbage characters and 16#2073 events.
• Ground potential difference. The CP 341 GND terminal and the BN 3500 chassis ground must be within a few volts. Industrial vibration monitoring cabinets are often far from the PLC cabinet and may sit on a different earth electrode. Bonding the two grounds with a 6 mm² copper strap often eliminates the fault.
• Cable category. Use only twisted-pair shielded cable designed for RS 485 (Belden 3106A, Lapp EIB-CY 2x2x0.22, or equivalent). Parallel routing with VFD power cables must exceed 200 mm or use a metallic separator.

4.2 Driver Timing Parameters

The Modbus master driver on CP 341 exposes three time constants that directly map to the error codes above:

• Character-delay time (Inter-character timeout). Default 4 ms at 9600 baud. If the slave pauses longer than this between bytes, the CP 341 aborts the frame with 16#2072.
• Response timeout. Time the master waits for the start of the slave response. Default 2 s.
• Frame turnaround time. Settling time after the master releases the RS 485 line before the slave is allowed to reply.

4.3 Program / CPU Side

• The Modbus master FBs must be called in a time-critical OB (OB 1 with appropriate priority, or a dedicated cyclic interrupt OB such as OB 35).
• If the OB cycle is longer than the slave response time, the next send call fires before the previous receive has been serviced, and the CP 341 hardware receive FIFO overruns.
• CFC charts compiled without the Run-time option can introduce additional latency between block calls, manifesting as 16#2079.

5. Cabling and Termination for the X27 RS 422/485 Interface

The X27 socket is a 15-pin sub-D female on the front of the CP 341. The standard RS 485 two-wire pinout is:

For multi-drop to a BN 3500 chassis use a daisy-chain topology. Drop cables (stubs) must be shorter than 30 cm at 9600 baud and shorter than 10 cm at 19 200 baud. Star topologies are explicitly prohibited on RS 485 and are a frequent root cause of intermittent 2072/2073 events when a star was retrofitted into a previously-working bus.

Termination procedure:

1. Identify the two physical ends of the trunk.
2. Enable the CP 341 internal 220 Ω termination through PtP Param if the CP 341 sits at one end of the trunk; otherwise leave it disabled.
3. Install a 120 Ω resistor across T/R(A) and T/R(B) at the far end (BN 3500 terminal block).
4. Confirm with an ohmmeter across the data pair at the cabinet end: you should read ~60 Ω (two 120 Ω in parallel). If you read 40 Ω, you have triple termination; if you read high-Z, both ends are un-terminated.
5. If the line is longer than ~50 m or runs through a noisy plant, add fail-safe bias resistors (typically 680 Ω pull-up to 5 V and 680 Ω pull-down to GND) at the master end only.

6. PtP Param Configuration Checklist

The PtP Param tool is delivered with STEP 7 optional package and is the only supported way to configure the CP 341. The configuration is downloaded to the module's flash, separate from the S7 user program. Recommended settings for BN 3500 Modbus RTU:

7. Program Side: Calling the Modbus Master Driver

The Siemens-documented path uses FB 7 P_RCV_RK and FB 8 P_SND_RK. Both are in the Standard Library > Communication Blocks and are documented in the online help of STEP 7 V5.x. A canonical Modbus FC 03 read of one register pair looks like this in structured text:

// Master send request
CALL FB 8, DB 8 (
    REQ := bStartPoll,
    LADDR := 256,            // Logical address of CP 341, check HW Config
    DB_NO := 100,            // Data block containing send data
    DBB_NO := 0,             // Byte offset in DB 100
    LEN := 8,                // Length of send buffer (Modbus RTU FC03 query)
    R_TYP := 'S',            // 'S' = Send, 'R' = Receive
    DONE  => bSendDone,
    ERROR => bSendErr,
    STATUS => wSendStatus);

// Master receive reply
CALL FB 7, DB 7 (
    EN_R := bSendDone,
    LADDR := 256,
    DB_NO := 101,            // Data block for receive data
    DBB_NO := 0,
    LEN := 256,              // Max receive buffer
    R_TYP := 'R',
    NDR  => bRecvOK,
    ERROR => bRecvErr,
    STATUS => wRecvStatus,
    LEN  => wRecvLen);

Map the returned STATUS word to a diagnostic row in the CFC. The error codes 0x2072/0x2073/0x2079 appear directly in the lower byte of wRecvStatus when the fault occurs on the receive call. If a custom block such as MBUSMCFG is in use, replicate this mapping inside it.

8. Diagnostic Procedure

1. Capture the CP 341 Diagnostic Buffer immediately after each fault: SIMATIC Manager > CP 341 > Diagnostics > Diagnostic Buffer. Note the exact time-of-day stamp to correlate with plant events (VFD starts, welding, crane operations).
2. Read the STATUS outputs of the send and receive FBs at the same instant. Add a latch in CFC that retains the last error code and the last failed poll index (1, 2 or 3).
3. Log the value of the slave's RS 485 line voltage (A−B) with an oscilloscope or a Modbus-aware line analyzer (e.g., Siemens Modbus Test Suite or Wireshark + RS 485 tap). Look for noise bursts coincident with faults.
4. Verify the configured Modbus slave address on the BN 3500 (default is 1; some installations use 247 for broadcast – do not use broadcast for normal polling).
5. Reduce the polling rate to one telegram every 2 s. If the faults disappear, the problem is CPU load / OB priority. If they persist, the problem is physical.
6. Loop the line back at the CP 341 end with a 120 Ω termination on a short stub and run the Modbus master against its own echo with a slave emulator. If the loopback runs cleanly for 24 h, the physical layer is guilty.

9. Field-Validated Fixes

10. Verification and Long-Term Health Check

After applying the fix, leave the installation logging for a minimum of 72 h under normal operating conditions including at least one start-up of every large drive in the cabinet. Add the following to the CFC / WinCC diagnostic screen so the issue can never recur silently:

• Counter for 2072, 2073, 2079 events per shift with a reset button.
• Last-good-poll timestamp displayed on the HMI.
• Alarms (WinCC horn) at >10 faults per hour – indicates the link is degraded and maintenance should be called before a hard failure.
• Per-poll round-trip time (computed as timestamp on SEND_DONE minus timestamp on first SEND call); trend this and alarm on >150 % of nominal.

Once 0x2072/0x2073/0x2079 are absent for one week, mark the corrective action as verified and archive the diagnostic buffer export together with a photo of the wiring and the PtP Param configuration for audit purposes.

11. When to Escalate to Siemens Support

If the documented procedure above does not eliminate the faults and the loopback test passes, open a support request at Siemens Industry Online Support quoting:

• MLFB and hardware revision of the CP 341 (printed on the side label).
• Firmware version and loadable driver version.
• Export of the HW Config and the PtP Param project.
• Diagnostic buffer dump (.txt) covering at least five fault events.
• STEP 7 project version (V5.5 SPx or V5.7) and CPU order number.

Because MBUSMCFG / FB 605 is an internal PG block, escalate the block itself through the Siemens-internal support channel that originally delivered the block, not through general industrial support.

Frequently Asked Questions