S7-300 Multi-CPU Data Aggregation: GET/PUT to OPC Server

1. Problem Overview

Many brownfield SIMATIC S7-300 plants end up with multiple independent controllers that need to be rolled up into a single data conduit for SCADA, MES, or OPC publishing. The typical constraints are:

• Existing CPU 315-2 PN/DP (6ES7315-2EH14-0AB0) and ET 200S CPU IM151-8 PN/DP (6ES7151-8AB00-0AB0) stations must not have their hardware configuration or user program modified.
• Only the receiving direction is required (unidirectional polling); the source CPUs do not need to be aware of the aggregator.
• Payload per station is on the order of 2,500 bytes, which exceeds the single-call limit of the standard S7 GET/PUT primitives.
• Data must be delivered to an OPC server (DA 2.05/3.0) for downstream consumers.

All four constraints can be satisfied with an aggregator PLC acting as an S7 client to the nine server stations, using SFB14 GET and SFB15 PUT over configured S7 connections. The aggregator runs the polling logic and the OPC tag database on the same controller, or hands the data to a dedicated OPC server over Industrial Ethernet.

2. Architecture: Two PROFINET Networks, One Aggregator

The reference topology is two PROFINET subnets joined by the aggregator CPU's integrated PROFINET interface or by a CP 343-1 module:

• Network 1: 3 × CPU 315-2 PN/DP + 2 × IM151-8 PN/DP CPU
• Network 2: 2 × CPU 315-2 PN/DP + 2 × IM151-8 PN/DP CPU
• Aggregator: 1 × CPU 315-2 PN/DP (or higher tier) on a backbone segment reachable from both networks

The aggregator initiates 9 S7 connections (one per source station) and runs 144 GET requests per scan cycle to capture 2,500 bytes from each. OPC tags are written into a contiguous DB that the OPC server polls, or are published via the SIMATIC NET OPC server or a third-party gateway.

3. Prerequisites

• STEP 7 V5.5 + SP4 (or TIA Portal V15.1 and later) for project engineering
• SIMATIC NET PC software V14 SP1 or later if the OPC server runs on a separate station
• CPU 315-2 PN/DP firmware V3.3 or later for unrestricted GET/PUT with full connection resource accounting
• Network connectivity: PROFINET switch infrastructure (SCALANCE XB-005, XC-100, or compatible) and an IP plan that gives every station a unique IPv4 address with a common subnet mask (e.g., 255.255.255.0 across all 10 stations if a single subnet is used)
• Source CPUs must have PUT/GET access permitted from remote partner in their security/connection configuration. This is a single CPU property and does not require program changes

4. Server-Side Configuration: No Program Changes Required

For an S7-300 station to act as a passive S7 server for GET/PUT, the only project-side action is enabling the connection mechanism. In STEP 7 V5.5 the equivalent is in HW Config → CPU Properties → Protection tab → check Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, ...). In TIA Portal this is located at CPU Properties → Protection & Security → Connection mechanisms.

Once enabled, the partner (the aggregator) can:

1. Open an S7 connection using the source CPU's IP address and the standard S7 port (TCP/102, ISO-on-TCP RFC 1006).
2. Issue GET (read) or PUT (write) requests against any data block, inputs, outputs, or bit memory area the partner specifies in the request.

5. Connection Resources Per CPU

The CPU 315-2 PN/DP (6ES7315-2EH14-0AB0, firmware V3.3) has the following S7 connection budget per the SIMATIC S7-300 CPU 31xC and CPU 31x technical data manual:

The ET 200S IM151-8 PN/DP CPU (6ES7151-8AB01-0AB0, firmware V3.3) is functionally identical to the CPU 315-2 PN/DP for S7 communication and shares the same 16-connection limit.

For the aggregator CPU, the 9 S7 connections to the source stations consume 9 of its 14 free resources, leaving 5 for PG, HMI, and the OPC server. If the OPC server runs on the same PLC, it consumes an additional connection. If a higher fan-out is needed (e.g., 10+ sources), promote the aggregator to:

• CPU 317-2 PN/DP (6ES7317-2EK14-0AB0) — 32 S7 connections, larger work memory, more comfortable for OPC tag DBs
• CPU 319-3 PN/DP (6ES7319-3EL00-0AB0) — 32 S7 connections, 2.5 MB work memory, fastest backplane bus
• CPU 414-3 PN/DP (6ES7414-3EM07-0AB0) — 64 S7 connections, 4 MB work memory, ideal for an OPC gateway role

Alternatively, add a CP 343-1 (6GK7343-1EX30-0XE0) to offload communication: the CP can establish up to 32 additional S7 connections, freeing the CPU's integrated port for HMI/PG traffic.

6. SFB14 GET and SFB15 PUT: Block Parameters

The GET (SFB14) and PUT (SFB15) function blocks are part of the standard S7-300 system function library and live in the System Function Blocks container. They run in the aggregator CPU only; the source CPUs run no SFB at all.

SFB14 GET input parameters (LAD/FBD view):

Output parameters:

