Connecting 20 Modbus RTU Devices to S7-300 PN/DP CPU via CP 341

Overview: Why an S7-300 PN/DP CPU Cannot Talk Modbus RTU Directly

An S7-300 PN/DP CPU (for example CPU 315-2 PN/DP, CPU 317-2 PN/DP, CPU 319-3 PN/DP) provides two integrated interfaces: an MPI/DP interface and a PROFINET interface. Both are Ethernet-class or RS-485 PROFIBUS-class industrial networks. Modbus RTU is a serial protocol that runs on RS-485 or RS-232 and is fundamentally incompatible with the PROFINET port of an S7-300 CPU. This is the root cause of the recurring question "can I connect my 20 Modbus RTU slaves to the PN port?" — the answer is no, you need an intermediate hardware element that performs the serial-to-PROFINET translation.

There are three engineering paths that Siemens officially supports or documents for this scenario:

1. CP 341 point-to-point / multi-drop serial module plugged into the S7-300 rack, loaded with the Modbus master driver (order number 6ES7341-1AH02-0AE0 or current 6ES7341-1BH02-0AE0 for RS-485). The CP 341 communicates on its serial backplane channel to the CPU and on the field side speaks Modbus RTU.
2. ET 200S 1SI serial interface module (order number 6ES7138-4DF01-0AB0) installed in an ET 200S station on PROFIBUS or PROFINET, used as either Modbus master or slave.
3. Third-party serial-to-Profinet gateway (for example a Phoenix Contact EWON, HMS Anybus X-gateway, or Wago 750-652). The S7-300 exchanges cyclic I/O with the gateway; the gateway polls the Modbus RTU slaves on its serial side and presents the data as PROFINET I/O slots/sub-slots.

For a station with 20 Modbus RTU slaves, the most common, supportable, and documented Siemens solution is the CP 341 with the "Modbus Master" parameterization. A single CP 341 supports up to 247 Modbus node addresses on its serial channel, so 20 slaves fit comfortably on one CP. If the 20 slaves are split across multiple RS-485 buses (different baud rates, different physical locations), plan one CP 341 per physical bus.

Prerequisites and Component List

Before commissioning, confirm the following hardware and software:

Where to Find the Modbus Connection Settings in STEP 7

In STEP 7 V5.x (the classic tool used for S7-300), the Modbus connection parameters for the CP 341 are configured in HW Config — not in NetPro, because Modbus RTU is a point-to-point protocol that the CP 341 terminates locally:

1. Open SIMATIC Manager → your S7-300 station → HW Config.
2. From the hardware catalog, insert the CP 341 into a free slot of the S7-300 rack (slot 4–11 typically, the CP must be adjacent to the CPU or in a valid slot).
3. Double-click the CP 341 to open its properties dialog.
4. Navigate to "Parameter Assignment" → "Protocol" and select "MODBUS master".
5. Click "Properties..." next to the protocol selection to open the Modbus parameter editor. This is where you set:
   • Baud rate (1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 — the slaves must match).
   • Parity (Even is the de-facto Modbus RTU default).
   • Data bits = 8, Stop bits = 1.
   • Response timeout (default 2000 ms is too long for a 20-slave poll; see the timing section below).
   • Number of retries (1–3 typical).

If you do not see "MODBUS master" as an option, the Modbus Master driver package has not been installed. Run the executable from the support download and re-launch HW Config; the option will appear in the protocol drop-down.

In TIA Portal V13 SP1 and later, the equivalent path is:

1. Project tree → Devices & networks → your S7-300 station.
2. Open Device view, locate the CP 341 in slots, double-click.
3. In the Inspector window select "Properties → General → Modbus master" and tick the activation box. Under "Protocol-specific parameters" configure baud rate, parity, character frame, and response timeout exactly as in STEP 7 V5.x.

The Modbus FB (MODBMA) is not visible inside HW Config — it is a function block that you drop into your OB1/OB35 cyclic program and call from user code. The block receives a job list (one entry per slave / per register range) and drives the CP 341 through FB 7 (P_SND_RK) and FB 8 (P_RCV_RK) internally.

Hardware Topology

The reference topology for 20 Modbus RTU slaves on one CP 341 is a classic RS-485 multidrop bus. The CP 341 is the master, each slave is addressed by a unique Modbus node address 1–247, and the bus is terminated at both ends with 120 Ω.

RS-485 practical limits at the most common Modbus RTU baud rate of 9600:

