SCALANCE X212-2 Link Monitoring on S7-300: Configuring DB126

Problem Overview: SCALANCE X212-2 Port Events Do Not Surface in DB126

A SCALANCE X212-2 managed switch inserted into an S7-300 PROFINET IO system frequently does not trigger an update of the status DB generated by SIMATIC RSE (Report System Error), even when the switch's port LED clearly indicates a link-down condition. With the topology shown below — two SCALANCE X212-2 units fiber-coupled, each carrying one CPU 317F-2 PN/DP, two ET 200S stations, and one MP 370 panel — an operator loses visibility of link faults in the customized alarm view because DB126 never changes state.

Root cause: the SCALANCE X-200 family (X200 v2 firmware generation and later) is not an ET 200-style distributed I/O device. Its port-level link events are PROFINET channel diagnostics, not classic module-pull diagnostics, so the default RSE template only fires on rack/module faults. To get port and partner-port events into the user program, the switch must be configured as a PROFINET IO Device with the proper GSDXML, the ports must be marked for monitoring under STEP 7, and the controller CPU must invoke OB 82 to interpret the channel diagnostic records.

Hardware and Software Prerequisites

The X212-2 ships with a fault contact (signaling contact) wired to a 4-pin M12 socket labeled F2 on the front panel. This is a hardware path completely separate from PROFINET diagnostics; it is wired to a digital input on a fail-safe module and is the only guaranteed way to know the switch itself is alive. Treat it as the last-resort fallback, not as a replacement for link diagnostics.

Why the X200 v2 Differs From X200 v1

SCALANCE X200 v1 (firmware pre-V4) exposed each port as an addressable sub-module slot. STEP 7 HW Config treated each port as a logical module, so RSE could enumerate slot 0 / slot 1 / slot 2 and report per-port status. From the X200 v2 generation onward, the switch still has physical ports, but the firmware no longer maps them to discrete slots in the PROFINET IO image. The switch presents itself as a single IO Device with one DAP (Device Access Point) and zero sub-modules.

The consequence is that PROFINET diagnostics on an X-200 v2 are delivered as channel diagnostics on the DAP, not as module diagnostics on a slot. The RSE wizard looks for module-pull events; it does not parse channel-diagnostic records unless OB 82 is wired and the relevant diagnostic blocks are evaluated. This is the most common reason DB126 remains silent on a link drop.

Step-by-Step: Bring SCALANCE X212-2 Link Events Into DB126

1. Install the Correct GSDXML

1. Download the current SCALANCE X-200 GSDXML from the Siemens Product Support portal (search for 6GK5212-2BB00).
2. In HW Config, choose Options > Install GSD File and point to the downloaded XML.
3. Restart HW Config. The SCALANCE X212-2 must appear in the PROFINET IO catalog under PROFINET IO > Network Components > Siemens AG > SCALANCE X.

2. Insert the Switch as a PROFINET IO Device

1. Drag the SCALANCE X212-2 from the catalog onto the PROFINET IO system that contains the CPU 317F-2 PN/DP.
2. Assign a device name identical to what is configured in the WBM (Web Based Management) — e.g. x212-2-left.
3. Open Properties > PROFINET Interface > General and confirm the IO device is assigned to the controller.

3. Mark the Fiber Port for Monitoring in HW Config

1. Double-click the X212-2 to open its slot view.
2. Select the port that is to be supervised — the fiber port connected to the partner X212-2 in this case.
3. Open Object Properties > Options tab.
4. Set the port mode from Automatic Setting to Automatic Setting (monitor). This enables LLDP-based neighbor detection on the port and converts partner-port mismatch events into PROFINET diagnostics.

4. Build the Topology in the STEP 7 Topology Editor

1. Open Tools > Topology Editor.
2. Right-click the X212-2 port you marked for monitoring and choose Edit Partner Port.
3. Point to the partner X212-2 fiber port. Topology ports must match on both ends for LLDP diagnostics to be classified as port data mismatch events.
4. Save and compile. The topology data is downloaded to the CPU along with the HW Config at the next download.

5. Regenerate DB126 With RSE

1. Open the RSE wizard (Options > Report System Error).
2. Select all IO devices in the PROFINET IO system, including the X212-2.
3. Regenerate DB126 and the associated FB/FBs.
4. Download the entire station (not just DB126). DB49 and other dependency blocks must be refreshed; this is the root cause of the symptom where DB126 updates only after another IO module is pulled.

6. Evaluate OB 82 in the User Program

Channel diagnostics are reported through OB 82 (Diagnostic Interrupt). Add OB 82 to the S7 program — even as a stub — and read the supplied OB82_MDL_DEFECT, OB82_EVENT_CLASS, and the diagnostic data buffer at OB82_LOCAL_DATA[12..25]. The diagnostic record follows the standard PROFINET channel-diagnostic format:

// Channel diagnostic structure (per PROFINET spec)
// Word 0: ChannelNumber
// Word 1: ChannelProperties (type, direction, accumulated)
// Word 2: ChannelErrorType (e.g. 0x000A = link down, 0x000B = link up)
// Word 3: ExtendedChannelErrorType
// Word 4..7: Additional diagnostic info

