Resolving CP341 Modbus Master Conflicts on S7-412-5H Redundants

1. Problem Description and System Context

A redundant SIMATIC S7-400 412-5 H PN/DP station, networked to multiple ET 200M remote racks through IM 153 PROFIBUS couplers, has been operating a CP 341-RS422/485 module as a Modbus RTU master for five years against a stable of slave devices. The control cabinet is being extended with additional field equipment that would have pushed the trunk length of the existing RS-485 bus past the EIA-485 maximum of 1,200 m (3,900 ft) at the configured baud rate, so the integrator is adding a second CP 341 (order number 6ES7 341-1CH02-0AE0) in the same remote rack (Rack 2) and intends to run it as a second Modbus RTU master on its own physical RS-485 segment.

The first CP 341, when exercised in isolation with the second card powered but not yet called, continues to poll its slaves without diagnostic entry. The instant the second card's application code is enabled, both masters fail simultaneously. The existing master reports no diagnostic events, but the new card produces a stack of incoming diagnostic events pointing at the CPU-to-CP direction. Diagnostic buffer text includes:

• Event 1: IF 1 — Error during data transmission from CPU to CP.
• Event 2: IF 1 — Error occurred during data transfer from CPU with RCV; detailed error in SYSTAT prior to this entry.
• Event 3: IF 1 — Timeout during transfer to CPU.
• Event 4: IF 1 — Internal error during data transfer to CPU — unexpected acknowledgement passive.

The integrator has also observed that, when only the new master is active, payloads belonging to the original master appear inside the data block that was assigned to the new master's slave list. Both symptoms point at the same architectural fault: the application is sharing a data block between two Modbus master instances that must each own an isolated data area.

2. CP 341 Modbus Master Hardware and Driver Requirements

The CP 341 is a serial communications processor for the S7-300/400 family. The variant that drives an RS-422/485 multidrop Modbus RTU trunk is 6ES7 341-1CH02-0AE0. Each CP 341 must be loaded with the Modbus master RTU firmware image and bound to a Modbus master license dongle. The driver image and the function block library are part of the option package "SIMATIC S7 CP PtP — Modbus Master / Slave" and are documented in manual A5E00218410-06 (CP 341/CP 441-2 Modbus Master RTU, Modbus Slave RTU).

For the redundant S7-400H station, both CPs live in the same ET 200M (Rack 2) and are addressed through the same IM 153 PROFIBUS coupler. Hardware configuration must therefore:

1. Insert two CP 341 modules under the IM 153 with non-overlapping slot numbers.
2. Assign each CP a unique logical base address in the I/O process image (the LADDR parameter of FB 7/FB 8 is read from this base address).
3. Load the Modbus master firmware on each CP 341 individually. Loading the driver on the first CP does not propagate to the second; the second CP ships with ASCII 3964(R) driver only.
4. Plug a Modbus master license into each CP. The license order number for the Modbus master is 6ES7 341-1AA00-0AE0 (single license), or the bundle 6AV6 671-0AE10-0AX0 for the full PtP option.

If the integrator skipped step 3 on the second card, the driver would refuse every Modbus request and report SYSTAT error 0x0E0A. The diagnostic events on the second card, however, do not match a missing driver; they match a runtime data block conflict, which is the issue treated in this article.

3. P_SND_RK and P_RCV_RK Function Block Architecture

The Modbus master driver ships with two function blocks in the SIMATIC library:

Each call to FB 7 and FB 8 must be assigned its own instance data block (IDB) so that the block's local static tags — the request handle, sequence counter, and LADDR/DB_NO copy — do not collide with the other master's instance. The relevant input pins and their meaning are:

When the integrator copied the working code from the first master to the second, the instance DB (often called IDB_P_SND_RK and IDB_P_RCV_RK in the project) was dragged in too, but the actual value of DB_NO inside that IDB still pointed at the first master's data block. Two FBs were therefore writing into the same byte range of DB 100, for example, and each new request from master #2 overwrote the request frame that master #1 had not yet finished transmitting.

4. Diagnostic Buffer Analysis: Decoding the Four Event Entries

Each of the four diagnostic events in the source post is a CP 341 self-diagnostic, surfaced through the IM 153 / PROFIBUS DP diagnostic mechanism and written to the CPU's diagnostic buffer. The order listed (with Event 1 as the most recent) is the standard S7 ordering: newest first.

To extract the SYSTAT value at runtime, read the SYSTAT output of FB 8 / P_RCV_RK into a watch table. SYSTAT is also readable via the CP's parameter assignment in HW Config: CP 341 → Diagnostics → Status. The two-byte SYSTAT word follows this layout:

• Bit 15 = 1: error condition present.
• Bits 14-12 = reserved (always 0).
• Bits 11-8 = error sub-class (e.g. 0x0A = timeout, 0x0B = sequence).
• Bits 7-0 = error class (0x0E = send/receive protocol error, 0x0F = internal CP error).

