S7-300 Ethernet Communication Between TIA Portal and STEP 7 V5.5

Cross-tool S7 communication between an S7-300 programmed in TIA Portal V13 SP1 and an S7-300 programmed in STEP 7 V5.5 is fully supported on Industrial Ethernet. The server CPU is passive and does not require any project modification; only the client (active) PLC is configured with an S7 connection plus the GET/PUT function blocks. This reference documents the field-proven procedure for a CPU 315-2DP plus CP 343-1 pair, including rack/slot addressing, TSAP configuration, instance DB allocation, and resolution of the alternating status codes 1 and 25 (decimal) that appear when the request trigger is set too fast for the server cycle.

1. Problem Definition and Architecture

The classic field scenario is a brownfield plant where one S7-300 was migrated to TIA Portal while a neighboring S7-300 remains on STEP 7 V5.5 because of legacy code, unsupported POUs, or a freeze directive. The two CPUs sit on the same Industrial Ethernet subnet through CP 343-1 modules. Only one side is accessible to the engineer at a time, which is the root cause of most configuration confusion: the operator typically owns the TIA Portal project (PLC1) and needs to pull a few words of process data from the STEP 7 PLC (PLC2) without ever opening STEP 7 V5.5.

The reference topology used throughout this article is:

All CP 343-1 variants (Lean, Standard, Advanced, Gigabit, Security) support S7 connections and the PUT/GET communication primitives documented in this article. The exact CP variant matters only for the number of simultaneously usable S7 connections, ISO-on-TCP, and security features; the configuration steps for PUT/GET are identical.

2. Prerequisites

• Hardware: Two S7-300 stations each fitted with a CPU 315-2DP and one CP 343-1 (or compatible CP 343-1 Lean/Advanced). The CP must be in rack 0, slot 4 by default (slot 4 is the conventional slot for an Ethernet CP in an S7-300).
• Programming software: TIA Portal V13 SP1 (or later V13/V14/V15/V16/V17/V20) on the engineering station; STEP 7 V5.5 on the partner station (any SP level is acceptable).
• Ethernet cabling: Switched Industrial Ethernet, 100 Mbit/s or 1 Gbit/s. Direct crossover is not required.
• IP plan: A free IP address for each CP 343-1 plus the matching subnet mask (255.255.255.0 is typical).
• PG access: Online access to PLC1 from TIA Portal. PLC2 needs to be online only for diagnosis, not for configuration.
• Library blocks: Standard library > Communication Blocks > FB14 "GET" and FB15 "PUT" available in TIA Portal. These are part of the standard scope of delivery and do not require installation of any additional options.

3. Hardware Configuration of the S7-300 in TIA Portal

1. Open the TIA Portal project that contains PLC1. Add a new device, choose SIMATIC S7-300 > CPU > CPU 315-2DP (MLFB 6ES7315-2AH14-0AB0 or compatible).
2. Open the device view of the S7-300. Slot 1 must remain empty. Slot 2 holds the CPU. Slot 3 is empty (or holds an IM). Slot 4 holds the CP 343-1.
3. Drag the CP 343-1 from the catalog (path: Communication > CP 343-1) onto slot 4.
4. Open the CP 343-1 properties > Ethernet addresses. Assign a static IP address (e.g. 192.168.0.10) and subnet mask (255.255.255.0). Disable router usage unless the plant architecture requires it.
5. In the network view, connect the CP 343-1 port to a new PN/IE subnet. Right-click the subnet and confirm it is the type "Ethernet".

For the partner PLC2 (STEP 7 V5.5 side), no TIA Portal project change is required. The IP address on the CP 343-1 of PLC2 must be known (e.g. 192.168.0.11), and the CPU must be reachable in the same subnet. The configuration in HW Config of STEP 7 V5.5 is independent: rack 0, slot 2 = CPU 315-2DP, rack 0, slot 4 = CP 343-1.

4. Creating the S7 Connection in TIA Portal

The S7 connection is configured exclusively on the client (PLC1) side. PLC2 is the unspecified partner and does not need any S7 connection object in its own STEP 7 V5.5 project. This "unspecified" mode is the most common S7 connection type for GET/PUT between S7-300 stations because the server partner is not known inside the client's project database.

