Configuring GET_S for S7-300 Ethernet: Resolving Error Code 1 in TIA Portal V14 Cross-Project S7 Communication

When an S7-300 station configured in STEP 7 V5.5 and a second S7-300 station configured in TIA Portal V14 must exchange data through PUT and GET_S blocks, the client CPU frequently returns error code 1 immediately on the first call. The connection appears under the online "Connections" tab as Exists offline only, then flips to Faulty, although both CPUs are reachable as accessible devices and the reverse direction (PUT from V5.5 → V14) works correctly. The root cause is an incorrect connection configuration for cross-project S7 communication; the fix is to use an unspecified S7 connection on the GET_S side and download that configuration only to the client CPU.

1. Problem Statement and Symptoms

Field symptoms reported with the V14 configuration:

• GET_S (FB 20, family S7 communication, standard library) returns STATUS = W#16#0001 on the first call and never leaves that state.
• Online view of the client CPU → "Connections" tab shows the configured partner as Exists offline only, then transitions to Faulty within one refresh.
• Both CPUs appear in "Accessible devices" with their PROFINET/CP IP addresses, confirming layer-1/layer-2 reachability.
• PUT from the V5.5 project (which calls the V14 partner) succeeds, proving the Ethernet path and the remote DB are valid.
• Only one GET_S job is in use; no resource exhaustion on the client.

The asymmetry between PUT (works) and GET_S (fails) is the diagnostic fingerprint: it indicates the failure is on the V14/TIA side of the S7 connection, not on the network, not on the partner, and not on the data area.

2. System Configuration Reference

The CP 343-1 (EX30) supports up to 16 S7 connections for S7 communication, PUT/GET included. The CPU 315-2 PN/DP integrated PROFINET interface supports up to 16 S7 connections, but the S7 communication services are limited to operator interface, program, and S7 routing roles when the PN interface is used alone; pairing with CP 343-1 is the recommended path for pure S7 PUT/GET between two S7-300 stations.

3. Root Cause Analysis

Error code W#16#0001 on GET_S (FB 20) means connection error — the partner is not reachable on the configured connection or the local resource could not establish it. The TIA V14 "Faulty" state of the partner entry confirms that the local S7 connection DB could not be initialized to a usable endpoint.

The architectural reason is the S7 connection model in TIA Portal V14:

• Project-internal S7 connection: Both endpoints exist inside the same TIA project. TIA creates the connection in both PLCs, assigns a matching Local ID / Partner ID, and the user downloads the connection configuration to both stations.
• Project-crossing S7 connection (this case): The partner is configured in a different engineering project (here STEP 7 V5.5). TIA cannot generate a partner endpoint that exists in the V5.5 project, so any project-internal connection type will fail to validate and download correctly. The remedy is the unspecified connection.

On a TIA cross-project S7 connection, only the side that actively opens the connection (i.e. the CPU where the GET_S/PUT block runs) needs the connection DB. The partner CPU is configured only as a passive partner by having the relevant data blocks present and accessible; its S7 connection side is implicitly the matching end of the TCP/ISO-on-TCP socket opened by the active CPU.

Two additional secondary causes produce the same STATUS = 1 symptom in the field and must be ruled out before declaring the connection type the cause:

