Configuring S7-412-2PN PROFINET CPU-to-CPU Data Exchange

Overview

The Siemens SIMATIC S7-412-2 PN is a mid-range CPU in the S7-400 family that provides an integrated two-port PROFINET switch on front connector X1 in addition to the integrated PROFIBUS DP master/slave interface on X2. Pairing two 412-2 PN CPUs in a single plant is a common architecture: one CPU acts as the cell-level controller, the second handles a sub-cell or a redundant process area, and both must share process data in near real time.

Two practical methods are available for CPU-to-CPU data exchange on this hardware, and the right choice depends on the origin of the data and on the required read/write symmetry:

1. S7 communication over the integrated PROFINET interface using PUT/GET with shared data blocks as the exchange buffer.
2. Direct Data Exchange (internode communication) where the input image of a DP or PN slave configured on one CPU is read by the second CPU without adding extra wiring or a duplicate I/O module.

This reference covers both methods, the configuration steps in STEP 7 V5.x and in TIA Portal, the shared-DB layout that prevents the two CPUs from corrupting each other's data, the HMI connection pattern that surfaces the shared data on a panel, and the diagnostic procedure for connection establishment and abort events on the 412-2 PN. For a single cabinet, the integrated PROFINET switch of each CPU is enough – no external switch, no additional CP.

System Topology and Constraints

The reference layout uses two SIMATIC S7-412-2 PN stations, one TP/TP-Comfort HMI panel, and one PROFINET cable between the two CPUs. The HMI is connected to the same subnet so that one PG/PC can reach both CPUs for commissioning and online diagnostics.

Three constraints apply to a 412-2 PN pair on this topology:

For CPU-to-CPU application data exchange (DB-to-DB), Approach 1 (PUT/GET over PROFINET) is the preferred architecture because it provides full read/write symmetry and does not depend on the topology of the distributed I/O.

Approach A: S7 Communication with PUT/GET over PROFINET

Both 412-2 PN CPUs sit on the same PROFINET subnet. Each CPU holds the S7 connection table for the other. Data exchange uses the standard S7 communication function blocks from the STEP 7 standard library:

• FB 14 "GET" – read a partner DB area into a local DB area.
• FB 15 "PUT" – write a local DB area into a partner DB area.
• SFB 14 / SFB 15 – system FB equivalents built into the S7-400 firmware. No instance DB required.
• SFB 8 / SFB 9 (USEND / URCV) and SFB 12 / SFB 13 (BSEND / BRCV) for unacknowledged or segmented transfer of large volumes.

Direction of data flow is symmetric: either side can issue a PUT or a GET. For deterministic updates, schedule the call in OB 1 (cyclic main) or in a watchdog OB (e.g. OB 35) and check the status outputs (ERROR, STATUS) for handshake errors. The STATUS word follows the IEC 61131-3 error model; non-zero STATUS means a communication error and must be alarm-logged.

Required CPU-side configuration

1. In the CPU properties under "Protection & Security" or "Communication" (depending on the engineering tool release), enable the option "Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, ...)". Without this flag, PUT/GET from another S7 CPU is rejected with a partner-rejected error (STATUS 0x000A) at the FB output.
2. Define the partner CPU as an "S7 connection" in the NetPro (STEP 7 V5.x) or "Devices & Networks" (TIA Portal) editor. The connection is configured on one CPU and downloaded to both; STEP 7 / TIA mirrors the connection configuration to the partner automatically.
3. Reserve enough free S7 connection resources. PG, OP/HMI and the CPU-CPU S7 connection all consume resources from the same pool – on a 412-2 PN this pool is small and must be planned in advance.

PUT/GET call example (Structured Text, STEP 7 V5.x)

