Adding a Second MPI Port to S7-300 CPUs Network Segmentation

Overview

Engineers maintaining legacy SIMATIC S7-300 installations frequently run into a hard architectural limit: a single CPU exposes exactly one MPI/DP port, and there is no SIMATIC CP for MPI. The classic symptom is a panel network of HMIs plus several CPUs all sharing one MPI segment using global data communication, where the goal is to split PLC traffic from HMI traffic into two physically separate networks. Because S7-300 CPs only support PROFIBUS DP, Industrial Ethernet / PROFINET, and point-to-point serial links, the resolution is never "add a CP for MPI" but rather "replace the MPI layer with one of the supported fieldbuses". This reference consolidates the constraints, the available CPs, the cabling rules, and the migration path that lets you keep an S7-315 in service while splitting the segment.

S7-300 Communication Architecture

The S7-300 family is built around a backplane bus and a fixed set of CPU-internal interfaces. Every standard S7-300 CPU (CPU 312 through CPU 319, including the CPU 315 referenced in the source scenario) ships with exactly one combined MPI/DP interface on the front of the module. The same X1 connector is software-selectable between MPI and PROFIBUS DP master operation; it cannot be both simultaneously, and it cannot be split into two ports.

The CPU-internal interface operates at 187.5 kbit/s in MPI default mode and can be raised to 12 Mbit/s when reconfigured as DP master on DP-capable CPU variants. The S7-315 (6ES7 315-xxx-xx-xx) ships in both MPI-only and DP variants; the DP variant is the practical choice whenever any external DP slave or PROFIBUS CP must coexist on the same CPU.

The Dual-MPI Limitation

There is no way to add a second MPI port to an S7-300 CPU. The S7-300 hardware does not expose a second MPI-capable connector at the CPU, and Siemens does not manufacture a CP that speaks MPI as a slave or master. The question "can I add a second MPI port" therefore has a definitive answer: no. Any attempted workaround using a third-party gateway that emulates MPI on a non-Siemens protocol is not supported in STEP 7 and will break global data, S7 basic communication, and S7 communication bindings that the existing HMIs and CPUs depend on.

Why a CP for MPI Does Not Exist

MPI was designed as a low-cost, low-speed (187.5 kbit/s default) tie-line between engineering stations, HMIs, and a small cluster of CPUs, never as a fieldbus. Siemens' product roadmap moved MPI traffic onto PROFIBUS DP (when CPU 31x-2 DP variants are used) and onto Industrial Ethernet (when CP 343-1 modules are added) from the early 2000s onward. The CP catalog reflects this: every S7-300 CP targets one of those three real fieldbuses, never MPI.

The relevant CPs for the S7-300 are:

The CP 342-5 Question: Can It Speak MPI?

The CP 342-5 is a PROFIBUS DP module only. Its firmware implements DP-V0 master/slave and DP-V1 master/slave, plus PG/OP routing and S7 communication over PROFIBUS. It does not implement the MPI token-ring protocol, it does not participate in MPI global data circles, and it cannot be addressed by an HMI as an MPI node. The CP 342-5 replaces a CPU's DP master function on the backplane side, but on the field side it speaks PROFIBUS DP frames, not MPI.

This is precisely why the source scenario cannot be solved with CPs alone if the HMIs are required to keep talking MPI: there is no CP that bridges an HMI's MPI traffic into the CPU. The only way to honor the "separate the HMI MPI network from the PLC PROFIBUS network" requirement is to migrate the HMIs to a bus the CPU can serve with a CP.

Segmentation Strategy: Keep the PLCs on PROFIBUS, Move HMIs to Ethernet

The most cost-effective split for an existing S7-300 fleet is to use PROFIBUS DP for inter-CPU traffic and Industrial Ethernet for HMI traffic. The CPs required are a CP 342-5 in each CPU that must speak PROFIBUS DP to its peers, and one CP 343-1 Lean per CPU that must serve HMIs.

