Reading S7-300 Tags from Multiple PLCs to a Central S7-400

Overview

When a fleet of SIMATIC S7-300 controllers is distributed across a plant — 40, 50, or 90+ CPUs — it is impractical for maintenance staff to dial into each PLC individually with STEP 7 to extract a single diagnostic value such as machine running hours. Aggregating those values into a single S7-400 (or modern S7-1500) acting as a data concentrator collapses N online sessions into one. This reference covers the architecture, function-block choices, connection-resource sizing, STEP 7 configuration, and the program code needed to consolidate a single DWORD from each of many S7-300 stations into a single DB on a central S7-400.

The solution pattern is to deploy the S7-communication blocks AG_SEND / AG_RECV (FC 5 / FC 6 on CP-equipped stations) or, on PN-equipped CPUs, SFB 14 GET and SFB 15 PUT, on the central CPU and to structure the topology as a pyramid when the leaf count exceeds the central CPU's connection budget.

Problem Definition and Constraints

Consider a fleet of 43 S7-300 stations, each tracking a crane or machine. The required data per station is one DWORD (32-bit) — for example, accumulated running hours stored in DB 100, byte 0 (DBD 0). The operator needs a single point of access to retrieve all 43 values without manually connecting to each CPU.

Constraints that shape the architecture:

• Connection resource ceiling. Every S7 connection consumes one resource on each endpoint. S7-300 CPUs typically allow 6–16 S7 connections; S7-400 CPUs range from 16 to 64 depending on model.
• Partner protection. The leaf CPU must allow PUT/GET access from remote partners; otherwise the central CPU receives STATUS = W#16#8311 (protection violation).
• Network layer. All S7 traffic in this scenario rides on ISO-on-TCP (RFC 1006) over TCP port 102 across switched 100 Mbit Ethernet.
• Data volume. Total data per polling cycle is small: 43 × 4 bytes = 172 bytes. Bandwidth is not the limiting factor — connection count and CPU scan time are.

The architecture must therefore address (a) how to fit 43 leaf connections onto a finite connection budget and (b) how to expose the consolidated data to a single point of attachment.

S7 Communication Primitives

SIMATIC offers four principal S7-communication primitives. Selection is driven by direction of data flow, packet size, and whether the partner CPU is passive or active.

For a 4-byte DWORD per partner, GET on the central S7-400 reading from each S7-300 partner is the simplest path. AG_SEND / AG_RECV are required when (a) the central CPU has no integrated PROFINET interface and must route through a CP 443-1, or (b) the existing plant codebase already uses them and uniformity outweighs the savings of switching to PUT/GET.

Connection Resource Sizing and Pyramid Topology

Siemens publishes connection budgets per CPU. Representative values from the S7-300 / S7-400 system manuals:

For 43 stations in a flat star, the S7-400 must support at least 44 connections (43 leaves + 1 PG/OP). A CPU 416-3 just fits; a CPU 414-3 does not. The reliable remedy is a pyramid (tree) topology in which groups of satellite CPUs aggregate into a tier of mid-level CPUs and the mid-level CPUs aggregate into the central S7-400.

Pyramid sizing rule for grouping with N-leaf clusters of size k:

N_clusters   = ceil(N_leaves / k)
Per-cluster concentrator connections = k + 1 (uplink)
Central CPU connections              = N_clusters + 1 (PG) + 1 (SCADA)

Example with k = 7, N_leaves = 43:

N_clusters = ceil(43 / 7) = 7 clusters (last cluster has 1 leaf)
Per-cluster concentrator connections = 7 + 1 = 8
Central S7-400 connections          = 7 + 1 (PG) + 1 (SCADA) = 9

This places the workload comfortably inside any S7-300 CPU's connection budget (8 max on a CPU 314), and frees the S7-400 to host an SCADA link and a redundant PG connection. A CPU 414-3 (32 connections) is more than sufficient as the root.

Network Topology and Data Block Layout

