Troubleshooting S7 PUT/GET Communication Failures: Data Block Length Mismatches and Write Permissions

When S7 communication using PUT (FB15) or GET (FB14) fails to write data into newly created Data Blocks (DBs) between S7-400 and S7-300 controllers, the root cause is almost always an address range mismatch where the remote DB length is smaller than the pointer slice specified in the ADDR parameter, or missing S7 communication permissions in CPU properties. In S7 communication, the remote target DB must exist and have a defined length equal to or greater than the transmitted BYTE count. If the DB is too short, PUT silently aborts with ERROR = 1 and STATUS = 16#0004. Expanding the remote DB length and compiling/downloading to both PLCs restores communication.

Mechanics of S7 Communication: PUT (FB15) and GET (FB14)

In SIMATIC PCS 7 and STEP 7 architectures, cross-controller communication between distinct automation stations (e.g. S7-400 to S7-300, or across separate project boundaries) is frequently engineered using S7 Communication system function blocks PUT (FB15) and GET (FB14). These blocks operate over configured S7 connections (bilateral or unilateral) in NetPro.

The defining advantage of PUT/GET is that communication is configured and triggered entirely on the local client CPU; the remote partner CPU requires no communication code, acting as a passive server handling data reads and writes in the background.

Root Causes: Buffer Length Mismatches and Pointer Address Boundaries

When an engineer adds a new Data Block on the partner CPU and attempts to write data using PUT, data often fails to transfer, appearing as all zeros unless modified manually via a Variable Table (VAT). Field investigations identify three primary flaws:

Remote DB Length Underflow: The ADDR_1 parameter defines an ANY pointer (e.g., P#DB100.DBX0.0 BYTE 64). If DB100 was created on the remote CPU with only 20 bytes allocated, the remote operating system rejects the write operation entirely to prevent memory corruption.
Missing Remote DB Download: If the newly created DB was saved offline in SIMATIC Manager but was not downloaded to the target CPU's load/work memory, the remote CPU returns status 16#0001 (DB does not exist).
Data Type Alignment and Offset Overlap: Byte-level offsets that misalign with structure definitions cause data to write into adjacent variables.

Target CPU Memory Constraints and DB Download Verification

S7-300 and S7-400 CPUs handle memory allocation differently:

In S7-300, DBs created in the block folder must be compiled and downloaded individually or via full user program transfer.
In S7-400, verify work memory allocation in CPU Properties -> Memory. If work memory is full, new DB downloads fail silently.
Open the Online view of the remote CPU's block folder and verify that the target DB is present with the expected byte length.

CPU Security Permissions: PUT/GET Access Restrictions

In modern S7 controllers (such as S7-300 with modern firmware, S7-1500, or newer S7-400 platforms):

CPU hardware properties include a security setting: 'Permit access with PUT/GET communication from remote partner'.
If this checkbox is disabled in HW Config, the CPU drops all external S7 write and read requests.
Furthermore, Data Blocks must use standard (non-optimized) layout, which is the native format in SIMATIC PCS 7 / STEP 7 V5.x.

Comparative Error Status Matrix for S7 Communication Blocks

The following table decodes status returns from PUT (FB15) and GET (FB14):

Status Code (STATUS)Error Flag (ERROR)Operational MeaningDirect Engineering Remedy16#00000Job completed successfullyNormal operation; data transferred16#00011Communication problem / Partner DB missingVerify remote DB exists in target CPU online block folder16#00041Pointer error / Address length out of boundsRemote DB byte length is smaller than ADDR_1 ANY pointer length16#00081Access error on partner CPUEnable PUT/GET access in remote CPU hardware configuration16#00141Connection not configured or ID incorrectVerify Connection ID matches S7 connection in NetPro16#00191Negative acknowledgment from communication partnerPartner CPU in STOP or communication buffer exhausted

Step-by-Step Diagnostic and Resolution Workflow

Follow this troubleshooting workflow to restore PUT/GET transfers:

Inspect STATUS Output: In CFC or VAT, monitor outputs DONE, ERROR, and STATUS on the PUT block instance. (Note: STATUS is only valid for one cycle when ERROR = 1; use an edge-triggered latch to capture the hex error code).
Verify Remote DB Size: In SIMATIC Manager on the partner project, open the target DB. Calculate total byte size (e.g., 0 to 63 = 64 bytes). Ensure the DB declaration has sufficient arrays or variables to cover the full length.
Download Remote DB: Perform an explicit download of the DB to the remote PLC. Go online and verify the DB is present.
Align ANY Pointer: On the local CPU calling PUT, verify ADDR_1 parameter matches the remote DB structure: P#DBxx.DBX0.0 BYTE <Length>. Ensure local send pointer SD_1 matches P#DB_Local.DBX0.0 BYTE <Length>.
Trigger Job Correctly: Ensure input REQ is pulsed with a positive edge when the previous job is complete (DONE = 1 or ERROR = 1). Never tie REQ permanently to TRUE.
Validate Transfer: Modify a value in the local send DB and confirm it updates in the remote DB.

Verification

Confirm reliable communication through these verification steps:

Online VAT Monitoring: Open a Variable Table on both PLCs simultaneously. Modify an integer in the source DB; observe immediate update in target DB.
Block Diagnostics: In CFC test mode, confirm PUT.DONE = 1 pulses regularly and PUT.ERROR = 0.
NetPro Connection Status: In NetPro, select the CPU and click Activate Connection Status. Confirm the S7 connection displays status Set up (Established).

Limitations and Operational Precautions

Observe the following safeguards:

Deterministic Real-Time Boundaries: S7 communication (PUT/GET) is an uncoordinated background service processed in CPU communication slices. It is not deterministic. For hard real-time interlocking (e.g. safety or high-speed synchronization), use direct I/O coupling (DP/DP Coupler) or BSEND/BRCV.
Unilateral Security Risks: PUT allows one controller to overwrite data in another without authorization checks in the server PLC code. Document all cross-controller write areas thoroughly to prevent accidental overwrite of critical control loops.
Commercial Accuracy Disclaimer: Software order numbers (MLFBs), package structures, and hardware capacity prerequisites vary across PCS 7 versions and hardware platforms. System integrators must confirm exact software entitlements and licensing requirements against the official Siemens Catalog CA 01 and obtain an authorized Siemens distributor quotation prior to purchasing.

Engineer FAQ

How do I capture the error STATUS code on PUT if it resets immediately?

Use edge detection on ERROR to latch the word value of STATUS into a helper static variable: IF ERROR THEN Latched_Status := STATUS; END_IF;.

Why should REQ not be permanently tied to TRUE?

Permanently asserting REQ attempts to initiate a new communication job every CPU cycle, saturating the controller communication queue and causing job rejections.

What is the maximum data length that can be transferred in a single PUT job?

Between S7-400 controllers, PUT can transfer up to 400 bytes per data area (depending on the CP and PDU size limits). For larger blocks, use BSEND/BRCV.