Configuring S7-300 CP 343-1 S7 Connections in NetPro for GET/PUT

1. Overview: S7 Communication Between Two S7-300 Stations

S7 communication is the Siemens-proprietary application-layer protocol used to exchange data between S7-300 and S7-400 controllers. The transport is flexible: the same S7 services (read, write, status, block functions) can be carried over MPI, Profibus, or Industrial Ethernet. When the physical layer is Ethernet, the S7-300 CPU offloads the TCP/IP stack to a communications processor - the CP 343-1 - which terminates ISO-on-TCP (RFC 1006) on port 102 and bridges the Ethernet packets into the S7-300 backplane. The CPU is unaware of TCP/IP details; from its perspective, the S7 connection terminates at the backplane slot of the CPU, and the CP is a transparent stepping-stone.

Establishing a handshaking link between two S7-300 stations therefore requires three coordinated steps: assigning an IP address to each CP 343-1 (or, on newer CPUs, to the integrated PN interface of the CPU), defining a configured S7 connection in NetPro for both partners, and calling the standard PUT and GET function blocks in the user program with the connection ID returned by NetPro. For bidirectional status exchange - the typical "I need a few signals saying information was received and correct" requirement - the cleanest approach is a fully specified S7 connection with one active and one passive partner. The "Unspecified partner" option offered by NetPro also works, but it makes the data source anonymous in the project tree, and field experience has shown that this quickly becomes a documentation problem in a multi-PLC plant: technicians cannot tell which partner is sending which byte without a parallel spreadsheet. The active/passive convention is therefore strongly preferred for production networks.

The recommended tool chain is classic STEP 7 V5.x with the SIMATIC Manager and the NetPro editor. TIA Portal uses a different editor called "Devices and Networks" and represents connections as graphical objects between CPU/CP ports; the underlying protocol and parameter set is identical, but the click paths differ. This article focuses on STEP 7 V5.x and references the equivalent TIA Portal documentation in the appropriate places.

2. Prerequisites and Project Planning

• STEP 7 V5.x with the NetPro editor installed (the default installation includes it).
• Two S7-300 stations physically wired through an Industrial Ethernet switch or a crossover cable.
• CP 343-1 modules in both stations (Standard, Lean, Advanced, or IT variants are all supported; the variant affects the number of available S7 connection resources, not the configuration procedure).
• A PG/PC with an Ethernet port, on the same subnet as the CPs, with STEP 7 set to "TCP/IP" as the PG/PC interface (Options > Set PG/PC Interface).
• Either a STEP 7 project containing both SIMATIC 300 stations, or - if the project was lost - the willingness to upload both stations into a fresh project (see Section 7).
• Free S7 connection resources on both CPs. NetPro's "Connection Resources" tab on the CP object shows the maximum number of S7 connections supported by that CP variant; if the limit is exhausted, the new connection is rejected with a download error.
• For the partner station to be able to write into a specific DB, that DB must exist on the partner CPU and must not be optimized (the standard S7-300 DB layout, not the S7-1200/1500 "optimized" layout).

3. Hardware Topology and Addressing

The physical layout is identical to a single-PLC Ethernet station, duplicated and joined through a switch. The following inline diagram shows the rack/slot map that STEP 7 expects in the hardware configuration, with the IP plan that matches the example in Sections 4 through 8.

4. STEP 7 Project and Hardware Configuration

1. Open SIMATIC Manager and create a new project.
2. Insert two SIMATIC 300 stations (Insert > Station > SIMATIC 300 Station). Rename them "Station_Master" and "Station_Slave" to match the field convention.
3. Open Hardware on the first station and assemble the rack: drag in a Rack 300, the CPU 31x module, and the CP 343-1 from the hardware catalog (SIMATIC 300 > CP-300 > Industrial Ethernet > CP 343-1). The exact CP order number depends on the physical module - select the matching entry to keep the firmware consistent.
4. Double-click the CP 343-1 and assign the IP address 192.168.0.10, subnet mask 255.255.255.0. Do not enter a router address unless the network actually requires it.
5. Open the CP's "Properties > Options" tab and verify that "S7 communication" is enabled. The default is usually enabled, but a previously edited project may have disabled it.
6. Repeat steps 3 to 5 for the second station using IP 192.168.0.11.
7. Save and compile (Station > Save and Compile). Resolve any catalog-version warnings by upgrading the module to match the hardware catalog in STEP 7, or by installing the matching HSP (Hardware Support Package).
8. Download the hardware configuration to each CPU separately (PLC > Download to Target System > Selected Station). The CP is configured indirectly: the IP and options are pushed to the CP during the CPU download because the configuration travels through the backplane.

Reference: PTC Knowledge Base: How To Configure S7-300/400 Connections in STEP 7 for a parallel walkthrough from the connectivity-driver perspective.

5. Configuring the S7 Connection in NetPro

NetPro is where the connection is bound to a local resource on the local CP and a partner resource on the remote CP. The block diagram of a configured S7 connection has the following form:

