Configuring Multipoint Modbus RTU: S7-300 CP341 to S7-1200 CM1241

A brownfield integration problem arises when a new S7-1200 PLC must share a single Modbus RTU segment with an existing S7-300 station that already talks to a third-party DCS. The DCS in this case is an Invensys system acting as the Modbus master, polling two redundant CP 341 modules installed in a CPU 315-2DP/MPI. A new CPU 1212C fitted with a CM 1241 RS422/RS485 module must now be added, but the legacy DCS only knows the existing two slave addresses and the only available spare resource on the S7-300 is the CP 341 slots themselves.

The critical field question is: can a single CP 341 that is already configured as a slave to the DCS also exchange data with the new S7-1200? The short answer is no, because Modbus RTU is a strictly single-master protocol and a slave cannot originate a request to another slave. The recommended approach is to add a CP 343-1 Ethernet module to the S7-300, treat it as a multipoint Ethernet backbone for the new S7-1200 and any HMIs, and keep the redundant CP 341 pair dedicated to the DCS link.

This reference walks through the architecture, the rationale, the hardware selection, the configuration parameters, the commissioning steps, and the verification checks required to ship a hybrid Modbus RTU + Industrial Ethernet system.

1. Problem Statement and Context

The integration driver is the simultaneous presence of a new S7-1200 and a legacy DCS that does not support Modbus TCP. The DCS expects to find two Modbus RTU slave unit IDs (one per CP 341) on a single RS485 trunk, and it cannot be re-tasked to read a third device on the same segment. The S7-300 application, however, must also forward the same process data to the new S7-1200, which has no RS485 peer on the existing DCS trunk but does have a CM 1241 spare.

The user originally proposed two alternative ideas:

1. Buy a third CP 341 for the S7-300 and let it act as a Modbus master toward the CM 1241.
2. Reuse one of the existing CP 341 modules as a shared gateway between the DCS and the S7-1200.

Both proposals fail on the same protocol-level constraint: a CP 341 supports exactly one Modbus role (master or slave) and a Modbus RTU bus supports exactly one master. A CP 341 that is already a slave cannot originate a request to the CM 1241, and a CP 341 that is reconfigured as a master would stop replying to the DCS. The fix is to add a CP 343-1 and bridge the S7-300 / S7-1200 traffic over PROFINET using S7 PUT/GET, leaving the CP 341 pair to serve only the DCS.

2. Hardware Inventory and Identification

The following Siemens order numbers (MLFB) are referenced from the field installation:

The CP 341 -1CH01 variant supports the Modbus master and Modbus slave protocol drivers, both loadable from the Point-to-Point parameter assignment tool. The CM 1241 -1CH32 module is configured from TIA Portal as a Modbus master or slave using the MB_MASTER / MB_SLAVE instructions in the S7-1200 program.

3. Modbus RTU Protocol Constraints

Modbus RTU is a single-master, multi-drop protocol. The master initiates every transaction on the bus; a slave never transmits unless it has been polled. This property is enforced at the application layer regardless of the physical medium.

Consequences for this brownfield integration:

• A slave cannot poll another slave. A CP 341 that is a slave has no Modbus mechanism to "push" data to a CM 1241.
• Two independent masters on the same wire produce collisions. Modbus RTU has no bus arbitration, so a second master (e.g. a CM 1241 configured as master) would corrupt frames that the DCS is driving.
• A passive "tapped" slave that only listens is not how Modbus works. A slave is silent until queried; unsolicited data is not supported in RTU mode.
• Multipoint refers only to the physical RS485 multi-drop topology; it is not a license to add additional masters.

Reference: Point-to-multipoint communication describes a one-to-many connection model where multiple receivers are attached to a single transmitter. In the Modbus RTU context the transmitter is always the master and the receivers are the slaves.

This is the central reason the user's first intuition - "make the existing CP 341 talk to both the DCS and the S7-1200" - cannot work without a separate bus for each master.

4. RS485 Timing Reference

Character timing on the RS485 trunk is calculated from the configured baud rate and the Modbus RTU frame format (8 data bits, even parity, 1 stop bit = 11 bits/character):

t_char = 11 / baud_rate

For 9600 bit/s: t_char = 11 / 9600 = 1.146 ms. The Modbus RTU inter-frame silence must be at least 3.5 character times, which at 9600 bit/s is 3.5 * 1.146 = 4.01 ms. The inter-character timeout within a frame is 1.5 character times, which at 9600 bit/s is 1.72 ms.

Implications for the S7-300 application:

• The S7-300 OB1 cycle time must be shorter than the inter-character timeout, or the CP 341 will treat the outgoing response as a new frame.
• The CP 341 -1CH01 default response time is 0 to 65535 ms; set this to a value that matches the DCS poll cycle (typically 50-500 ms for legacy DCS installations).

