Troubleshooting S7-1200 I-Device PROFINET RCVDP SENDDP Errors

Troubleshooting S7-1200/S7-1500 I-Device PROFINET RCVDP/SENDDP Communication Errors

When an S7-1200 or S7-1500 acting as a PROFINET I-Device suddenly drops communication, the symptom is often a channel diagnostic event in the TIA Portal online diagnostics view, an alarm referencing the configured DP_DP_ID, and a stalled cyclic data exchange. Field experience shows that re-instantiating the RCVDP and SENDDP function blocks (FB) and regenerating the I-Device GSD file is the fastest path to recovery. This reference documents the root cause, the diagnostic ladder, and the engineering controls that prevent the fault from recurring.

1. I-Device Communication Architecture Recap

An I-Device (intelligent IO device) is a CPU that behaves simultaneously as an IO device on a higher-level PROFINET IO controller and as an IO controller for its own lower-level PROFINET subnet. The functional description, transfer area configuration rules, and GSD export workflow are defined in the TIA Portal documentation portal: I-Device Functionality (S7-1200 G2 Manual Collection).

For a standard CPU-to-CPU I-Device link without a higher-level controller, the typical pattern is:

• Both CPUs are configured as I-Devices in their own STEP 7 projects.
• Each CPU exports a GSD file containing the configured transfer areas (slots 0..63).
• The partner CPU imports the GSD file and adds the I-Device as a PROFINET device on its own PROFINET interface.
• Cyclic I/O data is exchanged via RCVDP (Receive) and SENDDP (Send) function blocks called inside the user program of each CPU.

The Siemens application note I-Device Function in Standard PN Communication (PDF) provides the canonical configuration sequence and pin-out for both transfer areas. The safety variant is documented separately in Safety-Related IO Controller-I-Device Communication (PDF).

2. Problem Description and Symptoms

The original fault report showed:

• Two S7-1200/S7-1500 CPUs that had been exchanging I-Device data for an extended period.
• A channel diagnostic event in TIA Portal > Online & Diagnostics referencing the I-Device transfer area.
• The partner device entry displaying cc600.profinet interface_2, indicating the device was a PROFINET endpoint and not a legacy DP (PROFIBUS) slave.
• The user changing the DP_DP_ID and increasing the LDPV2 / F-Shaped update time from 500 ms to 1 s without effect.
• A newly exported GSD file installed on the partner CPU producing the same diagnostic entry.

The signature event typically includes the words "SafetyToCC500" or similar in the diagnostic buffer text, which is misleading because the link itself is a standard link, not a PROFIsafe link. The string is a historical artifact of the I-Device diagnostic block. The actual underlying cause is generally architectural, not a safety-stack failure.

3. Root Cause Analysis

Three classes of root cause account for nearly every intermittent I-Device drop encountered in the field. All three create a queue overflow in the I-Device proxy that drops subsequent RCVDP/SENDDP calls, which is what the diagnostics buffer ultimately surfaces.

3.1 Stale or Inconsistent Instance DB

When the I-Device GSD file is re-imported on the partner, STEP 7 silently rebinds the transfer area offsets to the new instance DB, but the existing RCVDP / SENDDP background DB keeps the old HW ID and the old length. The two views drift apart, and the first warm restart after a topology change shows the diagnostic event. Re-instantiating the FBs refreshes the HW ID set inside the instance DB and clears the mismatch.

3.2 PLC Scan Time Exceeding the Update Window

The RCVDP block has an internal timeout derived from the configured PROFINET update time. If the OB1 cycle time of the I-Device grows above that window (because of background tasks, online changes, or a non-deterministic HMI polling load), the receive call is dropped and the diagnostic event fires. Increasing the update time from 500 ms to 1 s is the correct first mitigation, but it must be applied to both the I-Device GSD and the partner's device view. Changing it on only one side re-creates the asymmetry.

3.3 OB3x Cyclic Interrupt Phase Collision