1. CP 343-1 IP address / subnet mismatch between the offline TIA project and the online CP.
2. Connection resource exhausted on the CP — the CP firmware reports a connection-limit error (W#16#80C3) which the GET_S block surfaces as STATUS = 1 after a few retries.

4. S7 Communication Architecture Used by GET_S

GET_S (FB 20, IEC-style counterpart to the legacy GET / SFB 14 pair) is part of the "SIMATIC 300/400, Standard Library → Communication Blocks" set. It uses the S7 protocol over an ISO-on-TCP (RFC1006, port 102) transport channel established by the local CPU/CP. The block behaves as a S7 client that:

1. Opens the S7 connection referenced by the ID input (DWORD, points at the local connection DB or the local endpoint ID).
2. Transmits a read request for the area defined by REQ, SD_i (source address on partner), and LEN_i.
3. Waits for the read response from the partner CPU.
4. Writes the received data into the RD_i (receive destination) area on the local side.
5. Sets DONE = 1, ERROR = 0 on success, or ERROR = 1 with STATUS set to the W#16#xxxx error code on failure.

Because step (1) requires a working S7 connection before the read can even be issued, the very first execution of GET_S with a non-existent connection always returns STATUS = W#16#0001. The block does not retry — the application must retrigger REQ or call the block cyclically with a rising edge at REQ.

5. Configuring an Unspecified S7 Connection in TIA V14

The correct configuration for cross-project S7 communication from the V14 client is an unspecified S7 connection on the CPU that calls GET_S. Steps:

1. In the TIA Portal V14 project tree, select the client CPU (the CPU 315-2 PN/DP that owns the CP 343-1 used as the Ethernet interface).
2. Open Properties → Communication → S7 connections, or, in Devices & Networks, add a new connection of type S7 connection.
3. Choose the local endpoint as the CP 343-1 (Ethernet interface), not the PN port of the CPU. The CP owns the IP and the S7 connection resources for S7 communication.
4. In the Partner field, select "Unspecified". Do not browse the project for the partner CPU — the partner is not part of the TIA project.
5. Enter the partner IP address (the IP of the remote CP 343-1, e.g. 192.168.0.10). Use the S7 connection port 102 (default, ISO-on-TCP).
6. Set the Connection resource on the local CP to a free local ID, e.g. W#16#0001 to W#16#000F. Avoid duplicates — the local ID must be unique within the CPU.
7. Set the Active connection establishment checkbox to enabled on the client side. The server side (V5.5) is configured passively by STEP 7 V5.5 with the active-establishment flag cleared.
8. Compile the project. The connection is now owned by the TIA V14 client only; the V5.5 project does not need a matching entry because its connection is created by V5.5's own S7 connection editor and downloaded to the V5.5 CPU.
9. Download the project only to the TIA V14 CPU/CP. The CP receives its S7 connection DB and the active-establishment parameter; the V5.5 side remains untouched.

6. GET_S / PUT Parameter Mapping

For the symmetric PUT (FB 15) on the V5.5 side, swap SD/RD semantics: the V5.5 PUT is the active write into the V14 partner's data area, with its own connection ID created in V5.5 and a matching passive S7 connection in the V14 TIA project (or the reverse: active on V14, passive on V5.5 — both directions can be active in their own S7 connection).

7. S7 Connection Establishment on the Wire

The ISO-on-TCP transport connection is opened with a standard RFC1006 handshake. For the cross-project case, the TCP three-way handshake is initiated by the active partner (the V14 CPU in this scenario), which then performs the S7 CR (Connection Request) TPDU. The partner CC (Connection Confirm) TPDU references the configured local ID of the partner. The S7 connection remains open until either side sends a DR (Disconnect Request) or the keep-alive times out (default 30 s on the CP 343-1).

When the V14 project is downloaded with the unspecified S7 connection, the CP 343-1 stores the connection record in its connection table (max. 16 entries for S7 connections on EX30). The connection record contains:

• Local TSAP (transport service access point, e.g. 10.00 for the CP 343-1 in slot 1 of rack 0)
• Remote TSAP (the S7 partner's TSAP; in the V5.5 project this is the slot 1 CP TSAP, e.g. 10.00, or a custom TSAP if explicitly set)
• Local IP / remote IP
• Connection role (active / passive)
• Local ID (W#16#0001 in this case)

8. GET_S / PUT Error Code Reference

The full STATUS list is published in the SIMATIC standard library help and in the TIA Portal V14 Online Help under Communication Blocks → GET_S / PUT.

9. Step-by-Step Resolution Procedure

1. Verify the CP firmware version. The CP 343-1 (EX30) must run at firmware V3.0 or higher for compatibility with TIA V14 projects. Older CP 343-1 EX11/EX21 firmware limits the S7 connection table and may produce STATUS = 1 on the active side. Use Online & Diagnostics → Module Information to read the firmware; update the CP if needed.
2. Confirm both CPUs are online and reachable. In TIA V14, Online → Accessible Devices must list both CP 343-1 modules with their IP addresses. If one is missing, fix the Ethernet path first — the S7 connection cannot work without layer-1/layer-2 reachability.
3. Check the partner's IP address and TSAP. The TSAP of the partner (V5.5 CPU / CP) must be entered correctly in the unspecified connection. Default TSAP for an S7-300 CP in slot 1 is 10.00 for S7 communication.
4. Replace the project-internal connection with an unspecified connection. Follow section 5. The TIA V14 project must not reference a CPU that does not exist inside the TIA project.
5. Set the active-connection-establishment flag on the V14 client only. The V5.5 partner must be passive (default for S7 connection in V5.5). If the V5.5 project has the partner as active too, the connection will not be established because both endpoints wait for the other.
6. Download only the V14 client CPU + CP. Do not attempt to download to the V5.5 CPU; that belongs to a foreign project. The S7 connection DB on the CP 343-1 is built from the local connection record downloaded to the V14 CP.
7. Verify the S7 connection online. In TIA, go Online → Online & Diagnostics on the CP 343-1 → Functions → Connection Diagnostics (in some firmware versions: Connection Status). The S7 connection should show ESTABLISHED within a few seconds after the first GET_S call with rising REQ.
8. Call GET_S cyclically with rising edge on REQ. Wire a clock-bit or one-shot to REQ. STATUS = 0001 on the first call is normal if the connection is still being established; the second call should report success.
9. Check the partner DB. Confirm that the DB referenced in SD_1 exists on the V5.5 CPU and is not optimized (S7-300 only supports standard DBs, not optimized — S7-300 has no optimized DB concept, so the default is fine). The DB must be loaded and accessible without password protection if the S7 connection is configured without password.
10. Capture a Wireshark trace (optional, advanced). Filter on tcp.port == 102. The S7 connection request should appear from the V14 client IP to the V5.5 partner IP. If no SYN is visible, the issue is the local S7 connection DB (recheck section 5). If SYN is sent and SYN-ACK is received but no S7 CR follows, the TSAP is wrong.

10. Verification and Acceptance Test

After downloading the V14 project with the unspecified connection, run the following checks before declaring the line production-ready:

1. Online connection status = ESTABLISHED. Confirm in the CP 343-1 online diagnostics. The S7 connection record should show partner IP and TSAP correctly and a non-zero "active since" timestamp.
2. GET_S DONE = 1, ERROR = 0, STATUS = 0000. On the V14 client, the first successful read populates the local RD_1 area with the data from the partner DB.
3. Cross-check in the watch table. Open a watch table in TIA V14 with the partner DB contents (if mirrored through a PUT) and the local receive DB; they should match.
4. PUT/GET symmetry. Trigger a write from V5.5 (PUT) and a read from V14 (GET_S) for the same data block; both should complete with STATUS = 0000 within one cycle each.
5. CPU STOP/RUN test. Stop the V14 CPU. The V5.5 PUT should report STATUS = 0007 (reset). Restart the V14 CPU. The next GET_S should re-establish automatically and return STATUS = 0000 without manual download.
6. Cyclic re-trigger test. Force REQ = 0 for several seconds, then re-trigger. The job should complete each time without leaking resources on the CP.

11. Common Field Pitfalls and Their Diagnostics

12. TIA Portal V14 Specifics Relevant to This Case

TIA Portal V14 introduced changes to the S7 connection editor and the way partner endpoints are validated. Notable items for cross-project S7 communication:

• The Unspecified partner option is the only project-crossing connection type supported for S7 connections to non-TIA or non-imported partners in V14.
• The connection resource (Local ID) is assigned by TIA when the connection is created; you can re-map to a free ID but the value must be unique within the local CPU/CP and must match the ID input of GET_S / PUT.
• For S7-300 + CP 343-1, V14 SP1 or later is recommended because earlier V14 builds had a known issue where the unspecified connection's partner IP was not always committed to the CP's S7 connection record until the project was re-compiled and downloaded a second time. The TIA Portal V14 update history and the Siemens Industry Online Support entry "Changes in TIA Portal V14" cover this and other V14 changes; consult the official V14 release notes for the exact fix list.
• V14's project view shows the connection under Connections on the local CPU; if the partner is unspecified, the online view shows the partner as a generic entry, not as a CPU type — that is the expected state for cross-project communication.

For the full V14 change list, see the official Siemens TIA Portal V14 release documentation at Changes in TIA Portal V14.

13. Field Commissioning Checklist

1. CPU 315-2 PN/DP firmware ≥ V3.3; CP 343-1 EX30 firmware ≥ V3.0.
2. CP 343-1 IP address matches the offline TIA project (subnet, mask, gateway).
3. Partner (V5.5) IP address and TSAP entered in the unspecified S7 connection.
4. Active connection establishment enabled on the V14 client only.
5. Local connection ID noted; matches ID input of GET_S / PUT.
6. Partner data block (DB number, length, type) verified to exist and be accessible on the V5.5 CPU.
7. Project downloaded to V14 CPU + CP; V5.5 project unchanged.
8. CP connection table shows the S7 connection record with status ESTABLISHED after first GET_S call.
9. GET_S returns STATUS = 0000 with correct data; PUT from V5.5 returns STATUS = 0000 with correct data.
10. CPU STOP/RUN cycle of either partner does not require re-download.