Configuring S7-300 to S7-400 BSEND BRCV Communication in Mixed TIA/STEP 7 Projects

Mixed-vintage SIMATIC fleets are routine in process plants: a new S7-400 CPU is added for a high-availability section, while existing S7-300 stations continue to run on STEP 7 V5.4 because the legacy project is not migrated to TIA Portal. Exchanging process data (often 2 KB or more per scan) between the two generations across Industrial Ethernet requires the BSEND / BRCV pair from the S7 Communication suite. This reference covers the full configuration path, the unspecified S7 connection required for cross-project links, and the well-documented PLCSIM behaviour that blocks FB12 on a simulated S7-300 station.

1. Overview of the Mixed-Environment Problem

S7 Communication provides three transport services that are common in automation networks: PUT/GET for short client-server reads, USEND/URCV for unacknowledged segments, and BSEND/BRCV for fully acknowledged streaming of large buffers. The third pair is implemented as a client-client protocol: both stations hold a configured connection entry, and either side may initiate a transfer. Because the connection is symmetric, both projects must reference the same connection ID and connection description.

When the S7-300 and S7-400 stations live in different STEP 7 projects (typical during migration or brownfield expansion), the connection cannot be created as a specified partner. The S7-400 must instead establish an unspecified S7 connection that references only the IP address, rack, slot, and TSAP of the remote CPU. The S7-300 side holds the matching entry configured as an S7 connection with a fully specified partner.

For ~2 KB payloads, BSEND/BRCV transfers the buffer in a single call rather than fragmenting it across multiple PUT/GET transactions. This eliminates CPU load spikes and simplifies error handling because a single DONE/RERROR handshake confirms the whole transfer.

2. Prerequisites

3. BSEND/BRCV Communication Fundamentals

The BSEND instruction ships data to a remote partner instruction of type BRCV. Unlike PUT/GET, which transfer up to 160 user-data bytes per call, BSEND/BRCV can stream up to 65,534 bytes in a single call. The transfer is acknowledged end-to-end: the sender sets DONE=1 only after the receiver confirms the complete payload has been written into the receive area.

3.1 Block Identification Across Environments

The block name changes between STEP 7 V5.x and TIA Portal. The functionality is identical.

3.2 Interface Definition

4. Network Architecture

The mixed fleet connects to a single Industrial Ethernet subnet. The diagram below shows the canonical topology used in brownfield S7-300/S7-400 migrations.

Each S7-300 station sends a dedicated payload (e.g. recipe parameters, diagnostic buffers, alarm history) to the S7-400. A separate logical BSEND/BRCV pair is required per data channel, but all pairs can share a single physical S7 connection by using unique R_ID values per pair.

5. Configuring the Unspecified S7 Connection on the S7-400 Side

When the S7-400 project does not contain the S7-300 station as a partner, the TIA Portal offers only an unspecified S7 connection. This connection requires explicit identification of the partner:

1. In the TIA Portal project tree, expand Devices & Networks, then select the S7-400 CPU.
2. Open Properties → Communication → S7 connections.
3. Add a new connection. The partner type is offered as "Unspecified" because no S7-300 CPU is in the project.
4. Configure the partner address:
   • Interface: PROFINET / Industrial Ethernet
   • IP address: 192.168.0.21 (S7-300 #1)
   • Connection resource / TSAP (rack, slot): Rack 0, Slot 2. The TSAP for S7-300 PN CPUs is constructed as 01.0r.ss where r is the rack number (hex) and ss is the slot number (hex). For rack 0 / slot 2 the local TSAP is 01.00.02.
5. Set the Connection ID to 1. This value must be passed to the ID input of the BRCV FB call.
6. Set the Active connection establishment flag on the S7-400 side (S7-400 initiates the connection; S7-300 side is passive).

For each additional S7-300 station, repeat the procedure with a unique Connection ID (2, 3, 4, ...). The S7-400 reserves a connection resource for each entry.

6. Configuring the S7 Connection on the S7-300 Side (STEP 7 V5.4)

1. Open the STEP 7 V5.4 project that contains the S7-300 station.
2. Launch NetPro (Options → Configure Network).
3. Select the S7-300 CPU and insert a new S7 connection.
4. Choose S7 connection as the connection type, and select the S7-400 partner from the partner list (the S7-400 must be added as a "Other Station" or "S7-400 Station" with its IP address).
5. Confirm the Connection ID matches the value used on the S7-400 side (in this case 1).
6. Configure the local TSAP: 01.00.02 for rack 0 / slot 2.
7. Set the partner IP address to 192.168.0.10 and the partner TSAP to 01.00.03 (S7-400 rack 0 / slot 3).
8. Leave the connection as passive (the S7-400 is the active end).

Compile and download the NetPro changes. Verify the connection appears as "established" in the CPU's online connection diagnostics.

7. Programming the S7-400 BRCV in TIA Portal

The S7-400 receives data using FB13 (BRCV). The instance DB and connection ID come from the connection configuration described in §5.

// OB1 cyclic main (TIA Portal, S7-400)
// Each cycle: trigger BSEND on the S7-300, then call BRCV on the S7-400

// --- Receive block on S7-400 (BRCV) ---
"BRCV_DB".EN_R  := TRUE;                       // permanently enable reception
"BRCV_DB".ID    := W#16#1;                     // connection ID = 1 (from connection config)
"BRCV_DB".R_ID  := DW#16#1000_0001;            // application-level ID, must match sender
"BRCV_DB".RD_i  := P#DB100.DBX0.0 BYTE 2048;  // receive buffer (2 KB), aligned

CALL FB13 "BRCV" , "BRCV_DB";

IF "BRCV_DB".NDR THEN
    // new data accepted, copy from DB100 to process area
    // (example: copy into DB200 for OPC UA / HMI use)
END_IF;

IF "BRCV_DB".ERROR THEN
    // capture STATUS, log to diagnostic buffer, raise alarm
    // STATUS format: 8xFx = error class, see §11
END_IF;

8. Programming the S7-300 BSEND in STEP 7 V5.4

On the S7-300 sender, drop SFB12 (BSEND) from the Standard Library → System Function Blocks folder. STEP 7 V5.4 auto-generates an instance DB; rename it to DB12.

// OB35 (cyclic interrupt, 100 ms) on S7-300 (STEP 7 V5.4)
// Calls SFB12 BSEND to send 2048 bytes from DB50 to the S7-400 receiver

// Pulse REQ every cycle to keep the transfer primed
// (BSEND is acknowledged; once DONE it waits for the next REQ edge)

CALL SFB12 , DB12 (
    REQ   := M10.0,           // rising edge to start each transfer
    R     := FALSE,
    ID    := W#16#1,          // connection ID 1 (matches NetPro)
    R_ID  := DW#16#1000_0001, // same application ID as receiver
    SD_1  := P#DB50.DBX0.0 BYTE 2048,
    LEN   := 2048,
    DONE  := M10.1,
    ERROR := M10.2,
    STATUS:= MW12
);

For periodic transfer, drive REQ from a timer or process event. To avoid re-triggering on every cycle (which would re-send continuously after DONE), use a one-shot pattern such as a positive-edge evaluation of a 1-Hz clock or a process condition (e.g. data-ready flag from the application).

9. PLCSIM Simulation: Why BSEND Fails Between S7-400 and S7-300

A widely reported behaviour in mixed-fleet simulation is that BSEND/BRCV functions correctly between two S7-400 PLCSIM instances but fails when one end is an S7-300 PLCSIM. The root cause is the block type loaded into the simulated CPU.

9.1 Root Cause

• PLCSIM instances a CPU image, not the full firmware. For S7-300 PLCSIM, the simulated environment expects the SFB variant of the communication block (SFB12 / SFB13), because that is what is stored in the S7-300 CPU operating system.
• If the S7-300 station was programmed in TIA Portal and downloaded as FB12 / FB13, PLCSIM may either fail to instantiate the block correctly or load it but produce inconsistent connection-state behaviour with the partner PLCSIM. The result is a connection error (typically STATUS 0x8081 or 0x8183) on the S7-400 side and a corresponding error on the S7-300 side.

9.2 Resolution

Use the following block-type selection rule when simulating with PLCSIM:

The engineering implication is that a single TIA Portal project with FB12 on the S7-300 cannot be downloaded to PLCSIM for end-to-end testing without source modifications. The recommended workflow is:

1. Maintain the production project with FB12/FB13 in TIA Portal.
2. For PLCSIM validation, open the S7-300 station in STEP 7 V5.4 separately, replace the FBs with SFB12/SFB13, and run the simulation from a parallel V5.4 project that mirrors the production connection configuration.
3. Once PLCSIM validation passes, load the production TIA Portal project to the real hardware for factory acceptance testing.

10. Block Selection Decision Flowchart

11. Data Size Limits and Buffer Sizing for 2 KB Payloads

BSEND/BRCV accepts up to 65,534 bytes per call. For the 2 KB (~2048 byte) payload described in the source scenario, the limits are well within bounds, but buffer setup must respect these constraints:

• The receive DB must be at least as large as LEN. Under-sizing causes STATUS 0x8085 on the receiver.
• The send DB area must be byte-aligned. Mixing BOOL, INT, and REAL tags into the same buffer requires careful offset planning because BSEND treats the area as a flat byte stream.
• For data integrity, place the receive DB in the work memory (DB number < 256 on S7-300 if using non-optimised access) to guarantee contiguous storage without paging delays.

12. Status and Error Code Reference

The STATUS output of BSEND/BRCV returns a 16-bit value combining a class byte and a detail byte. The most common codes observed during mixed S7-300/S7-400 commissioning are:

13. Verification Procedure

Use the following checklist after commissioning:

1. Online connection status: On the S7-400, open "Online & Diagnostics → Connection table" and confirm the connection is "Established." Repeat on the S7-300 in NetPro / "Accessible Nodes."
2. First transfer test: Force a BSEND call from the S7-300 with a known pattern (e.g. fill DB50 with incrementing bytes 0x00, 0x01, 0x02, ...). On the S7-400, monitor the receive DB in a watch table and verify the pattern arrives.
3. STATUS monitoring: Add STATUS, DONE, ERROR to a watch table on both stations. Confirm STATUS = W#16#0000 or transient values 0x7000 / 0x7001 / 0x7002 during normal operation.
4. Stop/Run resilience: Place the S7-300 in STOP for 5 seconds, then return to RUN. Verify the connection re-establishes automatically (S7 communication auto-reconnects on partner return-to-RUN).
5. Diagnostic buffer: Read the S7-400 diagnostic buffer ("Online & Diagnostics → Diagnostic buffer") and confirm no permanent S7 communication errors.
6. Cycle timing: Measure the OB1 / OB35 scan time before and after the BSEND call to ensure the transfer does not exceed the configured cycle time. Typical 2 KB transfers add 30–60 ms per call on a CPU 315-2 PN/DP.

14. Troubleshooting Matrix

15. Field-Proven Engineering Notes

• R_ID uniqueness: Each BSEND/BRCV pair uses a unique 32-bit R_ID. Multiple pairs can share the same physical S7 connection as long as R_IDs are distinct. Keep a project-level R_ID registry to avoid collisions during later expansions.
• Network redundancy: For S7-400H redundant systems, configure two separate S7 connections (one per subnet). Use different R_IDs per subnet to avoid the active connection shadowing the standby.
• Firewall / NAT traversal: S7 communication uses TSAP-based addressing and does not traverse IP-NAT cleanly. Place both CPUs on the same Layer-2 subnet, or use SCALANCE security modules with explicit S7-connection rules.
• STEP 7 V5.4 + TIA Portal coexistence: STEP 7 V5.4 and TIA Portal projects can coexist on the same engineering workstation but cannot be open simultaneously against the same CPU. Close one before connecting to the other for online operations.
• Firmware consistency: For mixed firmware levels (e.g. S7-400 V5.x with S7-300 V3.x), BSEND/BRCV is supported but STATUS 0x80D0 may appear if block version exceeds CPU firmware version. Use the block version compatible with the older CPU.
• Memory layout: On S7-300 CPUs with limited work memory (e.g. CPU 312), declare receive DBs above DB 200 (data area) rather than below to avoid overlap with the instance DBs of integrated blocks.

16. References for Further Verification

• Siemens Support: S7 Communication between SIMATIC S7-1500 and SIMATIC S7-300 (PDF) — covers the same client-client principle applied to S7-1500 ↔ S7-300, useful for confirming TSAP and connection configuration patterns.
• Siemens TIA Portal Help: BSEND - Send data in segments (S7-300, S7-400) — official instruction reference for FB12 interface, error codes, and programming example.

Frequently Asked Questions