1. Inventory nodes. List every CPU and every HMI on the existing MPI segment with their current MPI addresses and the highest baud rate supported (typically 187.5 kbit/s for older panels, 1.5 Mbit/s for newer MP/TP panels).
2. Re-architect the network. Design a PROFIBUS DP segment (1.5 Mbit/s is a safe default for mixed S7-300 fleets) carrying the six PLCs. Design an Industrial Ethernet segment (100 Mbit/s, switched) carrying the HMI fleet.
3. Select CPs per CPU. For each CPU that must speak PROFIBUS DP to a peer CPU, slot a CP 342-5. For each CPU that must serve HMIs, slot a CP 343-1 Lean. A single CPU can host both CPs simultaneously because the S7-300 backplane supports up to four CPs per station.
4. Switch X1 to MPI (default) or DP. If the CPU is a 31x-2 DP variant and one segment is the X1 port itself (for example, a programming terminal), decide in HW Config whether X1 stays MPI for PG access or is reconfigured as DP master. The chosen role must be consistent with the CP slots; do not attempt to run X1 as DP master while a CP 342-5 is also configured as DP master on the same CPU without planning the bus topology carefully.
5. Re-engineer HMI connections. In each HMI project, change the connection type from "S7 MPI" to "S7 Ethernet (ISO-on-TCP)" or "S7 Ethernet (TCP/IP)" and point the partner IP at the new CP 343-1 Lean's IP address. The HMI's connection timeout and retry settings should be revisited; Ethernet fail-fast is much faster than MPI retry, so alarm damping in the HMI may need adjustment.
6. Re-engineer CPU-to-CPU bindings. In STEP 7, replace any PUT/GET, BSEND/BRCV, or global data definitions that used MPI with the equivalent PROFIBUS bindings (PUT/GET over S7 connection routed by CP 342-5). The CP's connection resources must be sized: a CP 342-5 typically supports 16 S7 connections, of which several are reserved for PG/OP routing.
7. Segment the networks. The PROFIBUS DP segment must follow RS-485 rules: terminated at both ends (terminator on), drop cables short, baud rate 1.5 Mbit/s gives 100 m of trunk per segment at this rate; longer trunks need repeaters or a fiber CP 342-5 FO. The Ethernet segment must be switched, with HMIs and CPU CPs in the same VLAN or subnet and any router/firewall configured to permit ISO-on-TCP (port 102) and S7 communication (port 102 for ISO, 2000+ for some TCP variants).

Keeping the HMI on MPI by Moving the PLCs to DP

The mirror image of the previous strategy is also valid and is often cheaper if the panel fleet is large and the HMI panels are legacy MPI-only (OP/TP177, MP270, MP370, older TP). In this layout the X1 port on each CPU is switched to PROFIBUS DP master (a configuration change in HW Config, requires a STOP download), the six CPUs communicate over a single PROFIBUS DP trunk, and the HMIs continue to talk MPI to a single gateway CPU. The disadvantage is that the gateway CPU becomes a single point of failure for HMI visibility. The mitigation is to size the gateway CPU's MPI resources carefully and to enable PG/OP routing on the CP 342-5 so that engineering stations can still reach all CPUs through the gateway.

This pattern is the most common field retrofit when a plant cannot afford to replace 20 MPI panels but can afford one CP 342-5 per CPU.

Configuration Parameters to Verify

Configuration Snippet: Replacing an MPI PUT with a CP 342-5 PUT

The STEP 7 STL below is the typical SFC 67 (X_GET) call that the source plant would have used across MPI. After the network is split, the same function is reachable over a CP 342-5 with no change to the block instance: the CP handles transport, the SFB/SFC stays the same.

// Read 20 bytes from DB100 in the partner CPU via S7 connection
// routed by CP 342-5 (connection ID = 1, established in NetPro)

      CALL  "X_GET" , DB115
           REQ    :=TRUE                // Trigger on rising edge
           CONT   :=TRUE                // Connection held in NetPro
           DEST_ID:=W#16#0001           // Connection ID from NetPro
           VAR_ADDR:='DB100.DBB0'       // Partner DB, byte 0
           SD     :=P#M 100.0 BYTE 20   // Local source: 20 bytes from MB100
           RET_VAL:=MW 120              // Error code (see mapping below)
           BUSY   :=M 122.0