5. Architecture Options Evaluated

Option B is the lowest-risk, lowest-touch architecture. It honors the existing DCS contract, requires no firmware changes on the DCS, and uses standard Siemens blocks on the S7-300 and S7-1200.

6. Selected Architecture: Ethernet Bridge for S7-300 / S7-1200

The resulting topology is a hybrid network:

• Modbus RTU segment (RS485, 2-wire) carries the DCS master to the two CP 341 slaves. Termination and bias are required at the bus ends.
• Industrial Ethernet (PROFINET, 100 Mbit/s, full duplex) carries the S7-300 to S7-1200 data exchange plus the HMI traffic. The CP 343-1 acts as the S7-300 Ethernet node; the CPU 1212C PROFINET port acts as the S7-1200 Ethernet node.

The two CP 341 modules are configured identically: same Modbus slave address (matching what the DCS polls), same register map, same RS485 settings. Only the one currently being polled by the DCS replies; the other holds its transmitter in high-impedance.

7. CP 343-1 Selection and S7-300 Ethernet Parameters

Add a CP 343-1 to a free slot in the S7-300 rack. Typical MLFBs available on the Siemens catalog include:

Pick the variant that matches the S7-300 backplane and the project's firmware baseline. A Lean variant is sufficient for simple S7 / PROFINET use; an Advanced variant is needed only if the S7-300 must also serve as a Modbus TCP server or use IT functions such as FTP, HTTP, or email.

Recommended IP plan for the S7-300 Ethernet segment:

The CP 343-1 must be configured in STEP 7 (or TIA Portal if the S7-300 project is migrated) with the following parameters:

• IP address: 192.168.0.11
• Subnet mask: 255.255.255.0
• Router: 192.168.0.1
• S7 communication: enabled on the CP (the "Permit S7 communication" tick box; required for PUT/GET to the CPU).
• Time-of-day synchronisation: optional, per project standards.

8. S7-1200 Side Configuration

The CPU 1212C PROFINET port is the Ethernet interface that participates in the S7 communication with the S7-300. Its built-in switch has two ports; one is connected to the HMI, the other to the CP 343-1.

TIA Portal configuration items:

• IP address: 192.168.0.20, subnet mask 255.255.255.0.
• PROFINET device name: s7-1200-modbus-bridge.
• "Permit access with PUT/GET communication from remote partner" must be enabled under Properties > Protection & Security > Connection mechanisms. Without this, the S7-300 PUT/GET blocks are rejected.
• DBs that hold the shared data must be defined with "Accessible from HMI/OPC UA" set if the HMI reads them directly; or use a dedicated exchange DB.

A typical exchange DB on the S7-1200 (DB200 "BridgeData") contains the registers that mirror the Modbus RTU I/O plus any S7-300 status words. TIA Portal configuration steps:

1. Add a new global DB (DB200, name BridgeData).
2. Disable optimized block access (so PUT/GET from the S7-300 can use absolute addresses).
3. Define the data structure as a STRUCT of WORDs and REALs that match the S7-300 PUT/GET offsets.

9. CP 341 Redundant Slave Behaviour

The field installation uses two CP 341 modules carrying the same Modbus slave address and the same register map. Modbus RTU does not have a redundancy protocol; the "redundancy" is implemented at the DCS level by the DCS polling both addresses and selecting the data with the most recent timestamp or the best diagnostics.

Operating principles:

• The duty CP 341 is the one currently polled by the DCS; the standby CP 341 sees the requests but is addressed with a different Modbus unit ID (typically duty = 1, standby = 2). The DCS uses the data from whichever unit ID responds with valid diagnostics.
• Both CPs hold identical process images because the S7-300 application program writes the same data to both. Consistency is the responsibility of the S7-300 user program; the CP 341 does not synchronise images between the two modules.
• The hot-standby switchover time depends on the DCS poll cycle and the S7-300 scan time. Typical figures are 2 to 4 Modbus poll cycles.

This architecture is unaffected by the addition of the S7-1200 because the CP 341 / DCS segment remains a closed RS485 network with the DCS as the only master.

10. S7 Communication: PUT/GET Blocks

Two programming options exist for S7-300 / S7-1200 data exchange over Ethernet:

• S7 PUT / GET (the legacy, simplest; requires no S7 connection configuration on the S7-1200).
• Open User Communication (OUC) over TCP (more flexible; requires the TCON, TSEND, TRCV blocks).

For Modbus bridging use the S7 PUT/GET pattern because the S7-300 program is typically a STEP 7 project while the S7-1200 is a TIA Portal project, and PUT/GET hides the connection configuration in the S7-300 side.

