Resolving S7 PUT-GET Communication Errors (Code 4) Between S7-300 and Redundant CPU 410-5H

In S7 communication between an S7-300 (e.g., CPU 314-2 PN/DP) and a redundant SIMATIC PCS 7 CPU 410-5H, PUT (FB15) returning error status code 4 after an H-system master switchover indicates an area length error, PDU size violation, or invalid connection ID evaluation. S7-300 communication blocks evaluate connection IDs primarily during initialization (OB100); dynamically toggling connection IDs in cyclic logic without proper reset sequencing corrupts the internal communication state. Furthermore, large data payloads (>50 bytes) fail because the S7-300 PDU buffer size is exceeded during redundant header re-negotiation.

Mechanics of S7 Connections Between S7-300 and Redundant S7-400H / 410-5H

Integrating standard S7-300 controllers (e.g., CPU 314-2 PN/DP 6ES7314-6EH04-0AB0) with redundant PCS 7 automation stations (CPU 410-5H 6ES7410-5HX08-0AB0):
* The Asymmetric Redundancy Challenge:
An S7-300 does not support native Fault-Tolerant S7 Connections (Redundant 4-way S7 connections). To communicate with an S7-400H or CPU 410-5H, the engineer must configure two independent unilateral S7 connections in NetPro:
* Connection 1: S7-300 to CPU 410 Master (Rack 0).
* Connection 2: S7-300 to CPU 410 Standby (Rack 1).
* The Dynamic Switchover Attempt:
Engineers frequently write logic in the S7-300 to detect which H-CPU is currently Master and dynamically switch the ID input parameter on PUT (FB15) and GET (FB14) blocks from Connection 1 to Connection 2.

Root Cause of Error Code 4 and the 50-Byte Payload Boundary

Two distinct technical limitations cause failure when switching master controllers:
1. Error Status Code 4 (STATUS = 4):
According to the STEP 7 System Software Reference:
* Status 4: "Negative acknowledgment from partner CPU. The requested service does not exist or access error / area length error on partner."
* In S7-300, the ID parameter on PUT / GET blocks is evaluated when the block is initialized. Changing the ID parameter on the fly while a request (REQ) is pending or without executing an instance reset causes the block state machine to attempt writing to an un-negotiated connection channel.
2. The 50-Byte Payload Bottleneck:
* S7-300 standard communications processors and onboard PN ports negotiate a Protocol Data Unit (PDU) size of only 240 bytes (unlike S7-400, which supports 480 bytes).
* Inside each S7 communication frame, protocol headers, security tags, and variable address descriptors consume 30 to 60 bytes.
* When redundant partner synchronization occurs, additional coordination bytes are exchanged. If a data block transfer of 200 bytes exceeds the single negotiated PDU, the S7-300 must fragment the transmission. S7-300 standard PUT/GET blocks do not handle multi-PDU fragmentation transparently, throwing error 4. Reducing the payload to 50 bytes fits comfortably within a single unfragmented PDU.

Comparison Table: S7-300 vs S7-400 Communication Capabilities

The table below outlines technical communication boundaries between controller families:

Communication FeatureStandard S7-300 (e.g., CPU 314-2 PN/DP)Redundant S7-400H / CPU 410-5HMax PDU Size240 bytes (standard) / 480 bytes (newer PN)480 bytesFault-Tolerant S7 ConnectionNot SupportedFully Supported nativelyBumpless Redundancy SwitchoverRequires manual dual connection logicAutomatic hardware-level failoverMax Usable Payload per S7 Job~160 to 200 bytes (Single PDU)Up to 400+ bytes per PDURecommended Block SetBSEND / BRECV or Industry LibraryBSEND / BRECV or APL Blocks

Architectural Solutions for Cross-System Controller Coupling

To achieve stable communication across redundant switchovers:
* Option A: PCS 7 Industry Library (Recommended):
Use the PCS 7 Industry Library (6ES7658-1EX08-1YB5). It includes specialized communication function blocks (IL_S7PUT and IL_S7GET or S7Con_S3) designed specifically to handle automatic connection failover between S7-300/1500 and redundant S7-400H systems.
* Option B: Dual-Instance Static Interlocking:
Instead of dynamically modifying the ID on a single block instance, instantiate two dedicated PUT blocks in the S7-300:
* PUT_Rack0 permanently assigned to Connection ID 1.
* PUT_Rack1 permanently assigned to Connection ID 2.
Use master state coordination bits to enable only the active master's block instance, ensuring both connection state machines remain clean.
* Option C: Segmented Data Payloads:
Limit payload transfers to chunks of 100 bytes or less to prevent PDU fragmentation errors.

Step-by-Step Procedure to Implement Robust Cross-CPU Data Exchange

Configure Connections in NetPro:
In NetPro, configure two unilateral S7 connections from the S7-300 station to the S7-410 station:
* Connection 1: Partner = AS410 Rack 0 (Local ID: 16#0001).
* Connection 2: Partner = AS410 Rack 1 (Local ID: 16#0002).
Implement Dual Static PUT/GET Instances in S7-300:
In the S7-300 program (CFC or SCL), call separate instances:
pascal // Example SCL logic for redundant PUT handling IF #AS410_MasterIsRack0 THEN "PUT_Instance_Rack0"(REQ := #TriggerPulse, ID := W#16#0001, ...); ELSIF #AS410_MasterIsRack1 THEN "PUT_Instance_Rack1"(REQ := #TriggerPulse, ID := W#16#0002, ...); END_IF;
Structure Data Blocks into Compact Chunks:
Consolidate process variables into a dedicated communication Data Block (e.g., DB50) with a maximum length of 100 bytes.
Coordinate Master/Standby Health Bit:
Transmit an alternating heartbeat bit from both CPU 410 partners. The S7-300 evaluates which rack is active and directs communication to the healthy master without connection dropouts.

Verification

To verify robust cross-controller communication:
1. Establish communication between S7-300 and CPU 410-5H. Verify data exchange is active with STATUS = 0.
2. Initiate a manual master-standby failover on the CPU 410-5H (e.g., via SIMATIC Manager or by stopping CPU Rack 0).
3. Confirm that the S7-300 detects the switchover and resumes transmitting data to Rack 1 within 500 ms.
4. Verify that PUT status remains 0 (or returns 0 after brief switchover) and never halts on error status 4.

Limitations and Operational Precautions

Unilateral Security Restrictions: On modern CPU 410-5H firmware (V8.2+), ensure that Permit access with PUT/GET communication from remote partner is checked in CPU Hardware Properties -> Protection tab.
No Safety Data via PUT/GET: Never use standard PUT/GET communication for fail-safe safety interlocks. Safety data between independent safety controllers must use F_SendS7 and F_RcvS7 or DP/DP couplers.
Licensing Disclaimer: Utilizing the PCS 7 Industry Library (6ES7658-1EX08-1YB5) requires engineering and runtime licenses validated against the applicable Siemens catalog and authorized distributor quotation.