// Call once per OB 1 cycle; the FBs use the connection configured in NetPro
IF "i_Cyclic_OK" THEN
  // GET from partner CPU: read DB100.DBD0..19 into DB200.DBD0..19
  "iDB_GET"(REQ   := TRUE,
            ID    := 1,                   // local connection ID from NetPro
            ADDR_1:= P#DB100.DBX0.0 BYTE 20,
            RD_1  := P#DB200.DBX0.0 BYTE 20,
            ERROR => "get_err",
            STATUS=> "get_status");
  // PUT to partner CPU: write DB201.DBD0..19 into DB101.DBD0..19
  "iDB_PUT"(REQ   := TRUE,
            ID    := 1,
            ADDR_1:= P#DB101.DBX0.0 BYTE 20,
            SD_1  := P#DB201.DBX0.0 BYTE 20,
            ERROR => "put_err",
            STATUS=> "put_status");
END_IF;

Approach B: Direct Data Exchange (Internode Communication)

When the data to be shared is the input image of a DP or PN slave that physically belongs to the I/O of one CPU, Direct Data Exchange (German: "Direkter Datenaustausch") lets the second CPU read the same input image without a second wiring run or a second physical I/O module. The slave is configured on one master only; the other master declares the slave as a publisher and reads its inputs through the backplane of the bus.

Per Siemens FAQ 17660809, S7-400 CPUs support the Direct Data Exchange function. For PROFIBUS, the same FAQ identifies which IM 153-x interface module variants can publish their input images to a second master. For PROFINET, the equivalent function is provided by the "Shared Device" or by PROFINET IO device sharing with the appropriate I-device configuration; the underlying semantics – inputs are shared, outputs are not – are identical.

Ownership rule per Siemens FAQ 19081112:

• Inputs of a DP / PN slave can be read by more than one master.
• Outputs of a DP / PN slave can only be written by the master that configured the slave.

Use Direct Data Exchange when the second CPU only needs visibility into the input image (status, measurements, alarms) and the slave physically sits in the field near the second CPU. Use S7 communication with PUT/GET when the second CPU must also command outputs on slaves that belong to the first CPU, or when the shared data is application data that originates inside one of the CPUs (recipe parameters, sequence state, hand-shake flags).

CPU 412-2 PN Hardware and Firmware Considerations

The CPU 412-2 PN exists in several firmware releases. The PROFINET-enabled order number 6ES7412-2EK07-0AB0 represents the most recent PROFINET generation of the 412-2 family. Earlier PROFINET variants (for example 6ES7412-2BN02-0AB0) implement a single PROFINET port and have a smaller connection resource table. Always confirm the exact MLFB printed on the front panel against the firmware version selected in the hardware catalog before downloading the project.

For the exact numbers refer to the S7-400 CPU 412-2 PN manual in the Siemens Industry Online Support portal, search for the order number of the unit installed. The total connection pool is shared between PG, OP/HMI, the CPU-CPU link, OPC UA, and any open user S7 connections – budget these resources at design time, not at commissioning.

Configuring the PROFINET Connection

The configuration sequence differs between STEP 7 V5.x (classic) and TIA Portal. The procedure below covers both.

STEP 7 V5.x (NetPro)

1. Place two SIMATIC 412-2 PN stations in the project, each in its own S7-400 rack (UR1 or UR2).
2. Open the CPU properties of each station. On the Interface tab for PROFINET (X1), assign a unique IP address on the same IP subnet, e.g. 192.168.0.10 (CPU-A) and 192.168.0.11 (CPU-B), subnet mask 255.255.255.0.
3. Assign unique PROFINET device names, e.g. cpu412a and cpu412b. PROFINET device naming must be unique on the subnet even when the link is only used for S7 communication.
4. Open NetPro. Insert a new S7 connection. Select unspecified partner if the partner CPU is in a separate STEP 7 project; select the partner CPU directly if both stations are in the same project. The connection is mirrored to the partner automatically.
5. On the General tab of the connection, set the local connection ID (used as the ID input to PUT/GET). STEP 7 suggests an ID; write it down.
6. Download the hardware configuration and the connection configuration to both CPUs.

TIA Portal (Devices & Networks)