S7-300 side (STEP 7 STL in OB1):

// S7 PUT: write 10 words from S7-300 DB100 to S7-1200 DB200 starting at offset 0
CALL  "PUT"
  REQ    :=M100.0
  ID     :=1
  DONE   :=M110.0
  ERROR  :=M110.1
  STATUS :=MW112
  ADDR_1 :=P#DB200.DBX0.0 WORD 10
  SD_1   :=P#DB100.DBX0.0 WORD 10
  LEN    :=20

The ID is the local connection ID; it must match the ID used in the S7-300's connection table to the S7-1200. LEN is the total number of bytes (10 words = 20 bytes). ADDR_1 references the remote DB on the S7-1200 and must be fully qualified; this is configured in the S7-300 connection table as a "S7 connection" with the partner IP 192.168.0.20 and the partner rack/slot of the CPU 1212C.

For a partner on an S7-1200, the partner is referenced as:

• Partner TSAP: 03.01 (rack 0, slot 1) for the CPU 1212C's PROFINET interface.
• Local TSAP: 03.11 (any unused local TSAP).

S7-300 side (STEP 7 STL in OB1) for the reverse direction:

// S7 GET: read 10 words from S7-1200 DB201 into S7-300 DB101
CALL  "GET"
  REQ    :=M100.1
  ID     :=2
  DONE   :=M111.0
  ERROR  :=M111.1
  STATUS :=MW113
  ADDR_1 :=P#DB201.DBX0.0 WORD 10
  RD_1   :=P#DB101.DBX0.0 WORD 10
  LEN    :=20

S7-1200 side (TIA Portal SCL in OB1):

// Mirror the data from the S7-300 to the Modbus RTU I/O image
"DB_Bridge".CmdWord  :=  "DB_FromS7_300".CmdWord;
"DB_Bridge".Setpoint :=  "DB_FromS7_300".Setpoint;

The MB_MASTER or MB_SLAVE blocks (depending on whether the S7-1200 is master or slave on its own serial port) are then driven from DB_Bridge. For the architecture described, the S7-1200 typically does not need to participate on the same Modbus RTU segment as the DCS; it only needs to mirror the same process data through the S7-300.

11. RS485 Physical Layer for the Modbus RTU Trunk

The DCS-to-CP 341 segment is RS485 2-wire. The following physical-layer rules apply and are independent of the application program:

• Cable: shielded twisted pair, characteristic impedance ~120 ohm, e.g. Belden 3106A or equivalent. Maximum stub length 5 m to a node.
• Termination: 120 ohm resistor between D+ and D- at each end of the trunk. On the CP 341 -1CH01 the termination is enabled by a slide switch on the back of the module (T position) or by an external resistor on the screw terminals if the switch is not used.
• Bias: a pull-up to +5 V on D+ and a pull-down to GND on D- is required at exactly one point on the bus to hold the line in a defined idle state. The CP 341 -1CH01 does not provide bias internally; the bias must be added at the DCS end or at a repeater.
• Baud rate: match the DCS configuration, typically 9600 bit/s or 19200 bit/s for older DCS installations.
• Frame format: 8 data bits, even parity, 1 stop bit (8E1) is the most common Modbus RTU default.
• Inter-frame silence: 3.5 character times, enforced by both master and slave.

12. Commissioning Procedure

1. Pre-power checks: verify the CP 343-1 is fully seated in a free S7-300 slot and the backplane connector is clean. Verify the CM 1241 is seated in the signal board slot of the CPU 1212C.
2. RS485 wiring: land the DCS twisted pair on the screw terminals of both CP 341 modules. Confirm the shield is grounded at one end only (typically the DCS end).
3. Termination and bias: enable the 120 ohm termination on the far-end CP 341 (the one physically farthest from the DCS). Add a 680 ohm pull-up to +5 V on D+ and a 680 ohm pull-down to GND on D- at the DCS end.
4. Modbus RTU download: in STEP 7, load the Modbus slave driver into both CP 341 modules with identical parameters: 9600 bit/s, 8E1, unit IDs 1 and 2, register map 40001-40080 for process data.
5. CP 343-1 download: configure the IP address 192.168.0.11 and download the Ethernet configuration. Confirm the SF and BF LEDs are off after the first cycle.
6. S7-1200 download: in TIA Portal, configure the CPU 1212C IP address 192.168.0.20, enable PUT/GET, and download the project. Confirm the LINK LED on PROFINET port 0 is steady.
7. S7 connection table: in STEP 7 (or TIA Portal if migrated), define two S7 connections to the CPU 1212C: one for PUT (write) and one for GET (read). Use the IDs declared in the OB1 calls (ID = 1 for PUT, ID = 2 for GET).
8. DCS handshake: from the DCS engineering tool, force a poll of unit IDs 1 and 2. Confirm both CP 341s respond with valid diagnostics and the register values match the S7-300 process image.
9. PUT/GET smoke test: force a value in S7-300 DB100, word 0, and verify it appears in S7-1200 DB200, word 0. Force a value in S7-1200 DB201, word 0, and verify it appears in S7-300 DB101, word 0.
10. HMI test: from the HMI, read a tag that is mapped to the S7-1200 DB_Bridge and confirm it updates at the configured refresh rate. If the HMI is on the S7-1200 PROFINET port, confirm that the second port still has link to the CP 343-1.