1. Open NetPro (Options > NetPro, or click the NetPro icon in the SIMATIC Manager toolbar).
2. Click once on the CP 343-1 of PLC #1. A yellow highlight bar appears at the bottom of the CP graphic, indicating that a connection can be inserted on this resource.
3. Right-click the CP and choose "Insert New Connection". The Insert New Connection dialog opens.
4. Configure the dialog:
   • Connection partner: if both stations are in the STEP 7 project, select "SIMATIC 300 Station 2". If only one station is in the project, select "Other station" and enter the partner's IP, rack, and slot manually.
   • Connection type: "S7 connection". Other types (ISO transport, TCP, UDP) are also available, but for S7-300 PUT/GET the S7 connection is the correct choice.
   • Active connection establishment: tick this for PLC #1, leave it unticked for PLC #2. The active end initiates the TCP connect; the passive end waits for incoming connection requests.
   • Local ID: STEP 7 auto-assigns a hex ID (typically 1 for the first connection). Note this ID - it is the value that goes into the PUT/GET block parameter ID.
   • Partner IP address: 192.168.0.11.
   • Partner rack / slot: 0 / 2 (the CPU position on the partner station).
   • Connection resource on partner: STEP 7 auto-selects a free S7 connection resource on the partner CP (e.g., 1). Both stations' NetPro must agree on this value - the editor will warn if the resource is already in use.
5. Click OK. The connection appears as a green line between the two CPs in the NetPro graphical view.
6. Select NetPro > PLC > Download to download the connection configuration to both PLCs. The CP must be online - verify the CP appears in the "Accessible Nodes" browser with its MAC and IP.
7. Open the connection's "Object Properties" (right-click > Object Properties) and verify the General tab shows the same Local ID on both ends of the connection. NetPro automatically creates a mirror connection on the partner station; if the partner is "Other station", you must manually create the matching connection in the partner's NetPro (or accept that the partner runs with an "unspecified" connection, which works but is documented poorly).

Reference: Siemens S7 Connection - Technical Instructions (PDF) and the TIA Portal equivalent, S7 connection - general settings (S7-300, S7-400, S7-1500).

6. GET and PUT Block Programming

The two function blocks used for S7-300 S7 communication are part of the "Standard Library > Communication Blocks" collection. The exact FB numbers depend on the STEP 7 version and library revision, but the canonical blocks are:

When the GET or PUT block is inserted, STEP 7 prompts for an instance DB (DB of instance). The instance DB stores the connection parameters in its background - STEP 7 then links the call to the NetPro connection when the user right-clicks the block, picks "Connection...", and selects the connection from the dropdown. This writes the ID parameter into the instance DB permanently.

Sample PUT call (Structured Text):

// PUT - write 10 bytes from local DB20 to partner DB30 starting at byte 0
       CALL  "PUT" , "I_DB_PUT"
        REQ   :=M0.0              // Rising edge triggers one PUT job
        ID    :=W#16#1            // Local ID from NetPro (hex)
        DONE  :=M10.0             // One-shot complete (no error)
        ERROR :=M10.1             // Error bit
        STATUS:=MW12              // Status word (16-bit)
        ADDR_1:=P#DB30.DBX 0.0 BYTE 10   // Partner target address
        SD_1  :=P#DB20.DBX 0.0 BYTE 10   // Local source data

Sample GET call (Structured Text):

// GET - read 10 bytes from partner DB40 into local DB21
       CALL  "GET" , "I_DB_GET"
        REQ   :=M0.1              // Trigger
        ID    :=W#16#1            // Same Local ID as PUT on this station
        NDR   :=M10.2             // New data received (one-shot)
        ERROR :=M10.3             // Error bit
        STATUS:=MW14              // Status word
        ADDR_1:=P#DB40.DBX 0.0 BYTE 10   // Partner source address
        RD_1  :=P#DB21.DBX 0.0 BYTE 10   // Local target

For ladder logic users, the same blocks appear with input pins on the left and status contacts on the right. Right-click the block body and pick "Connection..." to bind to the NetPro connection - this writes the ID parameter into the instance DB, so subsequent edits to NetPro will not change the ID unless the user re-binds. Common binding mistakes:

• Binding to the wrong NetPro connection when the project has multiple S7 connections to different partners.
• Leaving the block "unbound" - the ID then shows the default value 0, and the connection is rejected at runtime with STATUS = 16#8184.
• Forgetting to copy the instance DB to the partner CPU. PUT/GET use the local instance DB; the partner CPU does not need a matching instance DB on its side, but the partner DBs referenced in ADDR_1/RD_1 must exist and have the expected length.

7. Uploading an Existing Connection Configuration

A common field problem is that an integrator hands over a project that uses PUT/GET but contains no S7 connections in NetPro. The user code in the offline project shows GET and PUT calls, but the connection is nowhere to be found. This is because S7 connection configuration is stored in the connection DBs of the CPU (specifically, in the system data blocks SDBs), not in the user's offline blocks. SIMATIC Manager's "Upload to PG" from the Blocks folder does not include SDBs by default; the correct upload path is:

1. Create a new empty STEP 7 project.
2. Open NetPro (Options > NetPro).
3. From the NetPro menu, choose PLC > Upload Station to PG/PC.
4. The "Select Station" dialog opens with empty Rack and Slot fields. Click "View" to scan the network - the CPs and CPUs on the local subnet appear as reachable nodes.
5. Select the target CPU from the discovered list. Set Rack = 0 and Slot = 2. The slot refers to the CPU position, not the CP slot.
6. Click OK. The full station - including the hardware configuration and all S7 connections stored in the CPU - uploads into the new project. The connection table from the partner side is also reconstructed if the partner is reachable.

The uploaded configuration preserves the original Local IDs. Once the S7 connections are visible in NetPro, the PUT/GET block IDs can be cross-referenced against the Local ID column of the NetPro table to confirm they match. If they do not match, edit the instance DB's STAT "ID" parameter to the correct hex value, or right-click the block and rebind through "Connection...". When the original project is recovered, the standard recovery sequence is:

1. Ask the original integrator for the offline STEP 7 project including the NetPro connections. This is the cleanest path.
2. If the offline project is unavailable, use the upload procedure above to reconstruct the connections into a new project.
3. Re-bind every PUT and GET block to the matching NetPro connection. The block instance DBs from the upload can usually be reused unchanged.
4. Download the new project to both PLCs to push the corrected connection configuration.

Reference: Siemens SiePortal: Help connecting to a Simatic S7-300 for additional context on upload-and-recover procedures.

8. Handshake and Status Word Implementation

For a robust handshake between the two PLCs, dedicate two words in each direction: one for the command/request code and one for the acknowledge/status. The PUT/GET cycle then becomes:

1. PLC #1 (active) writes its command (e.g., 16#0001) and a sequence counter into local DB20.DBW0 and DB20.DBW2, and PUTs both to partner DB30.DBW0 and DB30.DBW2.
2. PLC #2 receives the data via GET into its local DB20.DBW0 and DB20.DBW2. The user program processes the command, increments a local echo counter, and writes the result into local DB40.DBW0 / DB40.DBW2.
3. PLC #2 PUTs the result back to PLC #1's local DB21.DBW0 / DB21.DBW2.
4. PLC #1 reads the echo with GET and compares the sequence counter to the last value sent. A change confirms that the partner has processed the most recent command.

Wrap the PUT/GET in OB1 (cyclical, low overhead) or OB35 (time-staggered for deterministic rate). For deterministic timing, use a clock generator (e.g., a 1-Hz pulse from the CPU's clock bit or a self-resetting timer) to drive REQ, and reset the watchdog whenever the SEQ_ECHO matches the SEQ sent. A timed watchdog (DB21.DBW4 incremented every second in PLC #2) lets PLC #1 detect a stalled handshake within a known time and force a reconnect by toggling the connection through the connection-status word in the instance DB.

For higher reliability, use BSEND/BRCV instead of PUT/GET. BSEND/BRCV:

• Supports variable-length data blocks (PUT/GET require a fixed length known at compile time).
• Provides a coordinated handshake at the protocol level, so the application does not have to implement its own echo counter.
• Resumes after temporary network outages more gracefully than PUT/GET, which require a new REQ pulse after a STATUS error.

9. Troubleshooting Matrix

For the complete Siemens-published list of PUT/GET STATUS codes, refer to the S7 Connection technical instructions PDF and the STEP 7 online help for FB 14 / FB 15.

10. Verification and Online Diagnostics

1. After downloading NetPro to both PLCs, open NetPro, right-click the S7 connection, and pick "Connection Status". The status should read "Established" within a few seconds. A persistent "Not established" or "Disconnected" indicates a configuration or IP-routing problem; open the CP's diagnostic buffer for the reason code.
2. Online in OB1, monitor the DONE, NDR, ERROR, and STATUS outputs of the GET/PUT instance DBs. Force REQ and watch the cycle: REQ → ACTIVE → DONE/NDR (good path) or REQ → ERROR + STATUS (diagnose the value from the matrix in Section 9).
3. Open the CP's diagnostic buffer (PLC > Module Information > Diagnostic Buffer) on both CPs. S7 connection events appear as "S7 connection established / aborted" with the connection ID, partner IP, and reason codes. The reason code is the most direct way to identify a routing, partner, or protocol issue.
4. For long-term monitoring, write the most recent DONE/NDR/ERROR bits and the last STATUS value into a dedicated DB and display them on the HMI or in WinCC. Include the sequence counter and the watchdog time stamp from Section 8 so that operators can see handshake health at a glance.
5. For a final acceptance test, disconnect the partner Ethernet cable and verify that the local block surfaces a STATUS error within a few seconds, then reconnect the cable and verify that the handshake recovers without a CPU restart or NetPro re-download.

11. Frequently Asked Questions