5. Root Cause: Instance DB and Data Block Overlap

The integrator's working hypothesis during the troubleshooting session was that the two P_SND_RK / P_RCV_RK function blocks shared a CP-side resource. In fact they share a CPU-side resource. The CP 341 has two physical interfaces, but each instance of FB 7 / FB 8 only ever talks to one CP, addressed by LADDR. What is not CP-isolated is the buffer the user supplies through DB_NO and DBB_NO. The CP 341 itself does not own a Modbus data buffer; it uses the data block in the CPU as a passive mailbox.

When two FBs are configured with the same DB_NO, the second FB's request data is written to the same byte range the first FB is still using. The CP for the first master is in the middle of lifting a request out of the data block when the second master overwrites it. From the first CP's point of view the CPU just delivered a malformed frame, and from the second CP's point of view the CPU just delivered a request that should never have been there. Both CPs raise events 1, 2, 3, and 4, although in the field report only the new CP's events are visible because the original master is being polled on a longer cycle and the error is intermittent.

The "data dumped into the wrong DB" observation is the same fault seen from the application side: because both FBs read and write the same DB range, slave payloads addressed to master #1 appear in the buffer that master #2's user program reads. Once the FB is decoupled, every byte goes to the right place.

6. Step-by-Step Resolution Procedure

The following procedure restores correct dual-master operation on the CP 341 pair without replacing the hardware or breaking the existing master.

1. Confirm both CPs are loaded with the Modbus master driver. In HW Config, open each CP 341 → Parameter → Protocol. The drop-down should show "Modbus Master RTU." If the second CP still lists "ASCII / 3964(R)," load the driver using the Modbus Master installation DVD or the latest SIMATIC option package, then power-cycle the CP. Without the driver, the FB calls will time out regardless of DB configuration.
2. Confirm the Modbus master license on the second CP. In the CP's Parameter → Modbus Master tab, the licensed checkbox must be on. Without the license, the driver returns SYSTAT 0x0E01 and refuses to transmit.
3. Assign a unique base address to each CP 341. In HW Config, set the LADDR of CP #1 to e.g. 256 and CP #2 to e.g. 288. The address gap prevents the CPU from writing to the wrong diagnostic byte when SFC 59 "REC_RDBS" is used.
4. Create a new instance data block for the second master. In the SIMATIC Manager blocks container, insert a new DB; for FB 7 (P_SND_RK) call, choose "Instance DB" and select FB 7. Repeat for FB 8. Name these IDB_P_SND_RK_2 and IDB_P_RCV_RK_2 to keep them apart from the originals.
5. Open the new instance DBs and assign a unique DB_NO and DBB_NO. In the IDB's static section, set the DB_NO input to a brand new data block, e.g. DB 200 for master #2, and DBB_NO to 0. Master #1 keeps DB_NO = DB 100, DBB_NO = 0. The two masters now own disjoint byte ranges and cannot trample each other.
6. Update the FB calls in OB 1 / OB 35. Replace the second master's FB 7 / FB 8 calls so that they instantiate against the new IDB names. Double-check the LADDR input on each call: it must be 256 for master #1, 288 for master #2.
7. Compile, download blocks only (not the hardware). A full hardware download would reset the CPs and disturb the existing master's bus. Use "Download — Blocks to Target" so that only the FBs and the new IDBs land in the CPU.
8. Clear the CPU's diagnostic buffer to wipe the residual CP 341 entries. Use STEP 7 → CPU → Clear/Reset Diagnostic Buffer, or MRES if a full reset is acceptable during a maintenance window.

7. Verification and Online Diagnostics

After the corrected blocks are loaded, perform the following checks before releasing the system to production.

1. Watch table — SYSTAT polling. Open the watch table that references the SYSTAT output of both FB 8 instances. With both masters running, both SYSTAT words must read 16#0000. Any non-zero value indicates a remaining configuration error (typically LADDR mis-wired, license missing, or DB_NO still shared).
2. Status byte from the CP. In HW Config → CP 341 → Diagnostics → Status, the "Operating Mode" field must read "Data exchange." "Not configured" or "Fault" means the driver is not active.
3. CPU diagnostic buffer. In STEP 7 → CPU → Diagnostics/Setting → Diagnostic Buffer, filter for CP 341 events. After a five-minute run, no new entries should be present. The four legacy events 1-4 should be the only CP-related records visible and they will age out as the buffer rolls.
4. Slave echo test. Use a Modbus slave simulator on the new master's bus and confirm that read requests from the new FB return the expected payload. Repeat on the original master's bus to confirm no cross-talk.
5. Long-term stability test. Run both masters for 24 hours under load. Verify that the count of valid responses per master matches the number of requests issued, with zero retries. The retries counter is a useful tag to surface in the user program; the FB 7 / FB 8 pair already exposes a R_ERROR output that can be accumulated.
6. Cold restart of the redundant pair. On a S7-400H, perform an H-switchover while the bus is hot. Both masters should resume without re-issuing diagnostic events, because the new instance DBs are loaded in both CPUs of the H-pair and the runtime buffer is consistent.