1. Open the project tree in TIA Portal and select PLC1. Open Devices & Networks, then the Network view.
2. Click on the CP 343-1 of PLC1. In the inspector window under Properties > General > S7 connection, no new connection will appear yet; you create it from the project tree instead.
3. From the project tree, right-click PLC1 > Communication > S7 connections and choose Add new S7 connection. A wizard opens.
4. Select Unspecified as the partner. The partner is "unspecified" because PLC2 is not part of the TIA Portal project; the partner will be identified only by its IP address at runtime.
5. The local end point is automatically populated with the CP 343-1. Confirm the local interface is the CP (rack 0, slot 4) and not the CPU's integrated PN port.
6. The interface ID (Local ID) is assigned automatically. TIA Portal V13 SP1 starts the Local ID at hex 0A (decimal 10) for the first S7 connection in the project. This is normal and the value does not need to be changed to match STEP 7.
7. Click Finish. The connection is now visible in the project tree under PLC1 > S7 connections.

5. Configuring the Partner Address Details

With the S7 connection created, the next critical configuration is the partner address. Open the connection in TIA Portal and switch to the Address details tab.

Rack/Slot — CPU or CP? The S7 connection for GET/PUT always terminates on the CPU, not on the CP. The CP is the Ethernet transport layer, but the S7 protocol state machine and the data blocks live on the CPU. Therefore the partner Rack/Slot must be 0/2 for an S7-300 (CPU 315-2DP at slot 2 of rack 0). Setting the slot to 4 (the CP slot) will compile without error, but the connection establishment will fail with status W#16#001E (decimal 30) "connection partner not reachable" or W#16#0001 "communication error". This is the most common commissioning error.

TSAP structure. The Transport Service Access Point is a two-byte identifier used by S7 communication. For S7-300 CPUs the default local TSAP is 01.00 for the integrated PN interface and 01.<rack>.<slot> for CP-attached stations. For partner "unspecified" the TSAP is taken from the partner Rack/Slot; for partner "specified" the TSAP is taken from the explicit Connection Resource field. Either way, the TSAP must resolve to a CPU — not a CP — endpoint.

6. Programming the GET Function Block (FB14)

For a read-only scenario where PLC1 polls data from PLC2, FB14 GET is the correct block. The PUT/GET blocks in TIA Portal are found under Instructions > Communication > S7 Communication or, on older TIA Portal V13 SP1 libraries, under Standard library > Communication Blocks.

6.1 Block Interface

For PUT (FB15) the equivalent interface uses SD_1 (send) instead of RD_1 and adds a DONE output. PUT writes from PLC1's local area into PLC2's remote area. PUT is not required if the requirement is strictly read-only.

6.2 Instance DB

FB14 is a function block, not a function, and therefore requires an instance DB. When dragging FB14 from the library into the code area, TIA Portal prompts for the instance DB name. Accept the default "DB_GET" or assign a meaningful name. The instance DB is generated automatically and stores the connection parameters between calls.

6.3 Example Ladder Snippet

// OB1 - Cyclic main
// Network 1: Read 20 bytes from PLC2 DB100 into PLC1 DB200
      A  "Clock_0.5Hz"           // 2-second clock or scan-conditioned pulse
      =  "REQ_GET_DB100"

      CALL  FB14 ,  DB_GET
        REQ   := "REQ_GET_DB100"
        ID    := W#16#000A        // Local ID 10 hex
        ADDR_1:= P#DB100.DBX0.0 BYTE 20
        RD_1  := P#DB200.DBX0.0 BYTE 20
        NDR   := "GET_NDR"
        ERROR := "GET_ERR"
        STATUS:= "GET_STATUS"

The trigger "Clock_0.5Hz" must be a free-running clock bit (e.g. from a CPU clock memory byte) or a one-shot triggered by a configurable time, not a continuously-true signal. A permanently true REQ input causes the client to issue GET jobs as fast as the OB1 cycle allows, overwhelming the server CPU. Section 7 covers this failure mode in detail.