1. Create two S7-400 stations with a CPU 412-2 PN each.
2. In Devices & Networks, drag a PROFINET subnet onto the topology. Connect the two CPU PROFINET ports (X1 P1 – X1 P1, or X1 P1 – X1 P2 on the integrated switch).
3. In the CPU properties, set the IP address, subnet mask, and PROFINET device name for each station.
4. Right-click the first CPU and select Add new connection > S7 connection. Choose the second CPU as partner. TIA Portal assigns a local connection ID; note it for the PUT/GET call.
5. Compile and download the project to both CPUs.

Use the Accessible Nodes tool (STEP 7) or Online & Diagnostics > Online access (TIA) to verify that each CPU can browse the partner from its own integrated PROFINET interface. If the partner is not visible, check the switch port LEDs on the CPU front, the PROFINET device name assignment, and the PG/PC interface selection on the engineering station. A common commissioning error is the PG attached to the wrong CPU while the user assumes it sees both.

Shared DB Layout and Data Consistency

For data exchange with PUT/GET, define a shared DB on each CPU with a fixed byte-aligned structure. The partner accesses the DB by absolute address, so the DB must be not optimized access (in TIA Portal: uncheck Optimized block access) and must not use multi-instance declarations. Symbolic-only blocks are invisible to PUT/GET from a remote CPU.

// Shared receive DB on CPU-A (DB 200): written by PUT from CPU-B
DATA_BLOCK "DB_CpuA_From_B"
{ S7_access := 'DB200' }
VERSION : 0.1
STRUCT
  Heartbeat   : BOOL;   // running flag from partner
  Status      : WORD;   // partner status word
  Pressure    : REAL;   // process value
  Setpoint    : REAL;   // process value
  SeqID       : DWORD;  // rolling counter for diagnostics
END_STRUCT;
END_DATA_BLOCK

On the sending side, write the same offsets into the partner DB. For the rolling counter, increment a local DWORD in OB 35 (cyclic 100 ms) and copy it to the shared send DB. The receiving CPU compares the counter to detect lost or duplicated messages; a non-monotonic counter on the receiver indicates that a PUT was missed during a link outage.

Programming the Data Exchange

Calling PUT/GET once per OB 1 cycle is the most common pattern, but the cycle time of both CPUs must be considered. With a 50 ms OB 1 on each side, the worst-case data latency across the link is in the order of:

L_max ≈ 2 × T_OB1 + 2 × T_PROFINET + T_OB35_send

For a deterministic 100 ms scan, place the PUT/GET call in OB 35 (interrupt OB) on a fixed time base. The PROFIBUS DP cycle on X2 and the PROFINET cycle on X1 run independently; with PUT/GET over the integrated PROFINET interface, the link uses standard S7 communication (ISO-on-TCP, port 102) and is not synchronized to the PROFINET IO cycle.

Complete OB 1 example with status handling

// Network 1: GET from CPU-B (read inputs / status)
CALL "iDB_GET" , "iDB_Get_Inst"
   REQ   := "M_Get_REQ"
   ID    := 1                       // local connection ID
   NDR   := "M_Get_NDR"
   ERROR := "M_Get_ERR"
   STATUS:= "MW_Get_STATUS"
   ADDR_1:= P#DB100.DBX0.0 BYTE 20
   RD_1  := P#DB200.DBX0.0 BYTE 20;

// Network 2: edge-triggered REQ for PUT (one call per cycle)
      A   "M_Put_REQ";
      FP  "M_Put_REQ_FP";
      =   "iDB_PUT".REQ;

// Network 3: PUT to CPU-B (write outputs / setpoints)
CALL "iDB_PUT" , "iDB_Put_Inst"
   REQ   := "M_Put_REQ_FP"
   ID    := 1
   DONE  := "M_Put_DONE"
   ERROR := "M_Put_ERR"
   STATUS:= "MW_Put_STATUS"
   ADDR_1:= P#DB101.DBX0.0 BYTE 20
   SD_1  := P#DB201.DBX0.0 BYTE 20;

// Network 4: alarm log on non-zero STATUS
      L   "MW_Put_STATUS";
      L   0;
      <>I ;
      S   "M_Put_Alarm";
      L   "MW_Get_STATUS";
      L   0;
      <>I ;
      S   "M_Get_Alarm";

