Resolving CP 343-1 PROFINET DCP Failure with M-Bus Gateway

1. Problem Overview

An S7-300 station built around a CPU 313C and a CP 343-1 PROFINET communication processor is unable to establish a cyclic data exchange with a third-party M-Bus to PROFINET gateway (M-Bus = Meter-Bus, EN 13757). The remainder of the PROFINET subnet — six frequency converters and one ET 200S distributed I/O — continues to communicate without issue, so the failure is isolated to the newly added M-Bus device.

The PLC controller emits PROFINET DCP Ident Requests with the configured NameOfStation (e.g., mbus) at one-second intervals on the PROFINET multicast address 01:0e:cf:00:00:00, but the M-Bus gateway never answers with an Ident Response, never returns a Get Response, and never enters cyclic data exchange. The PLC's IO controller diagnostic buffer accumulates "Device not found" or "Station failure" entries. The S7 program polls the PNIO send/receive blocks (FC12 AG_SEND / FC13 AG_RECV) on the CP without raising non-zero STATUS codes — meaning the cyclic frame exchange is never even initiated because the device was never parametrized.

2. System Architecture and Components

The reference installation is composed of the following modules. Pin down each item with its catalog number and firmware version before commissioning; M-Bus gateways in particular have several hardware revisions, and the GSD file you import must match the firmware.

The CP 343-1 is configured as the PROFINET IO Controller. The ET 200S and the six converters act as IO Devices. The CP exposes the PROFINET interface to the S7 program through the AG_SEND (FC12) and AG_RECV (FC13) function blocks. The standard S7-300 CPU 313C has no integrated PROFINET interface — all PROFINET IO traffic is terminated by the CP.

3. Root Cause Analysis: PROFINET DCP Discovery Failure

PROFINET IO controllers use the Discovery and Configuration Protocol (DCP), which is a sub-protocol of LLDP and is defined in IEC 61158-6 / PROFINET specification, to identify and assign parameters to devices. The handshake proceeds in this order:

1. The IO controller broadcasts a DCP Ident Request (multicast 01:0e:cf:00:00:00, frame ID 0xfefe) with the configured NameOfStation.
2. The addressed IO device answers with a DCP Ident Response (unicast back to the controller's MAC).
3. The controller issues DCP Set IP / Set Name requests if the device has no valid name or IP, then DCP Hello confirms.
4. Only after the LLDP neighbor exchange and the AR (Application Relationship) establishment does cyclic IO follow.

A capture on the SCALANCE X200 mirror port shows that the controller is repeatedly sending DCP Ident Requests (frames 7 and 17 in the Wireshark capture, XID 0x300c437 / 0x300c438, NameOfStation = "mbus") with no Ident Response. This single symptom has four plausible root causes in this configuration, which must be ruled out in order:

In this installation, the on-site trace demonstrated that causes A, B, and C were eliminated: the device was on the same flat PROFINET subnet, was powered, and PRONETA could see it under its factory MAC with its configured IP (192.168.2.13). Cause D — a slot/GSD mismatch — is by far the most common failure when adding a third-party PROFINET device to a CP 343-1 installation.

4. Symptom Analysis with Wireshark Capture

Capture the PROFINET traffic on a span port attached to the SCALANCE X200. Configure the X200 with port mirroring from the gateway port to the engineering port. In Wireshark, set the display filter to pn-dcp || pn-io || pn-mrp to filter out unrelated TCP/UDP noise.

The decisive frame pair to capture is:

• Frame Tx: Source = IO controller MAC (e.g., SiemensA_d7:f9:d6 = 00:0e:8c:d7:f9:d6), Destination = PN-MC_01:0e:cf:00:00:00, Protocol = PN-DCP, Type = Ident Request, Block = NameOfStation, Value = "mbus".
• Frame Rx (expected): Source = gateway MAC, Destination = controller MAC, Protocol = PN-DCP, Type = Ident Response, Block = NameOfStation, DeviceId, IP, Subnet, Gateway.

If only the Ident Requests appear — repeating every 1 s with incremented XID — the gateway's PROFINET stack is not responding. Confirm by also filtering lldp to verify the gateway is sending LLDP neighbor advertisements; absence of LLDP confirms the gateway's PROFINET application is not running on the port. In some captures a few stray LLDP frames appear (the LLDP-MED or generic lldp frames visible in the trace are link-layer discovery only — they are not the PROFINET application relationship.

Use File → Export Specified Packets to save the filtered capture as a .pcapng file for vendor support. Always include frames in both directions and the boot sequence of the gateway.

5. Diagnostic Tools and Procedures

5.1 PRONETA (Siemens network analysis tool)

PRONETA is the official free tool from Siemens for PROFINET commissioning. It is the fastest way to validate that the gateway is electrically present and configured correctly.

1. Install PRONETA on a Windows PC and connect to the same physical network as the gateway.
2. Open the Network Analysis view → click Start Search. The gateway must appear in the device list with its MAC, IP, NameOfStation, and device type.
3. Right-click the device → Set IP and Set Name to the values expected by the STEP 7 HW Config.
4. Open the IO Test view → load the GSD file via the GSD Manager (the GSDML-Vx.x-…xml file shipped by the gateway vendor). Verify that the module list under Slots matches the configuration in HW Config exactly. Mismatched slot lengths (for example, HW Config defines a 4-byte output slot that does not exist on the device) cause the controller's parameterization to be rejected.

The GSD file format is the standardized GSDML (Generic Station Description Markup Language) based on XML. PRONETA includes a GSD Manager that allows you to import and inspect GSD files from third-party vendors.

5.2 Wireshark with PROFINET dissector

Wireshark ships with a built-in PROFINET dissector (since version 2.0). Enable it via Analyze → Enabled Protocols → PN-DCP / PN-IO. The dissector decodes DCP blocks, ARs, and IOCR payloads.

For deeper analysis, Siemens publishes the PROFINET plugin for Wireshark as part of the SIMATIC Automation Tool package, which adds PROFINET alarm and record-data decoding.

5.3 SCALANCE X200 port mirroring

From the Web Based Management (WBM) of the X200 (e.g., https://192.168.2.1), navigate to Layer 2 → Mirroring and configure the gateway port as the source and the engineering PC port as the destination. The mirrored traffic is read-only — it does not interfere with the running PROFINET.

6. Step-by-Step Troubleshooting Procedure

1. Verify physical layer. Link LED on the gateway's PROFINET port must be solid green or blinking green. Check for crossed pairs — PROFINET uses the standard Ethernet pinout (T568B), but industrial M12 D-coded connectors are polarity-tolerant.
2. Check power and gateway boot. Many M-Bus gateways have separate M-Bus and PROFINET power inputs (24 V DC). Verify both are present and that the gateway's PROFINET stack has finished initializing (LED pattern per the device manual, typically a steady green Ready LED).
3. Run PRONETA network analysis. Confirm the device is visible, that its IP and NameOfStation match HW Config, and assign them if missing.
4. Re-import the latest GSD file. Download the GSDML directly from the gateway manufacturer; do not rely on the version embedded in HW Config. Right-click the gateway in the STEP 7 device catalog → Update GSD or Reinstall GSD.
5. Compare slot configuration. In HW Config, expand the gateway device and check every slot. The slot list must exactly match the gateway's published module list. If the gateway's PROFINET side has no 4-byte output slot but your HW Config declares one, delete the slot, recompile, and download the HW Config to the CPU.
6. Restart the gateway. Power-cycle after assigning the name — many PROFINET stacks only commit the NameOfStation to non-volatile storage on a clean boot.
7. Clear the diagnostic buffer on the CPU. Use STEP 7 → PLC → Diagnostic/Setting → Clear Diagnostic Buffer then restart the PROFINET IO system: PLC → PROFINET IO → Restart IO.
8. Capture traffic with Wireshark. Confirm that DCP Ident Requests now receive Ident Responses and that the controller issues a DCP Set followed by an AR establishment.
9. Check FC12/FC13 status. Once the IO device is up, FC12 AG_SEND / FC13 AG_RECV return STATUS = 0000h and DONE = TRUE for every successful cycle. Any non-zero status indicates a CP-side problem (see Section 9 for the error table).
10. If the gateway still does not respond, contact the gateway vendor with the Wireshark capture. Provide the GSD revision, the gateway's firmware version, and the exact HW Config slot layout.

7. Slot Configuration and GSD File Mismatch

The most frequent cause of an M-Bus gateway that powers up and shows link but never reaches cyclic IO is a slot layout mismatch. PROFINET IO devices advertise a fixed set of slots and sub-slots defined in the GSDML; the controller's HW Config must request exactly that set. If a slot is defined in HW Config that the device does not support, parameterization fails and the AR (Application Relationship) is not established.

Concrete example: the user defined a 4-byte output slot at sub-slot 1 of the gateway. The vendor's GSD only advertises sub-slots 1 and 2 with 0 bytes / 16 bytes input. The controller requests a parameterization that the device cannot satisfy, the device returns a PROFINET alarm "Module Diff Block" or "Submodule not available", and the AR is rejected.

To rebuild the slot layout from scratch:

1. Open the GSDML file in a text editor. Look for the <ModuleList> block. Each <ModuleItem> lists the supported module identifiers and slot counts.
2. Open HW Config, delete the gateway device, re-insert it, and place only the modules documented in the GSDML. Do not add modules "to be safe" — extra modules are the failure.
3. Compile and download. Observe the controller's diagnostic buffer: the device should now transition from Station failure to Station OK.

8. Alternative Architecture: DP-MBUS Gateway with Built-in DP

Where the PROFINET ↔ M-Bus gateway cannot be brought up despite a verified GSD, firmware, and switch configuration, the field-proven workaround is to replace the S7-300's PROFINET-only stack with PROFIBUS DP. The CPU 313C variant 6ES7313-5BF03-0AB0 has an integrated DP interface (MPI/DP, 12 Mbps) which can act as a DP master. The PROFINET side of the system is preserved via the CP 343-1, while the M-Bus is brought in through a DP ↔ M-Bus gateway.

This swap is plug-and-play on the application level: the M-Bus data appear as PROFIBUS DP input bytes, addressable directly in the S7 program via PEW / PED on the configured DP slave slot. No FC12/FC13 calls are needed because the DP master is integrated in the CPU. The user on the original install confirmed that exchanging the gateway for a DP variant and using the CPU's built-in DP interface brought the meter values up "right away".

Trade-offs of the DP path:

9. CP 343-1 FC12/FC13 Status Codes

When cyclic IO is up, FC12 AG_SEND and FC13 AG_RECV return the following common status codes. The full table is in the CP 343-1 manual.

10. Verification and Validation

After the gateway is reachable and cyclic IO is up, validate the full path from the M-Bus meter to the S7 program:

1. In STEP 7, open the gateway's Module Information dialog and confirm Status = OK on every slot.
2. Open a VAT table on the configured input bytes (e.g., IB 200) and observe the raw M-Bus data. For an M-Bus heat meter, the first bytes are the fixed header per EN 13757-3 (0x68 0xLL 0xLL 0x68), followed by C-field, A-field, CI-field, and the data records.
3. Cross-check the values against the meter manufacturer's commissioning tool (e.g., the M-Bus level converter connected directly to a PC running the vendor software).
4. Force an M-Bus error condition (e.g., disconnect a meter) and confirm that the gateway propagates a PROFINET alarm visible in the CPU's diagnostic buffer.
5. Capture a final Wireshark trace on the SCALANCE mirror port. The PROFINET dissector should show a steady flow of cyclic Real-Time (RT) frames with the configured IOCR payload, plus DCP Hello frames every 30 s.

11. Preventive Best Practices

• Pin every GSD to a revision. Tag the GSD file used during commissioning in the project documentation. Vendor firmware updates may change the GSDML, and a "drive-by" firmware update can silently break the slot layout.
• Avoid mixing DCP-assigned and statically-assigned names on the same segment. Pick one model — typically static, via PRONETA — and apply it consistently.
• Do not filter DCP multicast on the SCALANCE. PROFINET requires 01:0e:cf:00:00:00 to be flooded. Block this multicast on a managed switch and PROFINET discovery will silently fail.
• Keep the CP 343-1 firmware up to date. Siemens fixes DCP handling edge cases in every major release. The current firmware is available on the Siemens Industry Online Support portal.
• Test the third-party gateway on a bench with a stand-alone CP 343-1 + CPU 313C + SCALANCE X208 setup before mounting it in the cabinet. A 30-minute bench test catches slot mismatches that take 3 hours to debug in the field.
• Document the M-Bus side as carefully as the PROFINET side. M-Bus has its own baud rate (300, 2400, 9600), addressing, and collision behavior. The gateway's M-Bus side must match the meter cluster; mismatches manifest as the gateway reporting "MBus timeout" without any PROFINET-side clue.

12. FAQ