RET_VAL decoding follows the standard S7 mapping. Common values seen on PROFIBUS PUT/GET through a CP 342-5:

Verification Procedure

1. Bus diagnostic from a PG. With STEP 7 connected to the bus, open "Accessible Nodes" on the new PROFIBUS segment. Every CPU with a CP 342-5 should appear with the configured PROFIBUS address and a green status. Any "not reachable" entry means the CP slot, address, or termination is wrong.
2. CP diagnostic buffer. In HW Config, right-click the CP 342-5 and open "Module Information". The diagnostic buffer must show no "Station failure" or "Bus fault" entries. The CP's SF/BF LEDs must both be off.
3. Connection status. In NetPro, the configured S7 connections on the CP 342-5 must show "established" for online operation. Online > "Monitor/Modify" on the connection gives a per-connection status byte; 0x04 (established) is the expected value.
4. HMI ping test. From each HMI panel, use the diagnostic page to ping the CP 343-1 Lean's IP address. A successful ping rules out cabling and IP configuration. Then trigger a tag read on a known DB; a value mismatch means the HMI connection pointer or the DB number is wrong, not the network.
5. Soak test. Leave the panel fleet running for at least one full shift with no operators on the system, capturing CP 342-5 diagnostic buffer snapshots every 30 minutes. Any "connection aborted" or "station failure" entry reveals a flaky termination or an undersized power supply on a remote segment.

Troubleshooting Matrix

Cost and Migration Notes

The original design relied on MPI global data, which is a Siemens-proprietary broadcast of small data packets (up to 22 bytes per GD packet) between CPUs on the same MPI segment. This pattern does not survive a move to a CP-based architecture: there is no GD equivalent on a CP 342-5. Every GD circle must be re-implemented as one or more S7 connections carrying PUT/GET. For 22-byte data this is a small refactor; for larger shared structures it is often cheaper to use a coordinated DB on a designated coordinator CPU and have peers read/write it via PUT/GET.

A typical retrofit for the source scenario (one CPU 315 + five peer CPUs + one shared CPU on both segments) ends up with:

• 5 x CP 342-5 for inter-CPU PROFIBUS
• 1 x CP 342-5 for the shared CPU's PROFIBUS leg
• 1 x CP 343-1 Lean for the shared CPU's HMI leg (Ethernet)
• HMI panel project re-engineered to S7 Ethernet (ISO-on-TCP)
• GD definitions replaced with PUT/GET S7 connections in NetPro

This is materially cheaper than the "3 or 4 CP 342-5 per CPU" worst case the source author anticipated, because the CPUs that only need to talk to peers can keep a single PROFIBUS segment with one CP 342-5 each, and the HMI side is consolidated onto one Ethernet segment with one CP 343-1 Lean in the gateway CPU. The HMI panels that must remain MPI can stay on a small MPI sub-segment terminated at the gateway CPU's X1 port.

Standards and Reference Documentation

The S7-300 system manual, the CP 342-5 manual, and the CP 343-1 Lean manual are the authoritative references for the parameters above. The CP 342-5 manual documents the operating modes (DP master, DP slave, S7 client/server), the connection resource limits (16 S7 connections per CP, of which 4 are reserved for PG/OP routing in older firmware revisions), and the diagnostic buffer structure. The CP 343-1 Lean manual documents the PROFINET IO controller limit (1 controller, 0 devices on the Lean variant) and the IT function exclusions. PROFIBUS physical-layer rules are covered in IEC 61158-2 and the PROFIBUS Installation Guideline from PI (PROFIBUS & PROFINET International). Industrial Ethernet physical-layer rules are covered in IEEE 802.3.

For general background on the MPI acronym (which is heavily overloaded with the high-performance computing Message Passing Interface standard), the two additional research items provided are not relevant to industrial MPI on SIMATIC and should be treated as homonyms. The SIMATIC MPI is a Siemens-proprietary RS-485 protocol at 187.5 kbit/s default, not the HPC standard.

FAQ