For 43 stations, a single Class C subnet (e.g., 192.168.10.0/24) provides 254 host addresses, more than enough. Address allocation scheme:

• S7-300 leaves: 192.168.10.11 … 192.168.10.53 (one per crane).
• S7-300 concentrators: 192.168.10.61 … 192.168.10.67 (one per cluster).
• S7-400 root: 192.168.10.1 (gateway / default for the subnet).

Use managed switches such as SCALANCE XC-200 for port-based VLAN segmentation if the cranes span multiple production halls. Each hall becomes a VLAN; inter-VLAN routing on a layer-3 switch permits the central S7-400 to reach all halls while isolating broadcast domains. S7 communication uses ISO-on-TCP (RFC 1006) on TCP port 102 — ensure any firewall between subnets allows this port bidirectionally.

For redundant ring topologies, deploy SCALANCE XR-300 switches with MRP (Media Redundancy Protocol). S7 connections survive a single switch or link failure within ~50 ms (MRP reconfiguration time).

Define one DB per cluster on the central S7-400 (so faults are locatable by DB number) and a single aggregator DB that mirrors all values into a contiguous array. The mirror DB is the single attachment point for SCADA / HMI / OPC.

Byte layout: cluster i starts at DBD (i-1) × 28 (7 DWORDs × 4 bytes) inside the mirror. Crane index mapping is documented in a separate engineering spreadsheet and loaded as the symbol comment for AllHours[i].

STEP 7 V5.x Configuration Procedure

Steps for the central S7-400 in STEP 7 V5.x (NetPro). TIA Portal follows the same conceptual path under Devices & Networks > Connections.

1. Insert S7 connections. In NetPro, right-click the S7-400 CPU > Insert New Connection. Choose S7 connection for each cluster concentrator (or each leaf if star-coupled). Specify partner IP, partner rack / slot, and a unique local Connection ID.
2. Allocate Connection IDs. Use a deterministic numbering scheme such as ID = 100 + cluster_number × 10 + leaf_number. Document this in a spreadsheet; a missing or duplicated ID causes SF LED and STATUS = W#16#80A1 at runtime.
3. TSAP / port. S7 connections default to ISO-on-TCP port 102 with TSAP 03.01 on the partner CPU's slot 3 / rack 0. Modify if a CP-based partner uses a different TSAP, e.g., 10.04 for a CP 343-1 at slot 4.
4. Download connection configuration. NetPro compiles the configured S7 connections into connection DBs (DB 1xx for S7-400). Download via PLC > Download to Target System. Without this download, the program blocks cannot resolve the connection ID to a partner.
5. Configure partner protection. On each leaf S7-300, open CPU Properties > Protection and tick Permit access with PUT/GET from remote partner. Without it, every GET returns STATUS = W#16#8311.
6. Generate program blocks. Add OB 35 (100 ms cyclic interrupt) call to GET / PUT / AG_SEND / AG_RECV FB instances, parameterized with the Connection ID, request DB, and target DB. Compile and download.

Program Code: AG_SEND / AG_RECV and GET / PUT

AG_RECV on the central S7-400 (legacy pattern, CP 443-1 required):

CALL  "AG_RECV"   // FC 6
  ID        := 100                      // Connection ID from NetPro
  LADDR     := W#16#0100                // Logical base address of CP 443-1
  RET_VAL   := MW 200                   // Return code (0 = OK, else W#16#80xx)
  DONE      := M 201.0                  // 1 = new data received
  ERROR     := M 201.1                  // 1 = error
  STATUS    := MW 202                   // Detailed status
  RECEIVE   := P#DB 200.DBX 0.0 BYTE 240 // Receive area in cluster DB

AG_SEND on the cluster concentrator (push to the central S7-400):

CALL  "AG_SEND"   // FC 5
  ACT       := M 100.0                  // 1 = trigger send
  ID        := 100                      // Connection ID (uplink)
  LADDR     := W#16#0100
  SEND      := P#DB 50.DBX 0.0 BYTE 240 // Send area
  LEN       := 28                       // 7 DWORDs × 4 bytes
  DONE      := M 101.0
  ERROR     := M 101.1
  STATUS    := MW 102

