S7-1200 to S7-400H Redundant PROFINET Communication Setup

1. Overview

Connecting a SIMATIC S7-1214C (firmware V4.0 or higher) to a SIMATIC S7-412-5H high-availability system requires explicit design choices because the two platforms handle redundancy at different layers. The S7-400H pair provides controller-level redundancy with sub-100 ms bumpless failover through fiber-optic sync modules; the S7-1200 is a single-CPU device and cannot itself be redundant. The redundancy in this scenario is therefore link-level on the PROFINET segment and connection-level in the application: only one S7-400H CPU is the active partner at any time, and the S7-1200 application must tolerate (or hide) the brief switchover.

This reference consolidates the field-proven options, explains why Media Redundancy Protocol (MRP) and PROFINET system redundancy (S2) are not directly usable with an S7-1200 in this role, and walks through the S7-communication configuration with PUT/GET and the T-block family that the S7-400H can use to back up the S7-1200 partner address.

2. S7-400H Redundancy Architecture

The S7-400H is a hot-standby system built around two identical H-type CPUs (e.g. 412-5H, 414-5H, 416-5H, 417-5H) sharing one SIMATIC S7-400H rack or two racks connected by sync-module fiber-optic links. The two CPUs run in parallel; one is the master, the other is the reserve. Event-driven synchronization keeps both internal image, program counter, and tag values aligned so that a fault on the master causes the reserve to take over at the exact instruction boundary without losing process state.

From the outside (an S7-1200, an HMI, or a SCADA client), the system presents itself as a single IP endpoint. The PROFINET device name and IP of the master are normally the ones the S7-1200 configures as the partner. Internal H-system mechanisms such as the backup HMI connection (H-CPU partner IP) and the system IP give a single, fixed address for the active CPU.

Reference: SIMATIC S7-400H Fault-Tolerant Systems (Entry ID 82478488) and the S7-400H System Manual (Entry ID 90885106).

3. PROFINET Redundancy Options Compared

PROFINET defines several redundancy mechanisms. Only some are usable when an S7-1200 sits at one end of the link.

The Cisco IE9300 documentation describes PROFINET system redundancy modes and is useful background on how AR (Application Relationship) and CRP (Communication Relation Protocol) handle failover, although the S7-1200 endpoint is not a candidate for S2 itself: PROFINET System Redundancy - Cisco IE9300 Configuration Guide.

4. Why the S7-1200 Cannot Be an MRP Manager

MRP requires one node in the ring to take the role of MRP manager. The manager sends test frames and reconfigures the ring on link loss. To act as MRP manager, a device must support the MRP manager role in its PROFINET stack, and the typical S7-1200 CPU ships with MRP client support only - it can participate in a ring managed by a switch such as a SCALANCE XC-200, XC-300, or a third-party managed switch, but it cannot itself be the ring manager.

Even when an S7-1200 variant (e.g. CPU 1215C, CPU 1217C) exposes two physical RJ-45 ports labeled PN1 and PN2, these share a single PROFINET interface internally (one MAC, one IP, one device name). They cannot be split into two independent PROFINET interfaces that each carry their own MAC, which is a prerequisite for acting as an MRP manager with a second port or for a true S2 device.

Field consequence: the typical topology is a linear or star PROFINET segment with a managed switch at the center. The S7-1200 connects once to that switch; the switch may then either (a) sit in an MRP ring together with the two H-CPUs' PROFINET ports or (b) connect both H-CPUs through separate switch ports for S7-400H internal redundancy only.

5. Communication Protocol Selection

Three protocol families are available in TIA Portal V15 and later, with the following support matrix against S7-400H.

Recommendation: Use PUT/GET for the simplest configuration. Use T-blocks when (a) the data volume per cycle is large and you need stream-style transfer with sequence checking, or (b) you want the connection to terminate on a user-defined TCP port and a partner IP you can swap on the fly.

6. PUT/GET Configuration Procedure

The S7-1200 can be either the client (issuing PUT/GET) or the server (responding to PUT/GET). For S7-400H redundancy, the client role is the easier choice: the S7-1200 actively reconnects after an H-failover, while the server role on the H-system is bound to a single physical CPU at a time.

6.1 Prerequisites

• TIA Portal V16 or later (V15 SP1 is the minimum for some 412-5H FW 6.0 features)
• S7-1200 CPU firmware V4.2 or later (V4.4 recommended for the latest PUT/GET reliability fixes)
• S7-412-5H firmware V6.0 or later (V6.0.7 or later recommended for the H-system IP partner-substitution behavior)
• S7-400H is configured as an H-station with both CPUs at the same FW level
• PROFINET network: managed switch (e.g. SCALANCE XC-200) with both H-CPU ports and the S7-1200 port connected

6.2 Step-by-step on the S7-1200 (TIA Portal)

1. Open the S7-1200 project, then Devices & Networks > Networks view > Connections.
2. Select S7 connection as the connection type.
3. Set Local end = S7-1200, Partner end = the S7-400H station. Enter the H-system IP (system IP) or the partner IP of the H-station as the partner address.
4. Activate the Establish active connection check box on the S7-1200 side; the H-system is passive.
5. From the Ladder / FBD / SCL editor, drop PUT or GET into a cyclic OB (e.g. OB1 or OB35).
6. On the connection configuration, ensure the partner interface is the PROFINET interface of the S7-400H (slot 0 / interface X1 / X2 depending on rack).
7. Compile and download to the S7-1200.