When an OB30..OB38 (or OB10..OB17 time-of-day) interrupt fires on the same scan edge as the I-Device proxy task, the OB1 cycle stretches and the proxy can miss its slot. The remedy is to assign a phase offset to the OB3x so that the interrupt falls in a known safe window. The original problem report states the project had no OB3x, so this cause is eliminated for that installation, but it must be ruled out in any new instance.

4. Diagnostic Procedure

Work through the ladder in order; do not skip steps because the symptoms look identical to a previous incident.

1. Capture the diagnostics buffer. Connect to each CPU, open Online & Diagnostics > Diagnostics buffer, and note the event ID, the time-of-day, and the incoming/outgoing marker. The Siemens recommendation to "obtain more information by searching for the event ID in the STEP 7 online help" should be followed; the help text gives the exact module and slot the event refers to.
2. Inspect the channel diagnostics. In the same online view, select the I-Device port and read the channel error code. A common return is a hex value indicating "partner CPU not reachable" or "substitute not activated".
3. Verify the PROFINET interface assignment. Confirm that the I-Device is bound to PROFINET interface_1 or interface_2 as the hardware configuration declares, and that the device name and IP address are reachable from the partner subnet.
4. Compare transfer area lengths. On both CPUs, expand Devices & Networks > I-Device > Transfer areas and confirm that the slot offsets and lengths on the GSD exporter match the lengths used in the RCVDP / SENDDP call interface on the importer.
5. Read the OB1 scan time. From the online watch table, monitor OB1_PREV_CYCLE (OB1 prior cycle time) and OB1_MIN_CYCLE / OB1_MAX_CYCLE. A max-to-min ratio above 2:1 typically points to a blocking task somewhere in the project.
6. Check for OB3x. In the project tree, expand Program blocks > System blocks and look for any OB30..OB38. If present, open each and note the configured phase offset.
7. Read the STATUS word of the FBs. Add the instance DBs to a watch table and observe the STATUS output of RCVDP and SENDDP. Siemens return codes in the 80A1..80B4 range indicate PROFINET subsystem errors and confirm the FB-level detection of the link loss.

5. Resolution: Re-instantiate RCVDP and SENDDP

The proven recovery is to delete and re-add the RCVDP and SENDDP blocks in the user program. STEP 7 retains the instance DB layout and refreshes all internal HW IDs, slot pointers, and partner references on the next download.

5.1 Step-by-Step Recovery

1. In the project tree, right-click Program blocks > RCVDP_instance_DB and select Delete. Confirm the prompt. Repeat for the SENDDP instance DB.
2. Open the OB in which the blocks were called. Select the call line and press Delete on the keyboard to remove the call.
3. From the right-hand Instructions pane, expand Communication > PROFINET / PROFIBUS > Other and drag RCVDP into the OB. Assign a new instance DB name (e.g., RCVDP_DB_1) in the dialog.
4. Wire the inputs as previously: ID = transfer area HW ID from the device view, LEN = length in bytes, ADDR = the partner transfer area start, and RECV = the target data block area.
5. Wire the NDR, ERROR, STATUS, and RD outputs to your status logic or to markers for monitoring.
6. Repeat the same procedure for SENDDP, pointing SEND at the source data block and ADDR at the matching partner area.
7. Compile the project, download to the CPU in STOP, then perform a warm restart.

5.2 SCL Reference Implementation

For engineers using Structured Control Language instead of ladder, the same pair of calls is shown below. The block interface is identical between SCL and LAD/FBD.

// Cyclic I-Device transfer on OB1
// Slot 0 = 32 bytes from partner, slot 1 = 32 bytes to partner

IF "FirstRun" THEN
    "FirstRun" := FALSE;
END_IF;

