Siemens S7-300 S7 Communication: PUT/GET Across Separate Projects

Configuring Siemens S7-300 S7 Communication: PUT/GET Across Separate STEP 7 Projects

Overview: The "Unspecified Partner" Problem

When a CPU313C equipped with a CP343-1 LEAN communications processor (order number 6GK7 343-1CX10-0XE0) must exchange a few bytes of process data with ten independently engineered CPU315-2 PN/DP controllers (order number 6ES7 315-2EH14-0AB0 or later) where each remote PLC lives in its own STEP 7 V5.x project, the engineer faces a routing and connection-ownership decision. The remote projects cannot be referenced from the central NetPro database because the integration teams maintain them separately; importing them is rejected because of version mismatches and intellectual-property constraints.

The standard answer is the S7 Communication protocol implemented through the Siemens standard library blocks FB34 "GET" and FB35 "PUT". These FBs establish ISO-on-TCP (RFC 1006) connections over Industrial Ethernet, identify the remote partner purely by IP address and Transport Service Access Point (TSAP), and require only that the local project define the connection as "unspecified" - that is, without referencing the partner's project. The remote partner merely permits S7 connections on the corresponding TSAP and serves or accepts data using its own GET/PUT, server-side, or operator panel blocks.

Hardware & Topology

The reference topology used throughout this article:

• Central station: S7-300 with CPU313C (6ES7 313-5BF03-0AB0 or later) and CP343-1 LEAN (6GK7 343-1CX10-0XE0, firmware V3.0.x).
• Remote stations (x10): S7-300 with CPU315-2 PN/DP (6ES7 315-2EH14-0AB0 or later) - integrated PROFINET interface used for S7 communication.
• Network: Single Industrial Ethernet subnet. Managed switches with IGMP snooping disabled for ISO traffic are recommended, or isolate the S7 traffic onto a dedicated VLAN with ACLs.
• Engineering station: STEP 7 V5.5 SP4 (or later) with the optional S7-Technology / S7-Communication package - though PUT/GET ships in the base "Standard Library".

The CP343-1 LEAN must be assigned a fixed IP address either via the rotary switches on the front panel (last octet only) or through STEP 7 hardware configuration. Each CPU315-2 PN/DP has its own PROFINET interface IP address configured in its own STEP 7 project. Because the projects never converge, IP addresses must be planned jointly by the integration team before commissioning. The MAC address is laser-etched on the front panel of the CP and on the CPU PN port.

Hardware manuals

• CP 343-1 LEAN manual (Siemens support, entry ID 24454475)
• CPU 315-2 PN/DP manual (Siemens support, entry ID 12996906)
• STEP 7 V5.5 Professional system manual (Siemens support, entry ID 109751605)
• S7 Communication Blocks (FB12/13/14/15/34/35) manual entry (Siemens support, entry ID 18610316)

Reference topology diagram

Prerequisites

Before opening NetPro, verify:

1. CP343-1 LEAN firmware >= V3.0. Earlier firmware versions (V2.x) limit S7 connections to 4 and have known interoperability issues with PUT/GET against newer CPU315-2 PN/DP firmware. Update with the SIMATIC Automation Tool or via the Siemens firmware update tool (entry ID 19437938).
2. STEP 7 Standard Library -> Communication Blocks is present and contains FB34/FB35. If missing, re-install STEP 7 from the DVD or download the library from Siemens support.
3. MAC/IP plan documented: every remote CPU315-2 PN/DP has a unique IP, and the TSAP of the local S7 connection on each remote station is agreed (default 03.00 is acceptable on most projects because it points to slot 3 = the integrated PN interface of the CPU315-2 PN/DP).
4. Connection budget calculated: see the next section. A naive installation of the LEAN CP against 10 partners will fail at runtime.
5. Subnet mask and gateway match across all stations. Mismatched masks silently prevent TCP three-way handshake completion and report STATUS = W#16#80A1 at runtime.
6. Watchdog / keep-alive: managed switches between stations must not run aggressive Spanning Tree, Energy Efficient Ethernet (EEE), or storm control that drops idle ISO-on-TCP keep-alive frames every 30 s.