6.1 Maximum Data Length per GET Call

For S7-300 stations as the data source, the GET block reads a maximum of 160 bytes per call when the source is an S7-300/ET 200S CPU. This limit is fixed by the firmware of the server and cannot be increased through configuration. SFB15 PUT has the same 160-byte ceiling per call.

The 160-byte limit is unrelated to the network MTU; it is enforced by the S7 communication stack's user-data payload field. To read 2,500 bytes from a single source, the aggregator must execute 16 GET calls (15 × 160 + 1 × 100 = 2,500), each with a different offset into the source DB.

7. Segmenting 2,500 Bytes with Sequential GET Calls

Sequencing GET calls inside one OB1 cycle is not recommended; the resulting scan time would be excessive and jobs cannot be re-triggered while a previous one is busy. Use a cyclical dispatcher in OB35 (e.g., 100 ms) or a time-driven state machine that issues one GET per cycle and increments an offset pointer.

Reference structured text skeleton for a single source (one of 9):

// State machine: 0..15 for 16 GET chunks, 16 = idle
IF iState < 16 THEN
    iReq[1] := FALSE;
    IF NOT bBusy[1] THEN
        iReq[1] := TRUE;            // rising edge -> trigger GET
    END_IF;
    SFB14(REQ := iReq[1],
          ID  := wConnID[1],
          ADDR_1 := P#DB[remoteDB] BYTE [iState * 160],
          RD_1 := P#DB[localAggDB] BYTE [iState * 160],
          LEN := 160,
          NDR => bNDR[1],
          ERROR => bErr[1],
          STATUS => wStatus[1]);
    bBusy[1] := NOT bNDR[1] AND NOT bErr[1];
    IF bNDR[1] OR bErr[1] THEN
        iState := iState + 1;
        IF bErr[1] THEN
            // log status, count error, advance state to avoid lockup
        END_IF;
    END_IF;
ELSE
    iState := 0;                    // all 16 chunks done, restart
    bComplete[1] := TRUE;
END_IF;

Replicate this block nine times (one per source), each with its own state counter, busy flag, and connection ID. The complete refresh of 2,500 bytes × 9 sources = 22,500 bytes requires 144 GET calls. At 100 ms per cycle, one full sweep takes 14.4 s. Tighten OB35 to 50 ms for a 7.2 s sweep if the SCADA refresh rate demands it; below 20 ms the backplane becomes a bottleneck on the 315-2 PN/DP.

8. Aggregator CPU and CP Selection Matrix

For the 9-source / 2,500-byte workload, the CPU 317-2 PN/DP is the most balanced aggregator. Choose the 319-3 or 414-3 only if the OPC tag database is shared with recipe management, audit trail, or batch logic on the same controller.

9. OPC Server Options

9.1 SIMATIC NET OPC Server

The native Siemens SIMATIC NET PC Software ships with an OPC DA 3.0 server that talks to S7 controllers via the S7 protocol. The aggregator CPU exposes its OPC tag DB over a single S7 connection; SIMATIC NET runs on a separate PC and uses the S7 driver to subscribe. This is the lowest-friction option and the one most aligned with the project's existing Siemens stack.

9.2 Softing echocollect

For deployments where the aggregator PLC is undesirable, Softing echocollect is an OPC UA/DA server that polls multiple Siemens controllers directly over Ethernet and exposes aggregated tags without any additional PLC. It is well suited when the 9 source CPUs must remain fully untouched and no aggregator PLC budget is available. It does, however, introduce a third-party runtime in the architecture.

9.3 KEPServerEX

Kepware's KEPServerEX Siemens TCP/IP Ethernet driver supports both S7-300 PUT/GET and native DB access. It is the most common choice in mixed-vendor plants.

10. Network Topology and IP Planning

• Assign a single /24 subnet to all 10 stations if a flat network is acceptable: e.g., 192.168.10.0/24 with 192.168.10.1 through 192.168.10.10.
• If two subnets are mandatory, place the aggregator on both subnets by giving the CPU 315-2 PN/DP two IP addresses (the integrated PROFINET port of the 315-2 PN/DP can be configured with one IP per port; the second port is reserved for PROFINET IO and cannot host an S7 connection in the base firmware, so use a CP 343-1 for the second subnet if this is required).
• Spanning tree must be disabled on PROFINET ports (RSTP/STP off) to avoid 30+ s reconfiguration events on link flap.
• Enable Port Priority and Flow Control on the SCALANCE switches; the OPC server traffic is best-effort and should not starve S7 communication.

11. Cycle Time and Performance Calculations

Round-trip time for one GET request against an S7-300 on PROFINET is dominated by the scan time of the source PLC and the OB1/OB35 cycle of the aggregator. Typical observed values for a 160-byte GET:

• 1 ms network latency per request (LAN, no router)
• 1–5 ms source PLC processing (depends on OB1 priority and current scan time)
• 1–2 ms aggregator processing
• Total per GET: 3–8 ms typical, 15 ms worst case