GET on the central S7-400 (modern pattern, integrated PN interface):

// OB 35 — read cluster 1, leaf 1
"C_Get_Cluster1_Leaf1"(                 // Instance of FB 14 (GET)
  REQ     := "Clock_1Hz",               // 1 Hz pulse from clock memory
  ID      := 101,                       // NetPro Connection ID
  NDR     := "Cluster1_Leaf1.NDR",      // New data received (1 cycle pulse)
  ERROR   := "Cluster1_Leaf1.ERROR",    // 1 = error flag
  STATUS  := "Cluster1_Leaf1.STATUS",   // Detailed status word
  ADDR_1  := P#DB100.DBX0.0 BYTE 4,     // Remote address: 1 DWORD
  ADDR_2  := P#M 100.0 BYTE 0,          // Unused
  ADDR_3  := P#M 100.0 BYTE 0,
  ADDR_4  := P#M 100.0 BYTE 0,
  RD_1    := P#DB 200.DBX 0.0 BYTE 4,   // Local target in cluster DB
  RD_2    := P#M 100.0 BYTE 0,
  RD_3    := P#M 100.0 BYTE 0,
  RD_4    := P#M 100.0 BYTE 0
);

For 7 clusters × 7 leaves, instantiate 49 GET FB calls. To avoid scan-time spikes, drive REQ from a clock-bit demultiplexer (one cluster per OB 35 cycle) so the central CPU performs 1 GET per cycle = 49 × 100 ms = 4.9 s full refresh.

Cluster Concentrator Pattern and BSEND / BRCV Variant

The Tier-2 concentrator CPU aggregates 7 leaves into one block. Pseudocode for a CPU 315-2 PN cluster concentrator running in OB 35 (100 ms):

// OB 35 — cluster concentrator
// Step 1: GET each leaf's DWORD into local DB 50 (1 GET per cycle)
"C_Get_Leaf1"(
  REQ  := "tick.0", ID := 1,
  ADDR_1 := P#DB100.DBX0.0 BYTE 4,
  RD_1   := P#"DB50".Leaf1_Hours,
  ... );
"C_Get_Leaf2"(
  REQ  := "tick.1", ID := 2,
  ADDR_1 := P#DB100.DBX0.0 BYTE 4,
  RD_1   := P#"DB50".Leaf2_Hours,
  ... );
// ... up to Leaf7

// Step 2: at end of cycle, AG_SEND the consolidated block to the central S7-400
"C_Send_Central"(
  ACT := "tick.6",
  ID  := 100,
  SEND := P#"DB50".Cluster,
  LEN := 28,
  ... );

The tick byte "Clock_OB35" is a free-running counter incremented in OB 35; bit "tick.n" is true once every 8 cycles (800 ms). This staggers GET calls across the cycle so the CPU never executes more than one GET per scan.

For installations carrying 200 words per leaf (such as a fleet where each leaf publishes a diagnostic array), GET's 160-byte ceiling is exceeded. Switch to BSEND / BRCV (SFB 12 / 13) which supports segmented data up to 65 534 bytes per call. Both partners must be programmed; the sender calls BSEND with LEN, the receiver calls BRCV with RD pointing to a buffer DB. Segment acknowledgments ride on the same S7 connection, so connection-resource cost is unchanged versus GET.

BSEND / BRCV timing on a 200-word payload: ~10–25 ms per call on a persistent connection. For 90 leaves × 200 words polled in OB 35 (100 ms), full refresh = 90 × 100 ms = 9 seconds, or faster if multiple BSEND calls run in parallel within OB 1.

Polling Cycle Design and Performance

A naïve "GET everything every scan" implementation saturates the S7-400 CPU. Use one of these patterns:

