S7-300 FDL: Resolving 'No Receive Resource on Destination Station' Error

When commissioning an FDL (Fieldbus Data Link) connection between two S7-300 stations equipped with CP 342-5 PROFIBUS communication processors, engineers frequently encounter a confusing diagnostic condition: data exchange is functioning correctly—values written by the sender are visible in the receiver—yet the NetPro connection status on the sending PLC persistently reports "No Receive Resource on Destination Station". The receiving PLC shows the connection as OK. This article provides a complete troubleshooting path, root cause analysis, and verified fix for this asymmetric NetPro diagnostic state.

1. Problem Description and Symptoms

The observed behavior in a typical two-station FDL network is:

• Two S7-300 CPUs each equipped with a CP 342-5 PROFIBUS module.
• An FDL connection is configured in SIMATIC Manager's NetPro for both stations, downloaded to each CPU.
• FC5 AG_SEND is called cyclically in PLC "A"; FC6 AG_RECV is called cyclically in PLC "B".
• Process data successfully arrives in PLC "B"—inputs update and outputs respond as expected.
• NetPro on PLC "A" shows the connection status: "No Receive Resource on Destination Station".
• NetPro on PLC "B" shows the same connection: OK.

The asymmetry is the key diagnostic clue. If the connection were truly broken, the data would not arrive. If the receiving PLC had no resource at all, the sender would observe repeated FDL acknowledgments with negative responses, and process data would be lost. The fact that data is received and the destination station itself reports the connection as healthy indicates the condition is transient and resource-related rather than a configuration or wiring fault.

2. Affected Hardware and Software

FDL operates at Layer 2 of the PROFIBUS reference model. It is suitable for transmission of contiguous data blocks between two or more PROFIBUS stations, independent of any DP master cycle. Refer to the official Siemens documentation on FDL connections for S7-300/S7-400 for the complete architectural overview.

3. Root Cause Analysis

The CP 342-5 has a finite pool of internal job resources (send and receive buffers) for FDL services. Each AG_SEND or AG_RECV call that is active in the CPU occupies a resource on the CP until the job completes (DONE, ERROR, or NDR). When a sender triggers a new FDL job before the previous one has been acknowledged or the receiver has consumed its buffered frame, the destination CP can momentarily have no free receive buffer to accept the new telegram.

The NetPro status "No Receive Resource on Destination Station" is generated when the destination station's CP returns a Layer 2 negative acknowledgment (NAK) with the high-layer error code indicating a depleted receive queue. PROFIBUS implements this as the FDL status NR (No Receive Resource). The NAK is transient—the destination station recovers immediately on the next cycle—but the NetPro online diagnostic latches the most recent failure description until the next successful job.

The dominant engineering root cause is calling AG_SEND with a fixed ACT = TRUE input in OB1. The sender triggers a new job every PLC cycle (typically 10–100 ms). The receiving CP's Layer 2 task can only accept and queue a limited number of FDL frames per scan; when the sender's cycle outpaces the receiver, transient NAKs occur even though no data is lost.

Secondary root causes (verify and rule out):

• FDL service mismatch: sender configured for SRD, receiver for SDA, producing protocol-level NAKs.
• Connection ID ID on the FB differs from the NetPro connection ID.
• Logical base address LADDR on the FB does not match the CP slot address in HW Config.
• Mismatched LEN parameter causing frame length NAKs (default 240 bytes maximum for SDA/SRD).
• Receiver's AG_RECV not called in OB1, or called with mismatched RECV ANY pointer.

4. Diagnostic Procedure

Follow this sequence to confirm the diagnosis and rule out other faults:

1. Open NetPro on PLC "A". Right-click the FDL connection and select Connection Status. Note the diagnostic text and the timestamp of the last status change.
2. Open NetPro on PLC "B". Confirm the same connection shows OK. This asymmetry confirms the issue is sender-side or destination CP resource state, not a wire/connector fault.
3. Verify process data integrity. Trigger a known value change in PLC "A", monitor the corresponding DBW in PLC "B" online. If the value updates, Layer 2 transport is functional.
4. Inspect the sender's OB1. Confirm whether ACT on AG_SEND is driven by a constant TRUE, a flag, or a handshake. If constant TRUE, the cause is confirmed.
5. Read the CP diagnostic buffer. In HW Config, open CP 342-5 properties → Diagnostic Buffer online. Look for FDL job entries with status code 0A0F (NAK no resource) and the associated timestamp pattern—if occurrences correlate with the OB1 cycle time, the contention is confirmed.
6. Check STATUS output of AG_SEND. Add a temporary cross-reference or VAT view to monitor FC5.STATUS during runtime. A flicker of 8185h or 0A0Fh confirms a transient Layer 2 NAK.

