How to Configure Cross-Project Data Exchange Between Independent SIMATIC PCS 7 Automation Stations

Exchanging process data between two independent SIMATIC PCS 7 automation stations located in separate multi-projects where one station possesses a CP 443-1 and the other utilizes an onboard PROFINET interface requires creating an Unspecified S7 Connection in NetPro on each controller. Because the projects are decoupled, communication blocks BSEND (SFB12) and BRCV (SFB13) or USEND (SFB8) and URCV (SFB9) must be configured in CFC with matching connection IDs and R_ID parameters. Alternatively, Open User Communication (TSEND/TRCV) can be deployed over raw TCP/IP if hardware interfaces lack compatible S7 protocol configurations. Ensuring identical subnets, static IP assignments, and coordinated send triggers guarantees deterministic cross-station telemetry.

Independent Multi-Project Communication Architecture

In large process facilities, separate plant units (such as Utilities, Synthesis, and Tank Farm) are frequently managed in independent PCS 7 multi-projects by different engineering teams. When process interlocking or production transfer data must be passed between these decoupled controllers:

The Architectural Dilemma: Because the controllers do not exist in the same SIMATIC Manager multi-project, the automated AS-AS cross-communication wizard cannot automatically route signals or create fully specified S7 connections.
Interface Divergence: Station 1 may feature an S7-400 CPU communicating over an external CP 443-1 (6GK7443-1EX30-0XE0), while Station 2 utilizes an S7-400 PN/DP CPU (such as CPU 414-3 PN/DP or CPU 410-5H) using integrated PROFINET ports.
The Solution: An Unspecified S7 Connection defined on each controller in its respective NetPro configuration, bound to standard communication function blocks in CFC.

Configuring Bilateral Unspecified S7 Connections in NetPro

To enable bidirectional data flow, configure connection tables in both independent projects:

Station 1 (Initiator / Sender):
* Open NetPro in Station 1's project. Select the S7-400 CPU.
* Add a new connection: select Unspecified partner and S7 connection.
* Under General Properties, assign the local interface (CP 443-1) and specify the partner's IP address.
* Check Active connection establishment.
* Note the allocated local Connection ID (e.g., 16#0001 or W#16#1).
* Under Address Details, set the Remote TSAP to match Station 2's CPU Rack and Slot (e.g., Rack 0, Slot 3 -> 03).
Station 2 (Responder / Receiver):
* Open NetPro in Station 2's project. Select the S7-400 CPU.
* Add a new connection: select Unspecified partner and S7 connection.
* Assign local interface (CPU PN-IO) and specify Station 1's IP address.
* Leave Active connection establishment unchecked (passive listener).
* Note the allocated local Connection ID on Station 2 (which can differ from Station 1).
* Save and compile NetPro in both projects and download connection tables to both PLCs.

CFC Block Engineering: BSEND/BRCV vs USEND/URCV Configuration

Once the network connections are established, instantiate standard communication blocks in the CFC charts:

BSEND / BRCV (SFB12 / SFB13) - Reliable Block Data Transfer:
* Use Case: Critical process values, batch parameters, recipe transfer, and equipment interlocks requiring absolute delivery confirmation.
* Parameter Alignment:
- ID: The local NetPro connection ID (WORD/INT).
- R_ID: A unique 32-bit identifier (DWORD) that must be identical on both BSEND and BRCV (e.g., DW#16#00000001).
- SD_1: Pointer to the send data structure (ANY pointer to a Data Block).
- RD_1: Pointer to the receiving buffer Data Block.
- Handshake Logic: Drive REQ using an edge pulse (e.g., 1-second pulse). Monitor DONE, ERROR, and STATUS.
USEND / URCV (SFB8 / SFB9) - Uncoordinated Fast Transfer:
* Use Case: High-frequency analog telemetry where the partner CPU simply overwrites stale values and packet loss handshakes are unnecessary.
* Transmits up to 440 bytes per telegram without receipt acknowledgment.

Alternative Open User Communication (TSEND / TRCV)

If one of the controllers is a third-party PLC or a basic S7-1200/1500 controller that does not support S7 communication blocks, Open User Communication (OUC) provides a universal alternative:

Protocol: Native TCP/IP or ISO-on-TCP (RFC 1006).
Blocks: TSEND (FB63), TRCV (FB64), TCON (FB65), and TDISCON (FB66).
Configuration: Connection parameters are defined via a user data block of structure UDT 65 (TCON_PAR) rather than in NetPro.
Advantage: Fully vendor-agnostic and supported across all SIMATIC controllers and Ethernet devices.

Comparison of Cross-Station Communication Mechanisms

The table below outlines the core characteristics of cross-project communication methods in SIMATIC PCS 7.

Communication MechanismProtocol UsedDelivery HandshakeMaximum Data SizeConfiguration ToolRedundancy SupportBSEND / BRCVS7 ProtocolYes (Positive ACK)64 KB per blockNetPro (Unspecified)S7-REDCONNECTUSEND / URCVS7 ProtocolNo (Cyclic overwrite)440 BytesNetPro (Unspecified)Single connection onlyPUT / GETS7 ProtocolClient-side only160 to 400 BytesOne-sided in NetProNot recommended in PCS 7TSEND / TRCV (OUC)TCP / ISO-on-TCPYes (TCP ACK)8 KB / 64 KBUser DB (UDT 65)Dual IP software logicAS-AS Cross-CouplingPCS 7 NativeSystem-managedDynamic APL tagsCFC Wizard (Same project)Fully Fault-Tolerant

Verification

To confirm that cross-project data exchange operates reliably:
1. In NetPro on both engineering stations, verify that connection status reports Established under PLC > Diagnostics/Setting > Connection Status.
2. In the CFC editor on Station 1, place BSEND into Test Mode: observe that parameter DONE increments or pulses TRUE, while ERROR remains FALSE with STATUS = 16#0000.
3. In Station 2's CFC editor, monitor BRCV: confirm parameter NDR pulses TRUE and destination data block values dynamically match source values.
4. Introduce a deliberate communication interruption (e.g., unplug Ethernet patch cable): verify that BSEND.ERROR transitions to TRUE with status code 16#0001 (communication fault) and recovery occurs automatically within 3 seconds of reconnection.

Limitations and Operational Precautions

Unspecified S7 connections lack compiler-level cross-project symbol verification; if data types or byte structures inside the shared Data Blocks are altered, data will be misaligned without compiler warnings.
Do not leave BSEND.REQ permanently set to TRUE; it must be edge-triggered by a pulse timer or change-detection block to prevent saturating controller communication buffers.
Cross-project communication between separate facilities should always be routed through managed industrial switches with proper VLAN isolation and cybersecurity firewalls.
Always validate final hardware configurations, network switches, and software licensing against the applicable Siemens catalog and authorized distributor quotation.

Engineer FAQ

Can I use PUT and GET blocks instead of BSEND and BRCV?

While PUT and GET are simple because they require configuration on only one CPU, they bypass the partner CPU operating system and read/write raw memory asynchronously. In PCS 7, this can cause data inconsistency during cyclic OB execution; BSEND/BRCV is strongly recommended.

Why is BRCV status reporting 16#0011?

Status code 16#0011 indicates that data transmission is ongoing or that the target receive buffer length specified in RD_1 is smaller than the incoming data packet sent by BSEND.

What happens if both PLCs have 'Active connection establishment' checked?

Both controllers will attempt to initiate the TCP handshake simultaneously. While modern TCP stacks often resolve simultaneous open requests, it can lead to intermittent connection resets; always configure one side as active and the other as passive.