S7-1200 1214C PROFINET Resolving Third Slave CPU Communication

Problem Overview

A 1-to-4 PROFINET network is being built from five identical SIMATIC S7-1200 1214C AC/DC/Relay CPUs, order number 6ES7214-1BG40-0XB0. One CPU acts as PROFINET IO-Controller (master) and four CPUs act as PROFINET IO-Devices (slaves). The physical layer is the Siemens green PROFINET cable (6XV1 850 series, industrial Cat5e, two-pair, RJ45, green jacket). The first two slaves establish communication without issue, the third slave does not establish communication, and the fourth slave is unverified.

The two symptoms that always point to the third slave specifically are: (1) the third CPU's BF LED stays steady ON while the first two BF LEDs are OFF, and (2) the master-side PUT/GET, TSEND_C, or I-Device block on the third partner returns STATUS W#16#80B1 (partner not reachable) or W#16#80A1 (connection already in use). Field frequency of root causes in roughly descending order: option flag not enabled on slave, IP/subnet error on slave 3, duplicate IP, defective cable run, switch port issue, connection-ID collision on master, and I-Device transfer-area mismatch.

System Identification: 1214C AC/DC/Relay 6ES7214-1BG40-0XB0

The affected CPU is the SIMATIC S7-1200 1214C in the AC/DC/Relay variant. The "-0XB0" suffix confirms the second-generation module with a PROFINET IRT-capable interface, I-Device support, and firmware V4.x. The key parameters that matter for a 1-to-4 communication project are summarized below from the S7-1200 System Manual collection.

From the TIA Portal V18 device configuration (CPU > Properties > Communication > Connection resources), the 1214C has 16 connection resources. The default reservation is one for the engineering station (PG) and one for the HMI (OP), one for HTTP web access, and one for HTTPS web access. That leaves 12 free for application connections, which is more than enough for a 1-to-4 topology. The 16-resource budget is therefore not the cause of the third slave failing — the cause is almost always an option flag, an IP/TSAP mistake, or a connection ID collision.

Three Architectures for 1-to-4 CPU Communication

For a master S7-1200 talking to four identical S7-1200 slaves on a single PROFINET segment, three architectures are supported by firmware V4.x. Each has a different impact on connection resources and on why the third slave can fail.

2.1 PUT/GET (S7 Communication, ISO-on-TCP / S7 protocol)

PUT and GET are the classic S7 instructions. GET reads data from a partner (the remote acts as server), PUT writes data to a partner (the remote acts as server). Each block establishes one S7 connection. From the firmware V4.x programming manual, the S7-1200 is both PUT/GET client and PUT/GET server. As a server, the 1214C accepts GET/PUT only if the option "Permit access with PUT/GET communication from remote partner" is enabled in the CPU properties — that option is OFF by default in V4.x.

Connection resources consumed:

• Master side: 1 connection per active PUT/GET block (up to 4 connections for 4 slaves)
• Slave side: 1 connection per active PUT/GET client (up to 1 server connection per slave when the master calls that slave)

For four slaves, the master uses 4 connections and each slave uses 1 — a total of 8 connection resources across the network. The 16-resource budget is not the limit; the real limit is the per-CPU option flag and the IP/TSAP configuration. PUT/GET is the path of least resistance for ad-hoc data fetches, recipe handling, and one-shot parameter writes.

2.2 TSEND_C / TRCV_C (Open User Communication over TCP)

TSEND_C and TRCV_C use ISO-on-TCP or TCP. Each call uses 1 connection. The number of simultaneous connections is bounded by the same 16-resource pool, and every partner must have a unique local TSAP or port. For four slaves the master opens four TSEND_C/TRCV_C pairs, and each slave uses 1 connection. TSEND_C requires partner IP, local port, partner port, and connection ID; the master cannot share a connection ID or local port between slaves. TSEND_C is the right pick when the data is large, irregular, or must cross to a non-S7 partner (e.g., a Modbus TCP gateway, a third-party SCADA, a remote HMI).

2.3 I-Device (PROFINET Smart Device)

The 1214C supports the I-Device (Smart Device) function from firmware V4.0. The slave CPU is configured as an I-Device that exposes its transfer areas (configured input/output slots) to the master's PROFINET IO system. Communication becomes PROFINET IO cyclic data exchange, not S7 messages. This is the recommended approach when all four slaves are S7-1200 in the same TIA project and the data is short and cyclic (sensor/actuator, interlocks, status mirrors, setpoint commands).