• Time-division multiplex. One GET per OB 35 cycle (every 100 ms). Total cycle to refresh all 43 partners = 43 × 100 ms = 4.3 s. Acceptable for crane hours where the value changes on the order of minutes.
• Event-driven GET. S7-300 leaves broadcast a 1-bit flag via USEND when running-hours changes by > 1 hour; the central CPU GETs only on the flag.
• Watchdog. Each leaf DB has a "last-contact" timestamp updated on every successful GET. If a partner's timestamp is older than N seconds, raise an alarm and force the mirrored value to 16#FFFFFFFF (a sentinel visible in WinCC).

Measured scan-time impact on an S7-400 CPU 416-3 PN/DP:

• Idle OB 1 scan: ~5 ms.
• Each GET call (persistent connection): +0.1–0.3 ms scan-time overhead.
• 49 GET calls instantiated: +5–15 ms total scan-time overhead.
• End-to-end GET duration: 5–30 ms per call (initial connection), 1–5 ms (subsequent on persistent connection).

For 43 leaves, sustained polling completes in ~250–700 ms wall-clock when connections are persistent. OB 35 at 100 ms gives comfortable headroom; reducing to OB 33 (10 ms) is not advised for this volume.

Verification, Diagnostics, and Error Codes

After download, verify in three layers:

1. NetPro connection monitor. Each S7 connection icon turns green when established. Yellow = establishing; red = fault. Open the connection table with PLC > Monitor / Modify or click the connection in the NetPro editor and view status.
2. CPU diagnostic buffer. Filter for Event Class "Communication". Common Event IDs:

3. FB STATUS values. Critical SFB 14 / 15 return codes:

SCADA / OPC Integration, Migration, and Edge Cases

The consolidated DB 500 is exposed to SCADA via SIMATIC NET OPC Server or to WinCC directly through a STEP 7 symbol export. In WinCC Professional, import the S7-400's symbol table and create internal tags for DB 500.DBD 0..172. Configure the tag update rate to match the polling rate (e.g., 1 s for hourly data, 5 s for slower diagnostics).

For third-party SCADA such as Ignition by Inductive Automation or any OPC-UA client, the consolidated DB is reachable via SIMATIC NET OPC UA Server. Each array element in DB 500 maps to one OPC tag — 43 tags total — versus 43 separate S7 connections if the SCADA polled each leaf directly. This single-attachment pattern is the principal architectural benefit of the data concentrator.

If new hardware is an option, replace the S7-300 leaves with S7-1200 / S7-1500 stations and the central S7-400 with an S7-1500. In TIA Portal, the S7 connection is replaced by a PUT / GET instruction in the program blocks palette, with the connection declared under Devices & Networks > Connections > S7 Connection. The data block structure on the central CPU and the GET call pattern remain identical, simplifying migration. The PUT/GET access toggle moves to Properties > Protection & Security > Connection Mechanisms > Permit access via PUT/GET communication.

Edge cases and field-proven caveats:

• CPU restart loses connection state. When the central S7-400 transitions from STOP to RUN, all S7 connections drop and re-establish within 1–3 seconds. During this window, GET calls return W#16#80A3 (partner unreachable). Plan for a startup grace period of ~5 seconds before flagging connections as faulty.
• WinCC project download interferes with connections. A WinCC download to the S7-400 briefly disrupts all S7 connections. Schedule downloads during maintenance windows.
• Firmware 3.x vs 4.x on S7-300. Some firmware versions changed connection-resource limits via CPU properties. Verify on the Siemens Industry Online Support portal that the firmware supports the connection count you intend.
• PUT/GET access is global, not per-connection. The toggle applies to all remote partners. If the leaf CPU must also block engineering access from non-trusted sources, use a separate protection level instead of disabling PUT/GET globally.
• AG_SEND / AG_RECV with CP 343-1 IT. The IT variant supports additional protocols (FTP, HTTP, SNMP). S7 communication works identically; verify the CP's firmware supports the connection count.

Troubleshooting Matrix