7. Status Code Diagnosis (W#16#0001 and W#16#0019)

When the GET function block returns ERROR = 1 and STATUS alternates between decimal 1 and 25, the root cause is rarely a configuration error. The two values are:

The alternating pattern (1 ↔ 25) is the signature of a request flood. The client is launching GET jobs faster than the server CPU can process them. Each cycle the OB1 sets REQ = 1, FB14 tries to send, and either:

• the server has not yet freed its receive buffer (status 25 = partner resource exhausted), or
• the underlying UDT connection briefly drops under the load (status 1 = communication error).

7.1 Resolution

1. Replace any continuously-true REQ input with a clock or a one-shot derived from the OB1 scan time. Siemens' official "S7-PUT-GET" example uses a clock memory bit such as M10.7 (1 Hz) configured under CPU properties > Clock memory.
2. Make sure the request is rising-edge triggered. A direct feed of a "TRUE" or "M0.0" constant to REQ causes the FB to re-issue the job every OB1 cycle until the partner's resource count is exhausted, then STATUS will switch to 25 and remain there until the partner resets.
3. Optionally, evaluate NDR (GET) or DONE (PUT) and gate the next REQ edge on the previous success. This produces a deterministic, non-overlapping job sequence regardless of the partner's speed.

7.2 Other Common STATUS Values

8. Verification and Commissioning

1. Online diagnostics — TIA Portal: Right-click PLC1 in the project tree > Go online. Once online, open Diagnostics > Online & diagnostics. The connection status of the CP 343-1 is shown; an active S7 connection appears under Communication > S7 connections with state "established".
2. Monitor STATUS: Open the OB1 online monitor and watch the instance DB of FB14. The STATUS word should sit at W#16#7002 (job running) and toggle to W#16#0000 with NDR = 1 for one cycle each time a new read completes.
3. Force the partner data: In STEP 7 V5.5, open the partner PLC2 and write a known pattern (e.g. 16#AA 16#BB 16#CC ...) into DB100. In TIA Portal, monitor DB200 of PLC1. The bytes should match the partner DB100 content.
4. Buffer diagnostic on partner: On PLC2 in STEP 7 V5.5, open PLC > Module Information > Diagnostic Buffer. Look for events "S7 connection established to IP x.x.x.x" and "S7 connection terminated". Spurious terminations indicate network or address mismatches.
5. Network traffic sanity check: Use Wireshark with the S7comm dissector on a mirror port. The TCP port for S7 communication is 102. You should see CR (Connection Request) followed by CC (Connection Confirm) and TPKT/COTP traffic. A high number of DR (Disconnect Request) frames within seconds of a CR indicates a connection that is being repeatedly torn down — typical of a request-flood scenario.

9. Edge Cases and Multi-CP Scenarios

9.1 Multiple S7 Connections in One Project

Each PUT/GET pair requires its own S7 connection object in TIA Portal. The second connection receives Local ID hex 0B (decimal 11), the third 0C, and so on. Pass the matching hex value to the ID input of each FB call. A single FB14 instance cannot serve two distinct partners — only one ADDR_1 / RD_1 per call, only one ID per call.

9.2 Multiple PLC2 Servers on the Same Subnet

Each partner PLC needs its own S7 connection object (with its own IP and rack/slot parameters). The GET block can be called multiple times in OB1 with the same ID, but each call only addresses one partner. To read from three different S7-300 servers, instantiate FB14 three times with three separate instance DBs and three S7 connection objects (IDs 0A, 0B, 0C).

9.3 CPU 315-2DP Without CP — Use Integrated PN

If the CPU 315-2DP is replaced with a CPU 315-2PN/DP (MLFB 6ES7315-2EH14-0AB0), the integrated PROFINET interface is used as the S7 connection endpoint. The Rack/Slot in the Address details then refers to the CPU's integrated port (slot 2, X2 PN interface). The CP slot 4 is not used in this case. The TIA Portal connection wizard will offer both options; pick the one wired to the plant switch.

9.4 Migrating the Partner From STEP 7 to TIA Portal

If PLC2 is later migrated to TIA Portal, the S7 connection on PLC1 can stay "unspecified". The migration tool will add PLC2 to the TIA Portal project, and you can change the connection type to "specified" at that time. Specified connections provide build-time consistency checks (the partner's TSAP and rack/slot are verified at compile) but are functionally identical at runtime.

9.5 Routing Through Multiple Subnets

If PLC1 and PLC2 sit on different IP subnets, a router (e.g. SCALANCE XC, SCALANCE XB, or a router CPU) is required. In TIA Portal, configure the router usage in the CP 343-1 properties and add a default router IP. The S7 connection itself is unchanged; the IP packets traverse the router transparently.

10. Frequently Asked Questions