Within OB 82, evaluate ChannelErrorType = 16#000A (link down) and 16#000B (link up), and tag them into a status word that the HMI (MP 370) can read. This decouples the alarm from the controller's standard RSE pipeline and gives the custom alarm system full visibility.

Alternative Method: Cyclic Connection Check Between CPUs

When the PROFINET diagnostics route proves unreliable — for example, when the partner connected to the monitored port is a non-PROFINET Ethernet node that does not speak LLDP — fall back to a cyclic end-to-end check between the two CPU 317F-2 PN/DP stations. The recommended implementation reads a clock byte from the partner and times the response.

1. Configure an S7 connection between the two CPUs in NetPro.
2. In the local CPU, call PUT / GET every 200 ms to read one byte from the partner's clock-merker byte (e.g. MB10).
3. Monitor the DONE, ERROR, and STATUS outputs of the GET block.
4. If no successful GET is observed within 1 s, raise the link-down alarm.

// Pseudo-code in STL for the cyclic check
CALL  "GET" , DB_GET
  REQ    := TRUE                // toggled by cyclic OB35
  ID     := 1                    // S7 connection ID
  ADDR_1 := P#M 10.0 BYTE 1     // partner clock byte
  RD_1   := P#M 200.0 BYTE 1
NOP 0

// In OB35 (100 ms tick): if DB_GET.DONE not set and timer > 1 s
// => set link-down flag, raise alarm on MP370

This method does not depend on the SCALANCE X212-2 firmware exposing per-port diagnostics, so it survives every firmware update and works equally well across copper and fiber paths.

Hardware Fault Contact (F2 M12 Socket)

The SCALANCE X-200 manual (SCALANCE X-200 Operating Instructions, edition 76) documents the signaling contact on a 4-pin M12 socket on the front of the X212-2. The contact opens (or closes, depending on configuration in WBM under System > Signaling Contact) when any of the following occur:

• Loss of power on at least one supply input.
• Internal fault (e.g. firmware watchdog, temperature out of range).
• Loss of link on a monitored port.
• Removal of the C-PLUG (configuration plug) without authorization.

Wire the F2 contact to a digital input on the ET 200S or directly to the F-CPU's standard DI module, and pass the state to the alarm system. Because the F2 contact is a hard-wired function of the switch hardware, it remains valid even when the PROFINET stack has lost connection to the controller — an essential last-line check in safety-relevant applications.

Verification Procedure

1. Online > Monitor/Modify: open the X212-2 IO device in HW Config. The slot view must show the DAP green and the device status OK.
2. Unplug the fiber patch cord from the monitored port. The DAP must transition to Maintenance required within one PROFINET update cycle.
3. Confirm OB 82 fires. The diagnostic buffer of the CPU must contain a Channel diagnostic entry of type Link down with the correct port and slot reference.
4. Confirm DB126 updates without a full station re-download. If DB126 does not change, the FB chain generated by RSE has not been re-instantiated; delete the old FB/DB and regenerate.
5. From the MP 370, confirm the custom alarm appears within 2 s of the unplug event.
6. Restore the link. OB 82 fires again with channel error Link up; DB126 must clear.

Security and Firmware Considerations

Siemens published CVE-2022-26648 (NVD record) covering SCALANCE X200-4P IRT and SCALANCE X201-3P IRT devices running firmware below V5.5.2. The X212-2 is a closely related member of the X-200 family and shares the Web Based Management and SNMP service surfaces. Apply the latest firmware from Siemens Product Support and validate against the SCALANCE X-200 manual's firmware matrix. Security hardening steps that should accompany a commissioning include disabling unused services in WBM (TFTP, HTTP, Telnet), enforcing SNMPv3 if SNMP is required, and changing the default password.

Troubleshooting Matrix

Operational Notes and Field-Proven Caveats

• The X212-2 supports two ports per port group in monitor mode; configuring more than two on a single switch can increase the OB 82 interrupt rate noticeably during topology changes. Filter the events in OB 82 before posting them to DB126 to keep the HMI alarm buffer from filling during normal moves-and-changes.
• RSE in STEP 7 V5.4 SP2 generates DB126 with a fixed signature. Renaming the IO device after regeneration invalidates the signature; always regenerate after any naming change.
• The MP 370 panel cannot render standard WinCC alarms for events that arrive only via channel diagnostics unless an HMI tag is bound to the same bit that OB 82 sets in the user program. Bind the OB 82 status word to an HMI tag so the custom alarm view can read it directly.
• When the SCALANCE X212-2 is wired in a ring with HRP (High-speed Redundancy Protocol) or MRP, the switch will trigger OB 82 events during a ring reconfiguration. Treat these as informational and debounce the alarm.
• Configuration of port monitoring parameters is firmware-version dependent. After every firmware upgrade, re-validate the port settings under HW Config because firmware upgrades can reset non-PROFINET port parameters in WBM.