I-Device does not consume S7 connection resources; it uses the standard PROFINET IO Controller/IO Device model. If the third slave fails in an I-Device topology, the cause is always an I-Device transfer-area misconfiguration, a GSD version mismatch, an unassigned PROFINET device name, or a slot misassignment — not connection resources.

Root Cause Analysis: Why the Third Slave Fails

When the third slave drops out while the first two work, the most common causes, ranked by field frequency, are listed below.

3.1 Reading the BF, LINK, and RX/TX LEDs on the 1214C

The PROFINET X1 port on the 1214C has two LEDs per port (left = LINK, right = RX/TX). The CPU front panel has a BF (bus fault) LED and a MAINT (maintenance) LED. Their states tell you exactly which of the ten root causes applies.

Solution A — I-Device Configuration (Recommended for 1-to-4)

Use the I-Device function to map the four slaves as PROFINET IO-Devices on the master. This is the Siemens-recommended path for high-integrity 1-to-4 communication between S7-1200 CPUs in the same TIA project. The configuration is documented in the TIA Portal help (Help > Information System > PROFINET > I-Device).

4.1 Prerequisites

• TIA Portal V18 (or V16/V17 with HSP for 6ES7214-1BG40-0XB0)
• One project, five S7-1200 stations added (one master, four slaves)
• All CPUs firmware V4.0 or later (verify with Online > Accessible nodes > Read CPU identification)
• Distinct IP addresses in the same subnet (e.g., 192.168.0.1 master, 192.168.0.11 to .14 slaves)
• PROFINET device name assigned to every slave (e.g., "io-slave-1" to "io-slave-4")
• For pipe-pressure application: a 32-byte transfer area from each slave covering pressure setpoint, current pressure, pump run command, motor contactor feedback, fault word

4.2 Configure slave 1 (repeat for slaves 2-4)