Edge-trigger the REQ input of PUT to avoid repeated triggering. The DONE output of PUT is set for exactly one cycle after a successful transmission; use it to clear the alarm flag and to increment a "successful PUTs" counter for long-term health monitoring.

HMI Panel Connection to Both CPUs

When a WinCC / TIA Panel (Comfort, Unified, or older Multi Panel / OP) must read tags from both 412-2 PN CPUs, configure two separate HMI connections: one pointing to CPU-A, one to CPU-B. The HMI tag DB uses the connection field to select the source PLC.

Considerations:

• Each HMI connection consumes one S7 connection resource on the target CPU. On a 412-2 PN the connection pool is small; the typical partition is 1 PG, 1 OP/HMI per CPU, 1 S7 CPU-CPU connection, 1 OPC UA server (if enabled), and 1 reserve. Exceeding the available resources generates a connection error at the HMI and a connection aborted entry in the CPU diagnostic buffer.
• For an HMI in the same STEP 7 / TIA project, set the connection type to HMI connection in the connections editor. For an HMI on a different subnet, use a routed connection and verify that the routers along the path support the S7 routing ports (ISO-on-TCP port 102, used for S7 communication).
• To minimize the number of connections and tags, prefer a single shared DB replicated on each CPU through the PUT/GET link, and let the HMI read the local copy. This avoids per-tag DB access from the HMI and reduces the HMI connection count.

Slot and connection parameters: The 412-2 PN CPU occupies slot 3 of the S7-400 rack. The integrated PROFINET and PROFIBUS interfaces are addressed through the CPU's own slot. In the HMI connection, the slot of the CPU parameter is set to 3 by default; the integrated PROFINET interface is reached through the CPU slot, not through a separate I/O slot. If a migrated HMI project references a different slot, the connection setup fails with Partner not reachable at the panel and a connection establishment failed entry in the CPU diagnostic buffer. Re-enter slot 3 and re-download the HMI project.

Connection Resources and Diagnostics

Use the online view of the connection table (STEP 7: PLC > Information on Connections; TIA Portal: Online & Diagnostics > Communication) to monitor the state of every S7 connection. Each row shows the connection ID, partner IP, state (established / aborted / in setup), and the diagnostic counter failed establishments.

The diagnostic buffer of the CPU records every connection establishment and abort with a time stamp. Export the buffer with PLC > Save to Text File for the maintenance record. Events to look for:

• Event ID 0x05: connection establishment – check the partner address and the connection table.
• Event ID 0x06: connection abort – check the partner CPU run state, cable, and switch port.
• Event ID 0x07: connection setup failure – check the protocol / port / slot configuration.

Verification and Commissioning

1. With both CPUs in RUN, force a known value in the send DB of CPU-A and observe the receive DB of CPU-B in the watch table. The value must appear within the expected scan interval (typically one or two OB 1 cycles).
2. Toggle the rolling counter in the send DB. The receive DB counter must increment by exactly 1 per send interval. Any mismatch indicates a missed PUT.
3. Disconnect the PROFINET cable between the two CPUs. Both PUT/GET calls must report STATUS ≠ 0 within one communication timeout, and the diagnostic buffer must contain an entry connection aborted by partner or connection establishment failed. Reconnect and verify that the connection is re-established automatically without a CPU restart.
4. Power-cycle CPU-B. CPU-A must report the loss of the connection in its own diagnostic buffer and re-establish the link automatically once CPU-B is back in RUN with the same IP and PROFINET name.
5. From the HMI, read a tag from each CPU. Disconnect one CPU and verify that the HMI flags the lost connection in the Connection status area. Reconnect and confirm that the tags resume updating without a manual operator action.
6. Force a write to the Permit access with PUT/GET property off on the partner CPU and confirm that the local CPU receives STATUS 0x000A. Restore the property, re-download the partner, and confirm that the link resumes.

Troubleshooting Matrix – Field-Proven Symptoms