Troubleshooting S7-400 to S7-300 PROFIBUS FB8 FB9 Communication

Problem Overview: Replacing S7-400 with S7-300 in an Existing PROFIBUS S7 Communication Network

When two of three CPU 416-2 PC controllers fail in a PROFIBUS-based S7 communication network, replacing them with CPU 319-3 PN/DP introduces compatibility constraints that prevent the surviving S7-400 from exchanging data with the new S7-300 stations. The original network used SFB8 and SFB9 (USEND/URECV) for client/server data exchange. Because S7-300 CPUs do not provide SFB blocks (SFBs are embedded in the S7-400 firmware only and cannot be loaded as user code on an S7-300), the blocks must be replaced with the user-side equivalents FB8 and FB9. After this substitution, the CPU 416-2 still does not see the S7-300 partners because the S7 connection itself was never re-engineered for the asymmetric client/server roles.

This guide documents the engineering changes required to restore S7 communication between an S7-400 (CPU 416-2 PC) acting as a client and CPU 319-3 PN/DP stations acting as partners, all running over the integrated PROFIBUS DP interface. It also addresses the 160-byte payload ceiling of FB8/FB9 on S7-300, the role of NetPro for S7 connection configuration, and a swap-in replacement strategy using GET/PUT or BSEND/BRCV.

Network Architecture and Compatibility Constraints

S7 communication (USEND/URECV, BSEND/BRCV, GET/PUT) operates as a connection-based, client/server protocol that can ride on top of MPI, PROFIBUS, or PROFINET. The transport medium is selected by the integrated interface being used; S7 communication does not change semantics across media. Per the Siemens manual "SIMATIC S7-300 CPU 31xC and CPU 31x: Technical specifications" (entry ID 12996906), the CPU 319-3 PN/DP supports S7 communication as either a client or a server with or without an external CP on its integrated PROFIBUS DP interface (firmware V3.x).

Critical architectural points:

• An S7-400 CPU 416-2 PC can act as both client and server natively.
• An S7-300 CPU 319-3 PN/DP can act as both client and server on its integrated DP interface starting with firmware V3.x.
• The protocol must be the same on both ends: an S7 connection (not TCP, UDP, or ISO-on-TCP).
• The transport medium must be consistent: PROFIBUS DP / MPI for the integrated DP port; PROFINET for the integrated PN port.
• Connection IDs (LOCAL_ID), partner PROFIBUS addresses, R_IDs, and TSAPs must match on both sides.
• The CPU 319-3 PN/DP (6ES7318-3EL01-0AB0) supports up to 16 S7 connections for PG/OP/S7 communication combined; the CPU 416-2 supports up to 64.

Reference Topology

The replacement network keeps the existing PROFIBUS DP cable and connectors; only the CPUs on stations 2 and 3 are physically swapped. The CPU 416-2 retains its PROFIBUS address (typically 1), and the CPU 319-3 PN/DP stations are assigned addresses 2 and 3.

Hardware and Firmware Prerequisites

Confirm the following before re-engineering the application:

Firmware and software requirements:

• STEP 7 V5.5 SP4 or higher with the Hardware Support Package (HSP) for the CPU 319-3 PN/DP and the CPU 416-2 PC.
• CPU 319-3 PN/DP firmware V3.3 or higher is required for full S7 communication as an active client on the integrated DP interface. Firmware V2.x supports only the passive (server) role on the integrated DP.
• The FB8 and FB9 function blocks must be present in the standard library (Communication Blocks) and compiled into the S7-300 user program along with their instance DBs.

PROFIBUS configuration values:

• Baud rate: 1.5 Mbps is a robust default for S7 communication; 12 Mbps is supported but requires higher-quality cabling.
• Bus profile: DP (master-slave) for the 319-3 PN/DP integrated DP port.
• Maximum station count per segment: 32; maximum with repeaters: 126.
• Address 1 for the CPU 416-2 PC, address 2 for the first CPU 319-3, address 3 for the second CPU 319-3.

SFB to FB Block Migration for S7-300

The first technical change is replacing the S7-400 system function blocks with the equivalent function blocks that live in the S7-300 user program. The block numbers stay the same (8/9), but the storage location and the requirement for an instance DB change.

Migration procedure on the S7-300 stations:

1. Open the S7-300 project in STEP 7 V5.5.
2. Open the standard library > Communication Blocks and copy FB8 and FB9 into the project Blocks folder.
3. Replace every SFB8 call in the user program with FB8 and assign a unique instance DB (for example DB100).
4. Replace every SFB9 call with FB9 and assign a unique instance DB (for example DB101).
5. Update the call syntax. FBs always require an instance DB; SFBs do not. Re-compile the program and download it to the CPU.
6. Ensure the CPU 416-2 PC also has its program updated to call the partner DB by the correct PROFIBUS address.

Configuring the S7 Connection in NetPro