Connection Resource Budget - Critical for the LEAN Variant

The CP343-1 LEAN is a cost-reduced variant. It advertises up to 8 connections in total, of which a strict maximum of 4 are usable for S7 communication (PUT/GET); the remaining are reserved or usable only for PG/OP/HMI traffic depending on firmware. This is documented in the CP343-1 LEAN operating instructions.

Since the central CP343-1 LEAN must talk to 10 remote CPU315-2 PN/DP stations, a single LEAN CP is insufficient. Three engineering options exist:

For this 10-partner architecture the recommended choice is the full CP343-1 (not LEAN), which provides 16 S7 connections - enough headroom for the 10 active connections plus one PG connection for engineering and 5 spare slots for future HMI panels. If a second LEAN is unavoidable, distribute five remote CPUs onto each CP and assign distinct IP subnets to keep IGMP and broadcast domains manageable.

Each remote CPU315-2 PN/DP integrated PROFINET interface supports up to 16 connections. One connection is consumed per partner CPU that calls PUT/GET; the rest stay available for HMI panels, engineering, and routing. Always reserve at least 2 free connections on the remote side for diagnostics and future HMI panels.

S7 Communication Protocol Fundamentals

S7 Communication is Siemens' native application-layer protocol for exchanging typed data (bytes, words, double words, bits, counters, timers) between S7 CPUs over ISO-on-TCP (port 102, RFC 1006). Each connection is identified by:

• Connection ID (ID): a WORD assigned by NetPro that selects which configured connection a GET/PUT call uses.
• Local TSAP: two-byte ASCII identifier (e.g. 03.00 means rack 0, slot 3 - the integrated PN interface; for CP343-1 LEAN use 02.00 or whatever is bound to the CP).
• Remote TSAP: TSAP of the partner station's connection endpoint. For an S7 connection on a CPU315-2 PN/DP the default is 03.00; for a CP the default is typically 02.00 or 10.00.
• Remote IP address: standard IPv4 dotted decimal.

The TSAP is structured as two ASCII characters per byte, so the value displayed in NetPro is dotted - e.g. 03.00 means bytes 0x03 and 0x00. The first byte traditionally encodes the rack/slot for S7-300; the second is the connection index. Both partners must agree on the TSAPs in advance. They are the equivalent of a TCP port for S7-Communication purposes.

Firmware compatibility matrix

NetPro Configuration - Step by Step

1. Open the central STEP 7 project containing the CPU313C + CP343-1 LEAN.
2. Open NetPro from the project window (Options -> NetPro or click the NetPro button in the toolbar).
3. Right-click the CP343-1 LEAN module and choose "Insert New Connection".
4. In the dialog Connection Partner dropdown, select "Unspecified". Do not select "In unknown project" - that option is for S7 routing across an intermediate gateway that is itself unmodeled.
5. In Type, select "S7 connection". Confirm.
6. Double-click the new connection row. The Properties - S7 Connection dialog opens. Switch to the General tab.
   • Local ID: a hexadecimal WORD (1 to 0x0FFF); record this value - it is the ID input to FB34/FB35. Repeat for each remote station; each connection must have a unique ID.
   • Local end point: the CP343-1 LEAN (or CPU313C integrated MPI/DP interface if so wired - though Ethernet is assumed here).
   • Partner address: enter the IP of the remote CPU315-2 PN/DP.
   • Partner TSAP: enter the agreed TSAP, e.g. 03.00 for the integrated PN interface of the CPU315-2 PN/DP.
7. Repeat steps 3-6 for each of the ten remote stations, incrementing the local ID by one each time (e.g. 1, 2, ... 10). All connections should appear in the NetPro matrix with green check marks after a successful compile and download.
8. Compile and download the NetPro configuration to the central CPU. The CP343-1 LEAN now knows about 10 S7 connections; the remote projects do not need to be modified for the central side to "see" them, but they must permit the connection (see Remote-Side Configuration).

Connection matrix - what success looks like

After download, the NetPro matrix shows the CP343-1 LEAN row, and ten green "S7" markers extending to the "Unspecified" column. If any connection shows red, right-click and choose "Connection diagnostics" to view the underlying status word.