// Receive from partner (slot 0, 32 bytes)
"RCVDP_DB_1"(ID := 16#0001_0000,        // transfer area HW ID
            LEN := 32,                  // length in bytes
            ADDR := 0,                  // partner slot offset
            RECV := P#DB200.DBX0.0 BYTE 32,
            NDR  => "rcv_ndr",
            ERROR => "rcv_err",
            STATUS => "rcv_status",
            RD := P#DB210.DBX0.0 BYTE 32);

// Send to partner (slot 1, 32 bytes)
"SENDDP_DB_1"(ID := 16#0001_0001,        // transfer area HW ID
             LEN := 32,
             ADDR := 0,
             SEND := P#DB220.DBX0.0 BYTE 32,
             DONE => "snd_done",
             ERROR => "snd_err",
             STATUS => "snd_status");

The HW IDs (16#0001_0000, 16#0001_0001) are the actual IDs STEP 7 assigns to the I-Device transfer areas. Always read them from Devices & Networks > I-Device > Transfer areas > Properties > System constants rather than hard-coding them, because they change if the slot layout is re-numbered.

5.3 GSD Regeneration Checklist

If the original GSD was exported before the FB mismatch was introduced, regenerate it. The full sequence is in the standard I-Device application note (PDF); the relevant subset is:

1. Open the I-Device CPU's project in STEP 7.
2. Select the I-Device CPU and choose Export > GSD file from the context menu.
3. On the partner CPU's project, install the new GSD (Options > Manage general station description files (GSD)).
4. Replace the existing I-Device entry in the device view with the new one. Do not re-use the old device object, because the HW IDs from the GSD will not be re-bound to the old RCVDP/SENDDP instances.
5. Recompile and re-download both projects.

6. Verification

After applying the recovery, confirm the link is healthy in three independent ways:

7. Common Fault Code Mapping

The following table maps RCVDP / SENDDP STATUS values to actionable causes. Always cross-check against the STEP 7 online help for the exact TIA Portal version in use, because some codes are version-specific.

8. Prevention and Best Practices

• Pin the PROFINET update time on both sides of the link. Asymmetric settings are the most common silent failure mode. Use values from the Siemens compatibility tool that match the rated I-Device capability of the S7-1200 G2 or S7-1500 CPU in use.
• Keep the GSD version under source control. A textual diff of the exported GSD between project revisions surfaces accidental slot or length changes immediately.
• Avoid OB3x on I-Device CPUs when possible. If cyclic interrupts are required, configure a phase offset so the interrupt does not collide with the I-Device proxy task. A 30% phase shift of the OB3x period relative to the PROFINET update time is a safe starting point.
• Monitor OB1_MAX_CYCLE. Add the diagnostic tag to an HMI screen and raise an alarm if it exceeds 70% of the configured PROFINET update time. This gives early warning of an architectural problem before the I-Device proxy starts dropping calls.
• Do not edit the GSD after the first download. If a slot or length must change, regenerate the GSD, re-import it on the partner, replace the device object (not just the FB), and re-instantiate the FBs.
• Submit a Siemens Support Request with both project archives if the fault reappears within 30 days. The Siemens moderator in the original incident explicitly recommended this, and the answer (which was a simple FB re-instantiation) is the kind of pattern that benefits other teams.

9. Edge Cases and Platform Notes

S7-1200 (firmware V4.x and earlier) vs S7-1200 G2 (V5.x): The I-Device capability set differs. The S7-1200 G2 manual collection, linked above, lists the per-CPU limits for transfer areas, slots, and update times. Do not assume an S7-1200 G2 setting is legal on a V4.x CPU.

S7-1500: The same FBs apply, and the same STATUS codes apply. S7-1500 supports the prioritized startup of PROFINET, which can mask a small scan-time jitter that would otherwise fault the S7-1200 side.

ET 200SP / ET 200AL as I-Device: Possible, but the I-Device GSD must be re-imported on the higher-level controller after any slot change. The same FB re-instantiation pattern applies on the controller side.

Multi-CPU projects: When the I-Device CPU is a multi-CPU rack (S7-1500 only), the PROFINET interface must be assigned to CPU 1; assigning it to a higher-numbered CPU in a multi-CPU configuration is allowed but the I-Device proxy may share its update window with the CPU-to-CPU shared memory transfer, which raises the effective cycle. Increase the update time accordingly.

10. FAQ