NetPro is the configuration tool inside STEP 7 V5.5 used to define S7 connections between CPUs. Without a properly configured and downloaded S7 connection, the FB8/FB9 calls return immediately with STATUS <> 0 and no data is exchanged. The CPU 319-3 PN/DP (firmware V3.x) is fully capable of participating in S7 connections on the integrated DP interface as either active or passive partner, so an external CP 342-5 is not required for this application.

Step-by-step NetPro configuration

1. Open the project in SIMATIC Manager and double-click NetPro in the project tree.
2. Select the CPU 416-2 PC station. Right-click on the PROFIBUS subnet and choose Insert New Connection.
3. Choose connection type S7 Connection.
4. In the connection properties, set the Local end to the CPU 416-2 PC and tick Establish an active connection. This makes the CPU 416-2 the client.
5. Set the Partner end to the CPU 319-3 PN/DP at PROFIBUS address 2. Leave the partner connection establishment set to Passive.
6. Define the Local ID as a unique hex value such as W#16#0001. This is the value used in FB8/FB9 calls.
7. Define the TSAPs on both ends; on the S7-300, the default TSAP for S7 connections over PROFIBUS is computed from the PROFIBUS address and the slot.
8. Compile the NetPro configuration (Network > Compile and Check All) and download only the connection configuration (PLC > Download Connection Configuration) to the CPU 416-2.
9. Repeat steps 2-8 for the second CPU 319-3 PN/DP, incrementing the LOCAL_ID to W#16#0002 and pointing to PROFIBUS address 3.
10. From each CPU 319-3 station, download its project (including the connection configuration) so that the passive side accepts the incoming connection from the client.

NetPro connection parameters

FB8 and FB9 Programming Interface

FB8 (USEND) and FB9 (URCV) are the S7-300 counterparts to SFB8 and SFB9. Their interface is identical apart from the storage location and the need for an instance DB.

FB8 USEND interface

FB9 URCV mirrors this interface: REQ must remain TRUE to accept incoming data; NDR (new data received), ERROR, STATUS, and LEN are the outputs.

The R_ID parameter is critical and frequently misconfigured. The same R_ID value must be loaded on both ends. If the CPU 416-2 sends with R_ID = DW#16#0000_0100, the receiving CPU 319-3 must also call URCV with R_ID = DW#16#0000_0100. Different R_IDs on sender and receiver yield STATUS = W#16#0003 on the receive side and no data is delivered.

Sample ST code for USEND on the CPU 416-2 (client)

// Instance DB for FB8 on the CPU 416-2
DATA_BLOCK DB100
  FB8
END_DATA_BLOCK

// Triggered from OB1 on a 100 ms cyclic tick
CALL FB100, DB100
  REQ := M10.0          // Trigger send (rising edge)
  ID := W#16#1          // Connection ID from NetPro to CPU 319-3 #1
  R_ID := DW#16#100     // R_ID must match URCV partner
  SD_1 := P#DB200.DBX0.0 BYTE 20   // 20 bytes from DB200
  SD_2 := P#DB201.DBX0.0 BYTE 20   // up to 160 bytes total across SD_1..SD_4
  LEN := 20             // Bytes to send in this call
  DONE := M10.1
  ERROR := M10.2
  STATUS := MW12;

Sample ST code for URCV on the CPU 319-3 (server)

// Instance DB for FB9 on the CPU 319-3 #1
DATA_BLOCK DB101
  FB9
END_DATA_BLOCK

// Cyclic call; REQ must remain TRUE for URCV to accept
CALL FB101, DB101
  REQ := TRUE           // Continuous receive enable
  ID := W#16#1          // Same connection ID as client
  R_ID := DW#16#100     // Same R_ID as client
  RD_1 := P#DB300.DBX0.0 BYTE 20   // Receive buffer
  RD_2 := P#DB301.DBX0.0 BYTE 20
  NDR := M20.1
  ERROR := M20.2
  STATUS := MW22;

160-Byte Payload Limit and Multi-Block Strategies

The CPU 319-3 PN/DP, like every S7-300, limits each FB8/FB9 call to 160 bytes of payload. If the original SFB8/SFB9 calls between the three S7-400 CPUs exchanged more than 160 bytes per call, the calls must be split into multiple FB8/FB9 invocations. The 160-byte ceiling is a CPU-specific limit tied to the S7-300 communication resources; it is not a protocol-level MTU.

Strategies to exceed 160 bytes

1. Use SD_1..SD_4 within a single FB8 call. Each ANY pointer can reference a different memory area; the sum across all SD_ pointers in one call must still not exceed 160 bytes.
2. Multiple FB8 calls with different R_IDs. Program FB8 multiple times, each with a unique R_ID and its own 160-byte payload. Both stations must use the same R_ID per call to keep pairs aligned.
3. Switch to BSEND/BRCV (FB12/FB13) for block-oriented transfer. BSEND supports up to 32 KB per call and handles segmentation internally. The R_ID and connection ID still need to match, but the per-call payload limit is much larger.
4. Switch to GET/PUT (FB14/FB15) for read/write semantics. 160 bytes per call still applies, but multiple FB14/FB15 instances can be called to read different ranges.