5. Solution: Implementing Handshake-Based Job Control

The fix is to gate the ACT input of AG_SEND with the rising edge of the previous job's completion, and to prevent retriggering while a job is active. The pattern is:

1. Detect rising edge of DONE or ERROR from the previous AG_SEND call.
2. Only set ACT = TRUE for one OB1 cycle after the previous job terminated.
3. Check STATUS on ERROR to log or escalate persistent resource issues.

This converts the sender from a free-running producer into a deterministic producer, paced by the actual response time of the destination CP. Throughput drops slightly (from "as fast as possible" to "one telegram per receiver response"), but the destination CP's receive queue never overruns, and the NetPro status remains OK on both stations.

5.1 ST (Structured Text) Implementation

FUNCTION_BLOCK FB_FDL_Sender
VAR
    sDONE     : BOOL;   // edge memory for DONE
    sERROR    : BOOL;   // edge memory for ERROR
    sEdgeDone : BOOL;   // previous cycle sDONE
    sTxTrig   : BOOL;   // one-shot trigger for AG_SEND
END_VAR

VAR_TEMP
    wStatus   : WORD;   // last STATUS from AG_SEND
END_VAR

BEGIN
    // Rising-edge detection on DONE and ERROR
    sDONE  := AG_SEND.DONE;
    sERROR := AG_SEND.ERROR;

    IF (sDONE OR sERROR) AND NOT sEdgeDone THEN
        // Previous job terminated this cycle: allow one new send
        sTxTrig := TRUE;
    END_IF;
    sEdgeDone := sDONE OR sERROR;

    // Fire AG_SEND for exactly one OB1 cycle when triggered
    AG_SEND.ID    := 1;            // Connection ID from NetPro
    AG_SEND.LADDR := W#16#100;     // Logical base address of CP 342-5
    AG_SEND.SEND  := P#DB10.DBX0.0 BYTE 32;
    AG_SEND.LEN   := 32;
    AG_SEND.ACT   := sTxTrig;
    AG_SEND.DONE  := FALSE;        // will be set by CP after completion
    AG_SEND.ERROR := FALSE;
    AG_SEND.STATUS:= 0;

    // Clear trigger after one cycle
    sTxTrig := FALSE;

    // Latch latest status for diagnostics
    IF AG_SEND.ERROR THEN
        wStatus := AG_SEND.STATUS;
    END_IF;
END_FUNCTION_BLOCK

5.2 Ladder (LAD) Implementation

The equivalent logic in ladder form is a single network that detects the rising edge of DONE from the previous call and sets a one-cycle trigger bit M 10.0 (TxTrigger) that drives ACT on FC5 AG_SEND. The second network calls AG_SEND with the CP's logical base address (e.g., 256 dec / 100 hex) and the same connection ID 1 used in NetPro.

Network 1:  Edge detect on DONE / ERROR
--[DONE]--+--[ NOT sEdgeDone ]--( S )-- M 10.0    // TxTrigger
--[ERROR]-+                                   (reset at end of OB1)

Network 2:  Fire AG_SEND for one cycle
--[M 10.0]--[NOT AG_SEND.ACT]-- AG_SEND
ID    := 1
LADDR := W#16#100
SEND  := P#DB10.DBX0.0 BYTE 32
LEN   := 32
ACT   := M 10.0

6. Receiver-Side Verification

On PLC "B", the AG_RECV call should also follow best practice: only call it once per OB1, and use NDR to latch the LEN for the most recent received telegram. The receiver never triggers a new job—it only consumes incoming frames—so it cannot create resource contention. Confirm:

• ID matches the NetPro connection ID on the receiving station.
• LADDR matches the receiving CP's logical base address.
• RECV ANY pointer covers a data area at least as large as the sender's LEN.

7. Verification and Testing

After implementing the handshake-based trigger:

1. Download both PLCs (program + NetPro connection data).
2. Restart both CPUs in Cold Restart to clear CP buffers.
3. Open NetPro on PLC "A", right-click the connection, and select Connection Status. The status should read OK within 2–3 seconds.
4. Run the system for 30 minutes under normal load. Open CPU Messages on PLC "A" and confirm no FDL NAK entries appear in the diagnostic buffer.
5. Force a process value change in PLC "A" and verify it appears in PLC "B" within the configured cycle time. Latency should be deterministic (one OB1 cycle + CP processing, typically 20–50 ms).
6. Stress test: cycle the sender's trigger at the maximum OB1 rate. Even under this artificial load, the destination CP's queue should not overflow, and the NetPro status should remain OK.

8. Advanced Configuration Considerations

8.1 NetPro Connection Attributes

In the NetPro connection properties, the FDL service type and the maximum telegram length directly affect the resource load on both CPs. SRD (Send and Request Data with acknowledge) is the default and is sufficient for unidirectional or simple request/response exchanges. SDN (Send Data with No Acknowledge) reduces load on the destination but does not guarantee delivery—use only for non-critical broadcasts. SDA (Send Data with Acknowledge) is the classic unidirectional FDL service.

For the symptoms described in this article, leave the service as SRD or SDA and apply the handshake trigger; switching to SDN is not a substitute for proper send pacing.

8.2 CP 342-5 Resource Limits

The CP 342-5 firmware limits the number of simultaneous FDL jobs per CP. Typical values for the production firmware revisions:

For most two-station FDL setups these limits are not approached. They become relevant only in large S7-300 networks where one CP terminates FDL connections to many partners and aggregate traffic overwhelms the receive queue.

8.3 OB1 Cycle Time Impact

The OB1 cycle time of the sender is the upper bound on FDL job rate. If OB1 runs at 100 ms and the destination CP can complete a receive within 20 ms, the receiver is idle 80 ms per cycle—plenty of headroom. If the sender is set to cycle at 5 ms, the destination CP's queue fills and NAKs begin. Throttling at the application layer (the handshake described in Section 5) is more reliable than relying on the CP's internal pacing logic.

9. Migration Paths and Modern Alternatives

FDL is a Layer 2 PROFIBUS service and is rarely used in new projects. For new S7-300/400 deployments, evaluate these alternatives before retaining FDL:

• PROFIBUS DP with master-master cross-traffic. If both stations are DP masters, configure direct data exchange (DP-DX) without FDL.
• ISO-on-TCP / TCP via CP 343-1 Lean / CP 343-1. Use the same FC5/FC6 pattern (AG_SEND/AG_RECV) over Industrial Ethernet. The diagnostic codes differ but the handshake principle is identical.
• S7 Communication (PUT/GET). Available in STEP 7 V5.x with FB14/FB15 (PUT) and FB13 (GET). Requires no FDL connection but uses S7 connections over PROFIBUS or Ethernet.
• Migration to S7-1500 / ET 200SP. In TIA Portal, FDL is supported only with restrictions; the S7-1500 communication library uses different FBs (PUT/GET, BSEND/BRECV). Plan FDL retirement as part of any S7-1500 migration roadmap.

10. Best Practices for S7-300 FDL Communication

1. Always trigger AG_SEND on the rising edge of the previous DONE or ERROR, never with a constant TRUE.
2. Call AG_RECV once per OB1, never in fast interrupt OB (e.g., OB35) unless a deterministic receive latency is explicitly required and verified.
3. Size the FDL telegram to the minimum data required; smaller telegrams free CP resources for other connections.
4. Reserve a one-word status location in the sender's DB and write the last AG_SEND.STATUS into it on every ERROR—this gives you a one-cycle-old diagnostic snapshot if a fault develops.
5. Document the NetPro connection ID and CP logical base address in the project header; do not rely on reading them from HW Config at commissioning time.
6. Perform a full cold restart of both stations and a 30-minute soak test after every FDL connection change.
7. If multiple FDL partners share one CP, schedule sends in OB1 (slowest) or OB35 (faster) with explicit timing, not in interrupt OBs without resource budgeting.

11. Related Status Codes and What They Mean

Beyond the resource NAK, other FDL-related diagnostics are sometimes confused with this issue. Distinguish them by their NetPro text and CP STATUS output:

12. Frequently Asked Questions