Remote-Side Configuration

On each remote CPU315-2 PN/DP project the integration team must configure the matching S7 connection in their own NetPro with the same connection parameters but mirrored: Partner = "Unspecified", Partner address = IP of CP343-1 LEAN, Partner TSAP = local TSAP set in the central project (e.g. 02.00).

Equivalently, the integration team can leave the remote project without a connection entry at all provided the CPU's access protection is set to permit PUT/GET. Modern CPU315-2 PN/DP firmware has a "Permit access with PUT/GET from remote partner" checkbox in the CPU properties under Protection > Connection mechanisms. Without this check, all PUT/GET attempts receive STATUS = W#16#80A2 "access error".

FB34 GET Block - Parameter Reference

FB34 "GET" reads data from a remote CPU. Place a single instance DB per remote station (e.g. DB100 for connection ID 1, DB101 for ID 2, ...). Sample call in STL:

CALL  "GET" , "DB_GET_01"
   REQ   :=M0.0
   ID    :=W#16#1
   ADDR_1:=P#DB20.DBX0.0 BYTE 10
   RD_1  :=P#DB50.DBX0.0 BYTE 10
   NDR   :=M10.0
   ERROR :=M10.1
   STATUS:=MW12
   LEN   :=MW14

Up to four address pairs (ADDR_1..ADDR_4 / RD_1..RD_4) can be issued per call, but the maximum total payload is 76 bytes (firmware dependent) on the CPU315-2 PN/DP integrated PROFINET interface. The CPU313C accepts up to 160 bytes per GET. For "a few bytes" this is irrelevant - just use ADDR_1/RD_1.

GET call sequence explained

When REQ sees a rising edge the FB allocates the connection's send buffer, copies ADDR_i / RD_i pairs into the S7 PDU, and transmits. The CPU continues to execute; the response arrives asynchronously one or two OB1 cycles later. The FB reports STATUS = W#16#7001 on the first cycle after REQ, W#16#7002 on subsequent cycles while waiting, and either NDR plus STATUS = W#16#0000 on success or ERROR plus a hex error on failure. Always test ERROR first, then STATUS, then NDR - never rely on NDR alone because it does not assert on error.

FB35 PUT Block - Parameter Reference

FB35 "PUT" writes data to a remote CPU. Sample call:

CALL  "PUT" , "DB_PUT_01"
   REQ   :=M0.1
   ID    :=W#16#1
   ADDR_1:=P#DB30.DBX0.0 BYTE 10
   SD_1  :=P#DB60.DBX0.0 BYTE 10
   DONE  :=M10.2
   ERROR :=M10.3
   STATUS:=MW16
   LEN   :=MW18

STATUS / Error Code Reference

The full status code table is published in the S7 Communication Blocks (FB12/13/14/15/34/35) manual entry.

Programming Pattern for 10 Stations

For a 10-partner architecture, build a periodic OB35 (or OB1) scan that iterates over an array of connection IDs. Each FB instance must be unique; you cannot loop a single FB instance against ten IDs without re-entrancy issues.