For 144 GETs in series at 8 ms each, one full data sweep is 1.15 s. With dispatcher overhead and connection keep-alive frames, budget 2 s per sweep. A SCADA system polling at 5 s sees consistent data; polling at 1 s will see partial updates during the sweep and should subscribe to the OPC server's data-change rate rather than request-based refresh.

12. Step-by-Step Configuration

12.1 Enable PUT/GET on the 9 Source CPUs

1. Open each source station in STEP 7 / TIA Portal.
2. Open CPU Properties → Protection / Protection & Security.
3. Check Permit access with PUT/GET communication from remote partner.
4. Save, download, and warm restart the CPU.

12.2 Build the Aggregator Station

1. Insert a new S7-300 station in STEP 7; choose the 317-2 PN/DP (or 315-2 PN/DP for budget-limited deployments).
2. Configure the PROFINET interface with a unique IP in the same subnet as the source stations.
3. Insert a PC station (or Softing/Kepware station) on the same subnet if the OPC server is external.

12.3 Configure the 9 S7 Connections in NetPro

1. Open NetPro on the aggregator station.
2. Insert a new S7 connection per source CPU; type S7 connection.
3. Set the aggregator as the local endpoint, client role, with Establish active connection = on.
4. Set the remote endpoint to the source CPU's IP; role server, Establish active connection = off.
5. Note the local connection ID assigned by NetPro (typically 1 through 9); these are the ID inputs to SFB14.
6. Save and download the connection configuration to the aggregator CPU.

12.4 Create the Aggregator Tag DB

1. Create DB1000 (or similar) with a structure of 9 arrays, each 2,500 bytes, named Source_01 through Source_09.
2. Reserve a parallel DB2000 of STRUCTs containing the 9 source pointers, state counters, busy flags, and last error codes for diagnostics.
3. Create a 22,500-byte raw block DB3000 if the OPC server needs a flat tag space rather than a structured DB.

12.5 Program the GET Dispatcher

1. Create FB1000 (or FC1050) implementing the state machine in section 7.
2. Instantiate it 9 times in OB35 (one per source). For each instance, parameterize the connection ID and the source DB number on the remote CPU.
3. Make sure OB35 priority is below OB1 to keep polling from blocking the main scan.

12.6 Configure the OPC Server

1. In SIMATIC NET, add a new S7 channel with the aggregator CPU as the device; create tags pointing to DB1000 offsets 0, 1, 2, ..., 22,499.
2. Set the deadband and update rate in the OPC group; a 1 s update rate with a 1% deadband is typical for process data.
3. Test connectivity using the OPC Scout (SIMATIC NET) or a third-party OPC client.

13. Verification and Diagnostics

13.1 Online Diagnostics in STEP 7

• Right-click the aggregator CPU → PLC → Diagnose/Setting → Information for connection status. A green status on each of the 9 S7 connections confirms the client is online.
• Use the Monitor/Modify view on DB2000 to confirm each state counter cycles 0..15.
• Use the Variable Table with VAT_AGG_MONITOR to read the 9 source arrays side-by-side with the expected raw values from the source DBs.

13.2 SIMATIC NET OPC Scout

1. Start OPC Scout V10.
2. Add a new group and drag the 22,500 bytes of tags from the channel.
3. Confirm all 9 sources report Good quality and values update on the configured refresh rate.

14. SFB14 GET/PUT Status / Error Code Matrix

The exact hex codes are documented in the SIMATIC S7-300 SFBs / SFCs reference manual and are identical for the S7-400 and ET 200S CPU platforms.

15. Troubleshooting Matrix

16. Answers to the Original Restrictions and Clarifications

• (a) No hardware or program changes on the 9 source CPUs: satisfied. The only modification is a single CPU property flag (PUT/GET permitted) and possibly a project download to enable that flag. No FB/FC/DB edits on the source stations.
• (b) One-way read-only: satisfied. Use SFB14 GET only; do not instantiate SFB15 PUT in the aggregator.
• (c) ~2,500 bytes per source: satisfied via a 16-call GET dispatcher (15 × 160 + 1 × 100). Full sweep in ~2 s on a 315-2 PN/DP or 317-2 PN/DP aggregator.
• (A) Feasibility without source-side changes: yes, with the PUT/GET flag enabled as described above. The source stations require no S7 communication blocks of their own.
• (B) Using S7 connection GET: yes, this is the standard approach. Configure 9 S7 connections in NetPro on the aggregator.
• (C) Bytes per GET: 160 bytes maximum against an S7-300 source. Larger transfers require segmentation or, if the source is willing to host an SFB, BSEND/BRCV (SFB12/SFB13) for up to 32 KB in a single call.
• (D) Recommended CPU and CP: CPU 317-2 PN/DP as the aggregator, optionally augmented with a CP 343-1 (6GK7343-1EX30-0XE0) for additional S7 connection capacity. For larger scope, upgrade to CPU 319-3 PN/DP or CPU 414-3 PN/DP. If introducing an aggregator PLC is undesirable, deploy Softing echocollect on a PC station and skip the PLC entirely.