13. Verification

After commissioning, the following checks confirm that the hybrid system is operating correctly:

• Modbus RTU segment: from the DCS engineering tool, force a poll of both CP 341 unit IDs (duty and standby) and confirm both respond with valid diagnostics. Check the S7-300 diagnostic buffer for CP 341 send/receive errors (event IDs 0x0202 and 0x0203 are typical of frame errors).
• Ethernet segment: from TIA Portal, perform "Go online" to the CPU 1212C and to the CP 343-1. Both should appear as "Reachable" and pass a ping test.
• PUT/GET: trigger a single PUT/GET cycle from the S7-300 and observe the DONE flag rising. Force a value into S7-300 DB100, verify it appears in S7-1200 DB200, and vice versa.
• LED pattern on the CP 343-1: SF (red) off, BF (red) off, LINK (green) steady, RX/TX flashing on PROFINET traffic.
• LED pattern on the CM 1241: if the CM 1241 is in use, its TX/RX LED should flash at the configured baud rate; if unused, its LEDs should be dark.
• HMI: confirm that the existing HMI on the S7-1200 PROFINET port still updates at its configured refresh rate. Adding the CP 343-1 to the S7-300 must not change the S7-1200's PROFINET network.
• Bus load: confirm Ethernet traffic is well below 50% of the 100 Mbit/s capacity during peak scans. Modbus RTU and Ethernet are independent segments, so a Modbus RTU problem cannot be caused by Ethernet load and vice versa.

14. Troubleshooting Matrix

15. Edge Cases and Field-Proven Caveats

• Existing CP 341 only supports the Modbus master or Modbus slave driver, not both at the same time. A single CP 341 cannot simultaneously be a slave to the DCS and a master to the S7-1200. The fix is to add the CP 343-1 and use Ethernet for the S7-300 / S7-1200 link.
• The CM 1241 -1CH32 supports Modbus RTU master and slave as a programming function block (MB_MASTER / MB_SLAVE), not as a firmware role. If the S7-1200 is added later to its own RS485 segment with other Modbus devices, the CM 1241 can act as a master; this is an additional segment and does not interfere with the DCS-to-CP 341 segment.
• TIA Portal version: the project for the S7-1200 and CP 343-1 (in a migrated S7-300) must be on a TIA Portal version that supports the S7-300 CPU firmware present. Verify the CPU 315-2AG10-0AB0 firmware version before upgrading TIA Portal.
• The S7-300's two CP 341 slots consume the same backplane bus; the CP 343-1 must be inserted in a free slot. Check the S7-300 rack configuration: the CPU 315-2DP/MPI supports up to four CPs in the central rack depending on the ordered variant.
• Hot-standby switchover does not propagate to the S7-1200 automatically. If the application requires the S7-1200 to know which CP 341 is currently the duty one, expose a status bit in the S7-300's PUT data that the S7-300 program updates based on the S7-CP 341 diagnostic interrupts.
• The CM 1241 -1CH32 module must be plugged into the signal board slot of the CPU 1212C (slot 101 in TIA Portal). Plugging into the signal board bay of an S7-1200 PM does not apply; it must be the CPU's signal board slot.
• Modbus RTU timing is sensitive to scan time. If the S7-300 OB1 scan time exceeds the Modbus inter-character timeout, the CP 341 may abort the response. Keep the S7-300 OB1 priority and cycle time predictable; use OB35 (cyclic interrupt) for time-critical tasks.
• Invensys DCS integration: confirm with the DCS vendor that the DCS treats unit IDs 1 and 2 as a redundant pair and not as two independent slaves that must be summed or averaged. A misconfigured DCS can produce wrong totals when both CP 341s are alive.
• Watch for the CP 341 -1CH01 firmware version. Earlier firmware (V1.x) had a known issue with 19200 bit/s and even parity; if CRC errors persist at 19200, drop to 9600 or upgrade the firmware.

16. FAQ