// OB1 fragment - illustrative, simplified
// 10 instance DBs: DB_GET_01 .. DB_GET_10 (multi-instance or standalone)
FOR i := 1 TO 10 BY 1 DO
   CASE i OF
     1: GET_DB_01(REQ := T_Pulse100ms, ID := W#16#1,
                  ADDR_1 := P#DB_REMOTE[1].DB_State BYTE 10,
                  RD_1   := P#DB_CENTRAL.LocalState1 BYTE 10,
                  NDR => bNDR1, ERROR => bERR1, STATUS => wSTAT1);
     2: GET_DB_02(REQ := T_Pulse200ms, ID := W#16#2, ...);
     3: GET_DB_03(REQ := T_Pulse300ms, ID := W#16#3, ...);
     4: GET_DB_04(REQ := T_Pulse400ms, ID := W#16#4, ...);
     5: GET_DB_05(REQ := T_Pulse500ms, ID := W#16#5, ...);
     6: GET_DB_06(REQ := T_Pulse600ms, ID := W#16#6, ...);
     7: GET_DB_07(REQ := T_Pulse700ms, ID := W#16#7, ...);
     8: GET_DB_08(REQ := T_Pulse800ms, ID := W#16#8, ...);
     9: GET_DB_09(REQ := T_Pulse900ms, ID := W#16#9, ...);
    10: GET_DB_10(REQ := T_Pulse1000ms, ID := W#16#A, ...);
   END_CASE;
END_FOR;

Stagger the REQ pulses with a 100 ms clock divider so that only one PUT/GET is in flight per cycle; this avoids bus contention and keeps the OB1 scan time stable. A W#16#7001 to W#16#0000 transition on STATUS indicates a successful poll. Always include a watchdog timer per partner: if NDR/DONE has not toggled within N seconds, raise a comms-loss alarm and fall back to the last known good data.

Verification Procedure

1. Download NetPro to the central CPU. The CP will show "Connection active" in the online diagnostics after the partner responds.
2. Open the partner CPU315-2 PN/DP online in STEP 7 (separate project). In CPU -> Information -> Communication, verify each connection shows state "established".
3. In the central project, place the FB34 instance DB into a VAT and force the REQ bit. The STATUS output should progress 7001 -> 7002 -> 0000 within one OB1 cycle if everything is wired correctly.
4. Monitor the partner CPU's Connection Diagnostics in NetPro online (right-click the connection -> Connection diagnostics). Look for the "Bytes sent / Bytes received" counters incrementing.
5. Use the partner CPU's "Monitor / Modify" tool to verify the data actually arrived at the partner DB. Read back the same bytes the central station wrote.
6. Force a deliberate partner CPU STOP via the mode selector. Confirm that the central FB returns STATUS = W#16#80F1 within a few seconds, then recovers to W#16#0000 when the partner is switched back to RUN.

Troubleshooting Matrix

Anti-Patterns - What Not To Do

• Do not call FB34/FB35 with REQ constantly = 1. This queues an unbounded number of jobs and overruns the connection's send buffer. Use a one-shot edge.
• Do not share a single FB instance across multiple connection IDs. Each ID requires its own instance DB so that the asynchronous status output is not overwritten by a newer job.
• Do not rely on NDR/DONE as an error indicator. These bits do not assert on failure - always evaluate ERROR and STATUS together.
• Do not push the LEAN CP past its 4 S7 connections. Use the full CP343-1 instead - it is cheaper than debugging intermittent W#16#80A4 errors in production.
• Do not leave the partner CPU's PUT/GET protection disabled in production without network segmentation. Any device on the segment can then read/write the partner's data.

Performance & Cycle-Time Considerations

A single GET over Industrial Ethernet with 10 bytes of payload takes 5-15 ms end-to-end on a healthy network. With 10 stations polled in a 1 s scan, OB1 priority class 1 should remain well below 100 ms. Watch the connection's send buffer depth: if it stays above 60% the link is congested, and you should reduce the polling rate or move the S7 traffic to a separate VLAN.

For deterministic 10 ms cycle times, switch from polling GET/PUT to the S7-300's BSEND/BRCV functions on the integrated PN interface - but BSEND/BRCV requires both partners to be configured in the same project, so for the "separate project" scenario PUT/GET is still the only practical choice.

Migration Notes - TIA Portal

If the central project is migrated to TIA Portal V15 or later, the S7-300 PUT/GET blocks become SFB14 (GET) and SFB15 (PUT) located in the "Communication" palette under "S7 Communication". The parameter interface is identical, but the TSAP entry changes format from dotted ASCII ("03.00") to a hexadecimal byte array. See the STEP 7 / TIA Portal communication manual for cross-reference. On S7-1500, replace SFB14/15 with the new "GET" / "PUT" instructions from the Communication palette; the behavior is the same but TSAP is configured per connection in the device properties.

FAQ

Reviewed against Siemens STEP 7 V5.5 SP4, CP343-1 LEAN firmware V3.0.7, CPU315-2 PN/DP firmware V3.3. Verify all values against the current Siemens product manuals before commissioning.