• Maximum cable length per segment: 1200 m (3937 ft), shielded twisted pair.
• Maximum number of transceivers per segment: 32 unit loads. If a slave has a 1/8 unit load transceiver you can place more devices on a single trunk; check the slave vendor datasheet.
• Maximum addressable slaves by Modbus protocol: 247 (address 1–247; 0 is broadcast). A single CP 341 can therefore theoretically poll 247 slaves.

Addressing: Node Address vs. Register Address

Modbus has two distinct "address" concepts that engineers often confuse:

For your 20-slave installation:

1. Give each slave a unique node address from 1 to 20 (leave gaps if you later want to add slaves; do not re-use addresses).
2. Read each slave's register map from its vendor datasheet. Look for the supported function codes — most modern instruments support FC 03 (Read Holding Registers), FC 04 (Read Input Registers), FC 06 (Write Single Register) and FC 16 (Write Multiple Registers).
3. In the CP 341 Modbus master job, you specify (slave address, function code, start register, length). The CP packages this into the Modbus ADU.

The "data exchange addresses" the user is asking about refer to where the received register values are stored in the S7-300 CPU after a poll completes. With the Modbus Master driver you choose one of two storage strategies:

• DB-based (recommended): each job reads N registers and writes them into a configured data block starting at a configurable offset. The user code does an uninterpreted "raw → engineering" conversion later.
• Process image (PAE/PAA): the CP 341 maps the first few registers into the I/O area. Useful for very simple mappings, not recommended for 20 slaves with multiple registers each.

Programming the Modbus Master FB (MODBMA)

The official "CP 341 Modbus Master" package provides FB 80 "MODBMA". The instance DB holds the entire job list. A minimum call looks like this:

// In OB1, called every cycle
CALL "MODBMA" , DB80
  REQ   := M10.0            // Trigger a single poll pass
  MODE  := B#16#01          // 0x01 = cyclic, 0x02 = single pass
  TIMEOUT := T#2S
  DONE  := M20.0            // 1-cycle pulse when scan completed
  ERROR := M20.1            // 1 = error, see STATUS
  STATUS:= MW22             // CP 341 status word
  JOB   := P#DB81.DBX0.0    // Pointer to job list (DB81 below)
  LEN_JOB := 40             // Length of job list in bytes
  RCV_DB := 82              // Receive DB for incoming data
  JOB_NO := MW24            // Job number currently executed
  JOB_STATUS := MW26        // Per-job error status

The job list (DB81) is a sequence of structures — one entry per slave/poll combination. A typical entry for one holding-register read on slave 5:

// DB81 — first 8 bytes = job header for slave 5
DBW0   := 5                  // Slave address = 5
DBB2   := B#16#03            // Function code 03 (Read Holding Registers)
DBW4   := 100                // Start address = 400101 (zero-based in MODBMA!)
DBW6   := 10                 // Number of registers to read = 10

For 20 slaves, build 20 entries. Place MODBMA in OB1 (cyclic) and the CP 341 itself will sequence the polls automatically. The DONE bit pulses when one full pass of the job list completes.

Throughput and Timing for 20 Slaves

The total cycle time of one pass over 20 slaves is the sum of all request-response round-trips plus inter-frame gaps. Use this back-of-the-envelope formula:

T_cycle = Σ_i [ (T_frame_request_i + T_frame_response_i + T_silence) / N_active_ports ] + N_retries · T_retry

T_frame ≈ (1 / baudrate) · (11 · N_bytes)   // 1 start, 8 data, parity, 1 stop, 11 bits/byte typical RTU

Worked example at 19200 baud, average of 8 holding registers per slave:

• Frame size: 8 bytes (request) + 21 bytes (response) ≈ 29 bytes × 11 bits = 319 bits/transaction.
• Transaction time: 319 / 19200 = 16.6 ms.
• Inter-frame silence (3.5 character times): 3.5 × 11 / 19200 = 2 ms.
• Per-slave round-trip ≈ 18.6 ms.
• Total for 20 slaves ≈ 372 ms, plus CP 341 internal scheduling ≈ 50 ms → about 420 ms per full cycle.

This is fast enough for supervisory HMI polling (typical refresh 1 s) and slow enough that you should not trigger MODBMA from OB1 with MODE 0x01 + 1 ms cycle — that would back up jobs. Instead, either set MODE to 0x02 and trigger REQ from a timer (e.g., 500 ms pulse) or trust the default cyclic behavior of the FB at OB1 with appropriate TIMEOUT.

If 420 ms is too slow because the HMI needs 100 ms refreshes on every value, you must either:

1. Lower the number of registers per slave and prioritize critical slaves in the job list (MODBMA executes jobs in the listed order).
2. Split the 20 slaves across two CP 341 channels.
3. Switch to Modbus TCP — but then your devices must also be Modbus TCP capable; the original question is about RTU.