For deterministic recipes, parameter sets, or large data block transfers, BSEND/BRCV is the recommended replacement; it preserves the SFB12/SFB13 paradigm of the original S7-400 program and avoids the per-call byte-count juggling of FB8/FB9.

Verifying the Communication

Once NetPro is downloaded and the FB8/FB9 calls are running on all three stations, verify the exchange using a combination of online diagnostics and a STEP 7 watch table.

1. Open NetPro, right-click on the S7 connection from the CPU 416-2 to each CPU 319-3, and choose Connection Status. The status must read Established.
2. In STEP 7, open PLC > Diagnostics/Settings > Diagnostic Buffer on each CPU. Look for event IDs that indicate connection state changes: 0x4301 = connection established, 0x4302 = connection aborted, 0x4303 = connection attempt failed.
3. Insert a watch table and monitor the FB8/FB9 output bits. DONE = TRUE on USEND confirms a completed send. NDR = TRUE on URCV confirms new data arrived. ERROR = TRUE always means STATUS must be read.
4. Use the watch table to compare the send DB on the client (for example DB200) to the receive DB on the server (for example DB300). They must match after each NDR pulse.
5. Run PLC > Diagnostics/Settings > PROFIBUS Diagnostics on the CPU 416-2 to verify that PROFIBUS addresses 2 and 3 are visible and that no bus faults (Fdl, Fmae, slave diagnostics) are present.
6. Force a CPU STOP on one of the CPU 319-3 stations and observe whether the connection state moves to Aborted in NetPro within a few seconds. This confirms the diagnostic path is wired correctly.

Common STATUS codes for FB8/FB9

Alternative Communication: GET/PUT and BSEND/BRCV

If USEND/URECV remains problematic after the NetPro reconfiguration, two robust alternatives are available within the same S7 connection framework.

GET/PUT (FB14/FB15)

GET and PUT replace the bidirectional push model of USEND/URECV with a unidirectional pull/push model. The CPU 416-2 reads from a partner DB on the CPU 319-3 (GET) or writes to a partner DB on the CPU 319-3 (PUT). The partner CPU remains in passive server role. The 160-byte per-call ceiling still applies, but multiple FB14/FB15 instances can each address a different DB range.

// PUT on CPU 416-2: write 20 bytes to DB200 on CPU 319-3 #1
CALL FB14, DB14
  REQ := M30.0
  ID := W#16#1
  ADDR_1 := P#DB200.DBX0.0 BYTE 20   // Target area on remote CPU
  SD_1 := P#DB100.DBX0.0 BYTE 20     // Source area on local CPU
  DONE := M30.1
  ERROR := M30.2
  STATUS := MW32;

// GET on CPU 416-2: read 20 bytes from DB300 on CPU 319-3 #1
CALL FB15, DB15
  REQ := M30.3
  ID := W#16#2
  ADDR_1 := P#DB300.DBX0.0 BYTE 20   // Source area on remote CPU
  RD_1 := P#DB100.DBX100.0 BYTE 20   // Target area on local CPU
  NDR := M30.4
  ERROR := M30.5
  STATUS := MW34;

The advantage of GET/PUT over USEND/URECV is the elimination of R_ID matching. The connection ID alone is sufficient because the FB looks up the connection internally.

BSEND/BRCV (FB12/FB13)

BSEND and BRCV are block-oriented transfers with a maximum payload of 32 KB per call. They replace the SFB12/SFB13 paradigm directly and are the recommended upgrade path if the original S7-400 program used BSEND/BRCV rather than USEND/URECV. R_ID matching still applies, but the payload limit is lifted significantly.

// BSEND on CPU 416-2: send 4 KB to CPU 319-3 #1
DATA_BLOCK DB200
  FB12
END_DATA_BLOCK

CALL FB200, DB200
  REQ := M40.0
  ID := W#16#1
  R_ID := DW#16#A000
  SD_1 := P#DB500.DBX0.0 BYTE 4096
  LEN := 4096
  DONE := M40.1
  ERROR := M40.2
  STATUS := MW42;

Troubleshooting Matrix

Migration Checklist

1. Verify CPU 319-3 PN/DP firmware is V3.3 or higher.
2. Open NetPro and create one S7 connection per CPU 319-3 with the CPU 416-2 as Active.
3. Assign a unique LOCAL_ID (W#16#1, W#16#2, ...) per partner.
4. Compile and download the connection configuration to all three CPUs.
5. On the CPU 416-2, replace any SFB8/9 calls that pointed to the old partners with USEND calls addressed to the new partner addresses.
6. On each CPU 319-3, replace any SFB calls with FB8/FB9 and create instance DBs.
7. Verify R_ID parity between USEND and URCV pairs.
8. If payload exceeds 160 bytes per call, switch to BSEND/BRCV or program multiple FB calls.
9. Download all programs and watch tables; run for at least one full cycle in test mode.
10. Check NetPro Connection Status and the diagnostic buffer for ID 0x4301 (connection established).

FAQ