8. SYSTAT Error Code Reference Table

The following SYSTAT codes are excerpted from the CP 341 Modbus master manual A5E00218410-06 and reflect the codes that surface in dual-master conflicts of this type.

9. Multi-CP 341 Deployment Checklist

Use this checklist any time more than one CP 341 is to be installed as a Modbus master on the same CPU or H-pair.

• Each CP 341 carries its own Modbus master driver and license.
• Each CP 341 has a unique LADDR in HW Config, with at least 16 bytes of I/O address space (the CP occupies 16 input bytes and 16 output bytes minimum).
• Each FB 7 / FB 8 call uses its own instance DB. Multi-instance technique is permitted but the multi-instance container must be a separate FB or DB, not the same instance as the first master.
• DB_NO used by the FB is unique per CP. Avoid the temptation to use the same DB with a different DBB_NO offset; the CP 341 can read and write the entire DB and the FBs do not protect each other inside one DB.
• DBB_NO defaults to 0 and stays at 0 unless the user is intentionally building multiple mailbox slots inside one DB; in that case the slot sizes must be larger than the maximum Modbus PDU (256 bytes plus Modbus overhead).
• The SYSTAT output of each FB 8 is monitored in a watch table or in the user program; a non-zero SYSTAT triggers an operator message and a retry rather than being silently ignored.
• The Modbus response timeout (configured in the CP 341 parameter assignment) is set at least 50 ms above the worst slave's turnaround time, but no more than 5,000 ms to avoid blocking the cyclic OB.
• If a single PROFIBUS DP line is shared between the two CPs (i.e. they sit in the same ET 200M), confirm that the bus parameters for the new CP match the existing one — same baud rate, same Tslot, same Tset.
• For redundant operation on S7-400H, the I/O address range used by the new CP must be configured as a redundant I/O range, otherwise an H-switchover will leave the second master without a target CP.

10. Wiring, Bus Length, and Termination Considerations

The original driver for the second CP 341 was that the existing RS-485 trunk would have exceeded the EIA-485 maximum length of 1,200 m at the chosen baud rate. This is the correct trigger for splitting the bus. A few wiring rules need to be respected on the new trunk.

• Use a shielded twisted pair with characteristic impedance 120 Ω. Belden 3106A or equivalent is typical for industrial Modbus trunks.
• Place a 120 Ω termination resistor at each physical end of the new trunk, never in the middle. The CP 341 RS-422/485 interface can enable an internal termination through the CP's parameter assignment (CP 341 → Parameter → Interface → Termination = ON). This is only correct when the CP sits at the physical end of the trunk. If the CP is mid-trunk, the internal termination must be OFF.
• Confirm the RS-485 common-mode voltage. The CP 341's RS-485 port is not isolated to 1,500 V in the -1CH02-0AE0 variant; for long outdoor runs, add an RS-485 isolator such as Phoenix Contact PSM-ME-RS485 at each end.
• Keep the new trunk's logical ground reference at one point only, typically at the master end. Floating shields cause SYSTAT 0x0E33 (CRC errors) and SYSTAT 0x0E40 (function code echo mismatch) at random times.
• Set the same baud rate on both trunks so the FBs are interchangeable; the CP 341 supports 300, 600, 1,200, 2,400, 4,800, 9,600, 19,200, 38,400, 57,600, and 115,200 bps. Modbus RTU spec recommends 19,200 bps or below for robust industrial use.

11. Migration from Legacy Single-Master Designs

Plants that have run a single CP 341 Modbus master for many years often copy the same FB instance into new code, exactly as the integrator did. The single-master pattern works because there is no second FB to race against. Migrating to a dual-master configuration requires three deliberate moves:

1. Renaming the original instance DBs to _1 and the new ones to _2, and writing a project naming convention that prevents reuse.
2. Introducing a project-wide constant block (a global DB of type CONST) that defines the LADDR, DB_NO, and DBB_NO for each CP, so the FB calls reference symbols rather than absolute values. This prevents drift when more CPs are added.
3. Adding a diagnostic FB — for example, a custom FB 100 "CP341_DIAG" that polls the SYSTAT of every Modbus master once per OB 35 cycle and accumulates the worst-case code into an HMI tag. This converts the four cryptic CP 341 events into a single, operator-readable status word.

For future growth, a CP 441-2 (6ES7 441-2AA05-0AE0) supports up to 32 Modbus masters on a single module and removes the need for multiple CP 341s. The migration path from dual CP 341 to a single CP 441-2 is straightforward: the FB 7 / FB 8 calls are re-targeted to a different LADDR and the second physical CP is decommissioned. The data block architecture described in this article carries over without change.

12. FAQ