6.3 Step-by-step on the S7-400H (TIA Portal, H-station)

1. Open the H-station project, verify that the H-system is enabled: Properties > System > H operation must show both H-CPUs configured.
2. Set the system IP (H-system identifier) under Properties > PROFINET interface > Ethernet addresses. The S7-1200 partner address must be this system IP, not the IP of CPU0 or CPU1.
3. Verify that the S7 connection is configured as unspecified on the H-side; the active endpoint is the currently master CPU.
4. Compile and download both H-CPUs; perform the H-system download (separate for each CPU in the correct order - first CPU 0, then CPU 1, or use the bulk H-download in TIA Portal).
5. Switch to run on both CPUs and confirm green RUN / RUN-R on both.

6.4 The "no optimized DB" rule

When the S7-1200 uses PUT/GET as a server, the data blocks that the partner reads or writes must be non-optimized. With Optimized block access enabled (the default for new DBs in TIA Portal), the partner CPU cannot resolve symbolic addresses and PUT/GET returns STATUS = 0x81 (or the S7-1200 returns DONE=0, ERROR=1, STATUS = 80C3 / 80B1 depending on firmware).

Fix: open the DB on the S7-1200, Properties > Attributes, uncheck Optimized block access. Recompile, reload. The absolute addresses are now stable, and the PUT/GET operand list on the S7-400H side must reference those absolute addresses, e.g. DB100.DBB0, DB100.DBW2.

7. T-Blocks for Hot-Standby Transfer

The S7-400H can act as a TCP server using TSEND / TRCV (FB63 / FB64) or the unsolicited variants TUSEND / TURCV (FB65 / FB66). The S7-1200 uses TSEND_C and TRCV_C from the Instructions > Communication > Open User Communication palette.

Configuration of the connection on the S7-1200:

• Connection type: TCP
• Partner IP: H-system IP (system IP of the S7-400H)
• Partner port: e.g. 2000 (must match the S7-400H TCON IDB port)
• Local port: 0 (any) or a fixed port for firewall purposes
• Active connection establishment: true on the S7-1200 side

Behavior on H-failover: the TCP connection terminates when the master CPU stops processing. The reserve CPU is now the active one but the TCP endpoint is fresh; it must accept a new connection from the S7-1200. The S7-1200's TSEND_C with CONT=1 will retry; the connection re-establishes in tens of milliseconds. There is no data loss on the application side provided the S7-400H application uses T-blocks in the program on both H-CPUs (the reserve's T-blocks become the new active path automatically).

8. Network Topology

Two topologies are field-proven.

Topology A (above): linear / star through a single managed switch. The S7-1200 has one path. The S7-400H is internally redundant.

Topology B: the two H-CPUs sit in a PROFINET MRP ring with the managed switch as MRP manager. The S7-1200 connects to the switch off the ring, or as an MRP client on the ring. Ring failure between the switch and one H-CPU is recovered in < 200 ms.

9. H-System Failover Behavior from the S7-1200 Side

When the S7-400H master fails (PROFIBUS / PROFINET fault, CPU stop, hardware fault), the following sequence is observable on the S7-1200:

1. 0 ms - master CPU enters STOP or fault state; reserve begins master-takeover.
2. ~50-100 ms - reserve is the new master. The PROFINET stack on the new master is fresh. Existing TCP connections (S7 connection or T-block) are terminated with FIN / RST.
3. ~100-500 ms - the S7-1200 sees the connection close. The PUT / GET block reports ERROR=1, STATUS = 0x80C3 / 0x8181 (resource error, partner not reachable). TSEND_C with CONT=1 reports BUSY until the connection is re-established.
4. ~500-2000 ms - the S7-1200 opens a fresh S7 or TCP connection to the H-system IP. DONE=1 on the next call.

Application implication: the S7-1200 program must debounce or filter the connection error for at least 2 seconds and keep the last good process values in a non-volatile DB (retentive marker area, MB0-MB15, or a non-optimized DB with Enable retain). Alarm bursts on the HMI side are common during the first second.

10. Diagnostics and Troubleshooting Matrix

11. Verification and Commissioning

After configuration, perform the following verification on the live system before sign-off:

1. Online connection test: in TIA Portal, right-click the S7-1200, Online & Diagnostics > Accessible devices, confirm the H-system IP responds. Repeat for both H-CPUs' individual IPs to confirm the rack is alive.
2. Bidirectional PUT/GET test: write a test value from the S7-1200 to a non-optimized DB on the S7-400H, and from the S7-400H back to a different non-optimized DB on the S7-1200. Verify both data flows with the HMI or STEP 7 watch table.
3. Forced failover test: in TIA Portal on the H-station, run Online > H-station > Master-Changeover. Observe on the S7-1200: connection drops, STATUS=0x8181, recovers within 2 s, DONE=1 on the next call.
4. Network fault test: physically disconnect the PROFINET cable from the active H-CPU. The S7-400H should switch to the reserve within a few hundred milliseconds; the S7-1200 application should remain alive.
5. Sync-link pull test: pull one sync-module fiber. The H-system enters solo mode; the S7-1200 sees a normal operating state (no failover) but the H-station alarms. Document the alarm handling.
6. Retain / restart test: cycle power on the S7-1200 with Retain enabled on the relevant DBs. After restart, the connection to the H-system is rebuilt automatically; no reconfiguration is required.

12. Frequently Asked Questions