1. In the project tree, open the slave 1 device configuration.
2. Select the CPU > PROFINET interface > Properties > General > Operating mode.
3. Check "I-Device". Under "Assigned IO-Controller", leave empty for now — it will be set in step 4.3.
4. Under "Transfer areas", click "Add new":
   • Area 1: Type = Input, Length = 16 bytes, Address in slave = %IW100, Slot = 1 (mapped to the master's process image by default)
   • Area 2: Type = Output, Length = 16 bytes, Address in slave = %QW100, Slot = 2 (mapped to the master's process image by default)
5. Compile the slave station (right-click > Compile > Hardware).
6. Repeat with new transfer-area start addresses for slaves 2, 3, 4 (e.g., %IW200, %QW200 for slave 2; %IW300, %QW300 for slave 3; %IW400, %QW400 for slave 4) to avoid symbolic address overlap in the master.

4.3 Configure the master IO system

1. Open the master device configuration. View > Network view.
2. From the hardware catalog, drag the "I-Device" entry corresponding to the 1214C to the master's PROFINET IO system four times, one per slave. Assign each to the matching slave IP and PROFINET device name.
3. Drag a "Transfer area" from each slave (e.g., slave 1 transfer area 1) into the master's device view. This becomes a 16-byte input module in slot 1 of the master IO assignment. TIA Portal auto-assigns the master's process image addresses (e.g., %IB100-%IB115 for slave 1 input area).
4. Repeat for each slave. The master now has four I-Devices, each with its own input and output transfer area.
5. Compile and download the master first, then the four slaves. Use Online > Assign PROFINET device name to each slave in the proper order.

4.4 Verify cyclic IO data exchange

After download, watch the slave CPU's BF LED turn OFF and the master's IO diagnostics show all four I-Devices with green check. In the master program, the input area from slave 1 is accessible as %IW100, slave 2 as %IW116 (16 bytes after the slave 1 area), etc., based on the TIA Portal auto-assignment. To read a pressure value from slave 3, use "DB_pressure".slave3_pressure := %IW132;. To write a pump-start command to slave 3, use %QW132 := "DB_cmd".slave3_start;.

4.5 Application mapping for pipe-pressure / pump control

A typical layout for a 1-master / 4-slave pipe-pressure system, using 16 bytes per slave transfer area, would be:

With this layout, a single TIA Portal HMI connected to the master sees the entire 4-pump plant on four contiguous process-image regions without any application-level message handling.

Solution B — PUT/GET Configuration for 1-to-4

For non-cyclic data fetches (recipe data, setpoints read on demand, diagnostic dumps) PUT/GET is more flexible. The procedure below resolves the most common cause of the third slave failing: option flag and IP/TSAP.

5.1 Enable PUT/GET server access on every slave

1. Open each slave's device configuration in TIA Portal.
2. CPU > Properties > Protection and Security > Connection mechanisms.
3. Check "Permit access with PUT/GET communication from remote partner".
4. Compile and download to each slave. (Required even if hardware is unchanged; the option is a CPU property, not hardware.)

5.2 Configure the master's PUT/GET blocks

For each slave, use one PUT and one GET instance (or four GETs only if you only read). Use unique connection IDs and the partner IP. Below is the parameterization of the first GET instance; the others differ only in ID and IP.

// GET instance for slave 1
"i_GET_slave1"(                // instance DB name
  REQ     := TRUE,             // trigger on rising edge (or controlled bit)
  ID      := 1,                // connection ID (unique per slave)
  ADDR_1  := P#DB1.DBX0.0 BYTE 20,    // source: slave 1 DB1 bytes 0..19
  ADDR_2  := P#DB1.DBX20.0 BYTE 20,   // source: slave 1 DB1 bytes 20..39
  RD_1    := P#M100.0 BYTE 20,        // destination: master M100..M119
  RD_2    := P#M120.0 BYTE 20,        // destination: master M120..M139
  DONE    => "tag_GET1_done",
  BUSY    => "tag_GET1_busy",
  ERROR   => "tag_GET1_err",
  STATUS  => "tag_GET1_status"
);

// Slave 2 uses ID=3, slave 3 uses ID=5, slave 4 uses ID=7
// Partner IP is set on the connection (see step 5.3)
// Even IDs (2, 4, 6, 8) reserved for the PUT blocks

5.3 Create and parameterize the S7 connection

1. In the master program, call Instructions > Communication > S7 Communication > GET/PUT. Place the block; the connection wizard will start.
2. Choose "Connection to a partner". Click "Add" and define a partner with the slave's IP, the partner's rack/slot (always 0/1 for S7-1200), and the local TSAP (default for S7-1200 PUT/GET server is 02.01).
3. Set the connection ID. Each PUT/GET instance uses a unique connection ID — IDs 1 through 8 in this case (one for each PUT and GET block, or as needed).
4. Save the connection with a name (e.g., "S7conn_to_slave3").

5.4 Connection ID rules

If two blocks accidentally share an ID, the second one to call will return STATUS W#16#80A1 (connection already in use) — and only the third slave fails when its ID collides with the master's own PG connection (ID 0x0000..0x000F reserved by engineering). This is the typical signature for the "third slave fails" symptom.

Solution C — TSEND_C / TRCV_C

Use TSEND_C and TRCV_C when the data is large, irregular, or must cross to non-S7 partners. Each connection is full-duplex TCP. The configuration is similar to PUT/GET in that unique connection IDs and unique local ports are required.

// Master side: 4 TRCV_C instances (one per slave)
"i_TRCV_slave1"(
  EN_R    := TRUE,
  ID      := 1,
  LEN     := 32,                // 32 bytes expected
  DATA    := P#M200.0 BYTE 32,
  CONNECT := "S7conn_TCP_slave1",
  NDR     => "tag_TRCV1_ndr",
  BUSY    => "tag_TRCV1_busy",
  ERROR   => "tag_TRCV1_err",
  STATUS  => "tag_TRCV1_status",
  RCVD_LEN=> "tag_TRCV1_len"
);

// Connection data block for slave 1 (auto-generated):
// CONNECT."ConnectionType" := 16#0B (TCP)
// CONNECT."ActiveEstablished" := TRUE (master is active)
// CONNECT."RemoteAddress".ADDR[1..4] := 192,168,0,11
// CONNECT."RemotePort" := 2000
// CONNECT."LocalPort" := 2001

Reserve a unique local port (2001, 2002, 2003, 2004) for each TRCV_C instance. Failure to do so results in STATUS W#16#80A4 (port already in use) on the third instance — again matching the "third slave fails" symptom. The slave-side TSEND_C uses local port 2000 (or any unique port) and a partner port 2001 from the slave's perspective.

Connection Resource Planning

From the TIA Portal CPU properties > Communication > Connection resources dialog, the 1214C with firmware V4.x exposes 16 connection resources. The default reservation is:

For a 1-to-4 PUT/GET scenario, the master uses 4 server connections, each slave uses 1 server connection. Total: 8. If HMI is connected to the master, add 1. If a PG is online to the master, add 1. With 16 resources, the limit is not the cause of the third slave failure in a 1-to-4 topology. The cause is almost always an option flag, an IP mistake, or a connection ID collision.

LED Diagnostics Reference (Master and Slaves)

Verification Procedure

1. Online > Accessible nodes: all five CPUs (master + 4 slaves) appear with the assigned IPs and PROFINET names.
2. From the PG command line, ping 192.168.0.13 (the third slave). Reply confirms IP and link layer.
3. Online > Diagnostics and Monitoring for the master. All four IO-Devices (if I-Device) or all four S7 connections (if PUT/GET) report green status.
4. Force a bit in the master's output transfer area to the third slave and observe the value in the slave's process image. Toggle a bit in the third slave's input area and observe it in the master's input area.
5. Power-cycle the third slave. The I-Device AR (Application Relationship) re-establishes within a few seconds. PUT/GET re-establishes on the next REQ edge.
6. Watch the master's connection resource counter (Online > Diagnostics > Connection overview). All four connections show "established" for PUT/GET; for I-Device, all four ARs show "running".
7. Use the TIA Portal integrated trace (Trace > Configuration) to capture the PROFINET IO update time on the master's IO system. For 16-byte transfer areas, expect a 1-2 ms update time on a 100 Mbit/s PROFINET segment with no other IO traffic.

Troubleshooting Matrix

Field-Proven Cautions

• The PUT/GET option flag is off by default. Most "first attempt" failures on a 1-to-many PUT/GET project are caused by this flag not being set on every slave. The symptom is asymmetric: slaves 1 and 2 work, slave 3 fails — the engineer remembered to enable the flag on 1 and 2 and forgot on 3.
• The PROFINET device name (not just IP) is required for I-Device. The TIA Portal "Assign PROFINET device name" tool needs the right MAC address to find the CPU; "Accessible nodes" in TIA helps confirm the MAC.
• Do not daisy-chain four PROFINET devices without at least one managed switch. Two 1214C in a row will work; three or four begin to show latency under load. Use a SCALANCE XC-108 or similar managed switch at the master end and consider an MRP ring if the segment is mission-critical.
• Reserve a local TSAP of 02.01 for the partner (S7-1200 default) and a unique local port (2001, 2002, 2003, 2004) for TSEND_C on the master side. Conflicts are silent and the only symptom is the affected partner failing.
• Updating firmware on the 1214C to V4.6 resets some non-retentive bit memory; back up the project before update.
• For pipe-pressure applications, configure the analog-input scaling in each slave's analog-input channel (0-10 V = 0-100% = 0.0-10.0 bar) so that all four slaves report a uniform engineering unit, regardless of which 0-10 V transducer is wired to which slave. Mismatched scaling is a frequent source of "communication works but data is wrong" tickets.
• After any firmware change on a 1214C, the IP address, PROFINET name, and connection option flags are retained, but the project re-download is required for them to take effect. Always re-download both the program and the device configuration.

Related Diagnostics: Connection Status Word (STATUS) Decoding

The GET, PUT, TSEND_C, and TRCV_C blocks all return a 16-bit STATUS word. The most common values that produce the "third slave fails" symptom are:

Sample Program Skeleton for the Master

The following STL-style skeleton ties the four slaves together for a 1-to-4 PROFINET master with mixed I-Device (cyclic) and PUT/GET (event-driven) traffic. Adapt to LAD/FBD as needed.

// OB1 — Main scan
// 1. Cyclic pressure / pump data is in %IW100-%IW163 (4 slaves × 16 bytes input)
//    and command bits are in %QW100-%QW163.
// 2. Event-driven diagnostic fetch from each slave via PUT/GET every 5 s.

// Periodic diagnostic GET to slave 3 (the failing one)
CALL "i_GET_slave3", "DIA_Get3"     // background DB
     REQ     := "clk_5s",            // 5 s pulse from clock byte
     ID      := 5,
     ADDR_1  := P#DB90.DBX0.0 BYTE 50,    // diagnostic block on slave 3
     ADDR_2  := P#DB90.DBX50.0 BYTE 50,
     RD_1    := P#M500.0 BYTE 50,
     RD_2    := P#M550.0 BYTE 50,
     DONE    => "tag_diag3_done",
     BUSY    => "tag_diag3_busy",
     ERROR   => "tag_diag3_err",
     STATUS  => "tag_diag3_status";

// On any diag3_error, capture status word into an HMI-visible tag
A "tag_diag3_err";
JCN noe;
L "tag_diag3_status";
T "DB_diag".slave3_last_err;
noe: NOP 0;

Pair this with the four I-Device transfer areas for cyclic data, and the master program has full visibility into all four slaves' pressure, pump, and fault data without any application-level S7 messaging for the cyclic path.

FAQ