Alternative Topology: ET 200S 1SI as Modbus Master on PROFINET

If you want the "PROFINET port" path the user asked about, the ET 200S 1SI module (6ES7138-4DF01-0AB0) plus the IM 151-8 PN/DP head (6ES7151-8AB01-0AB0) can be configured as a Modbus RTU master and presented to the S7-300 as a PROFINET I/O device. Each ET 200S 1SI channel polls up to 247 Modbus slaves. The user program in the S7-300 reads the ET 200S input words and writes to the output words exactly as if it were a normal PN I/O device. The advantage is that you use the CPU's PN port. The disadvantage is the additional programming effort in the ET 200S 1SI configuration tool ("ET 200S Serial" in TIA Portal or the standalone "Serial Interface Configuration Tool").

Alternative Topology: Third-Party Modbus TCP → Modbus RTU Gateway

A generic industrial gateway such as the Phoenix Contact FL GW MODBUS TCP/Modbus RTU (order number 1043197), HMS Anybus X-gateway Modbus TCP → RTU, or Wago 750-652 converts Modbus TCP on the Ethernet side to Modbus RTU on the RS-485 side. From the S7-300 CPU's perspective, the gateway is just another Modbus TCP partner. The PN port is then used directly for Modbus TCP communication — no CP 341 needed if the S7-300 is the master. The S7-300 sends Modbus TCP requests through the PN port to the gateway, which translates them to RTU on the serial side. Note: this changes the protocol on the field side to be initiated by the S7-300 acting as a Modbus TCP client. The CPU does not speak Modbus TCP natively either — you need the Open Communication (OC) blocks (FB 100–105 / FB 200–205 in STEP 7 V5.x "Standard Library → Communication Blocks → Open Communication"), or use the Modbus/TCP library from Siemens application example entry 109739916.

STEP 7 vs. TIA Portal: Where the Modbus Settings Live

For an S7-300 system originally programmed in STEP 7 V5.x and migrated to TIA, both tools expose the same parameters — the migration is lossless as long as the CP 341 driver library is also imported.

STEP 7 / TIA Commissioning Checklist

1. Install the CP 341 in the rack. Insert the license dongle on the CP or assign the license via ALM.
2. In HW Config, set the CP 341 protocol to "MODBUS master" and configure baud rate, parity, character frame and response timeout.
3. Save and download the hardware configuration to the CPU.
4. Open the project example for the CP 341 Modbus Master (entry 109474714) and copy FB 80, FB 7, FB 8, UDT 1, and the example DBs into your project.
5. Adjust the instance DB and job list to match your 20 slaves. Map the receive DB register ranges to your process DB.
6. Download the program. Open the "Modbus Master" online diagnostics in STEP 7 (right-click the CP 341 → "Modbus Master Diagnostics") to view live job counters and error statistics.
7. Use the "Modbus Master Trace" to capture the actual byte stream on the RS-485 side; cross-check with the slave vendor's Modbus scanner if the first poll returns an exception.

Verification: How to Confirm the 20 Slaves Are All Online

Use the following checklist before commissioning the HMI/SCADA layer:

Troubleshooting Matrix

OPC Connectivity from the S7-300 to a Free OPC Server (WinCC Flexible / WinCC)

The follow-up question asks about a free OPC server for WinCC SCADA / WinCC Flexible. With an S7-300 PN/DP and the CP 341 polling Modbus slaves, the data ends up in a DB in the CPU. Any OPC server that supports S7 communication over MPI/PROFINET can then expose that DB to the SCADA:

• Siemens SIMATIC NET OPC Server (SOFTNET-S7 / S7-PN) — licensed, comes with SIMATIC NET; not free but the standard option for WinCC Flexible/Professional.
• LibNoDave / Snap7 — open source libraries that talk S7 protocol; they are not commercial OPC servers, but you can wrap them in a custom OPC UA server using open62541 or Node-OPCUA.
• OPC UA Wrapper for S7 (e.g., the open-source "S7-OPC-UA-Bridge") — community packages, not officially supported by Siemens.

If the goal is purely to feed WinCC Flexible HMI panels on the same PN network, you do not need an OPC server at all. WinCC Flexible (or WinCC Comfort/Professional) can read DB tags directly from the S7-300 over PROFINET using a "SIMATIC S7-300/400" connection in the HMI tag management. The CP 341 data is already in the CPU's DB — the HMI simply tags it.

Notes on Variant Approaches (Decision Matrix)

FAQ