Diagnosing Disconnected PROFINET Ports on S7-300 with 0x802A

Problem Overview: Identifying Disconnected PROFINET Nodes on S7-300

A typical machine builder scenario ties a SIMATIC S7-300 CPU (firmware V3.x for the 31x-2 PN/DP family) to twenty PROFINET IO devices arranged in a ring for cable-break tolerance. The PLC is configured as the IO Controller, the IO Devices sit on the ring, and an SCALANCE switch (for example SCALANCE XC208 or XC216) acts as the Media Redundancy Manager (MRM). When a single segment of the ring breaks, MRP keeps the IO running over the alternate path, but the operator must still see which device went down and which port lost link.

PROFINET provides three independent channels that you can exploit to surface this information to the HMI:

1. Acyclic record reads against each IO Device, specifically PROFINET diagnostics data record 0x802A, which exposes the port link state and port statistics.
2. Diagnostic interrupts raised by the IO Devices, delivered to the CPU via hardware interrupts and consumed in OBs (OB82, OB83, OB86, OB85, OB121, OB122).
3. SNMP polling against the standard IF-MIB (interface state) and the PROFINET MIB, exposed through the SNMP OPC Server of the SIMATIC NET PC software into WinCC.

For a 20-device ring, the cleanest path is acyclic record 0x802A plus OB82/OB86 event capture, because no SNMP OPC Server is required and the CPU itself owns the dataset that the HMI simply reads as a tag. The remainder of this document walks through the structure of 0x802A, the RDREC call, the OB evaluation, and the WinCC wiring that converts raw data into a graphical node map.

PROFINET Diagnostics Architecture on the S7-300

PROFINET diagnostics are split between cyclic and acyclic services:

PROFINET IO devices expose a standardized set of diagnostics indices, summarized below. Only the records relevant to port state are highlighted.

The record 0x802A is the workhorse for port-level fault detection. It bundles, in a single acyclic call, the live link state, MAU type, autonegotiation result, and the cumulative error counts of a port. A pull-cable event flips the link bit within milliseconds, so polling the record on a one-second cycle gives the HMI a near-real-time view of the ring health. See the PROFINET device diagnostics chapter in the Siemens TIA Portal documentation (V20) for the record layout and the call patterns used by the RDREC instruction.

Topology and Hardware Identification

Before any code is written, every IO Device must carry a deterministic hardware identifier (HW-ID) in STEP 7. Without an HW-ID, the RDREC block cannot address the device. The HW-ID is visible in the device properties in the hardware configuration of STEP 7 V5.5 (SIMATIC Manager) and in TIA Portal under Properties → System constants.

Each IO Device typically exposes two PROFINET ports: P1 and P2. In a ring these map to the two neighbours. Record 0x802A is requested per port, so to fully cover one device you issue two record reads, one for slot 0 / submodule 0 / index 0x802A addressed to port 1, and one addressed to port 2. The address used by RDREC is the hardware identifier of the submodule that owns the port, not the device itself.

Data Record 0x802A: Layout and Link-State Encoding

The PROFINET record 0x802A is a vendor-independent record defined in the PI specification "PROFINET Diagnosis Block / Port Data Real". The buffer returned by RDREC has the following high-level layout (the exact byte offset of the per-port block is device-specific and can be obtained from the GSD file under Diagnostic->Record 0x802A):

Inside each per-port block, the PortState field is a 16-bit bitmap that contains the operator-relevant link information. The most relevant bits are:

Bit 0 is the only bit that drives the HMI. A "0" in bit 0 means the cable is broken, the device is powered off, or the remote port is administratively down. Bits 1-4 give diagnostic context for the link that is up. The rest of the per-port block holds error counters (CRC, fragments, undersize, oversize, jabber) which are useful for trending intermittent faults (see section Intermittent Disconnections).

Calling RDREC Against Record 0x802A

STEP 7 V5.5 exposes the standard block FB "RDREC" (SFB52) for S7-300. In TIA Portal the equivalent is the "RDREC" instruction inside the "Extended instructions → Diagnostics" group. The call signature is identical:

The recommended SCL wrapper that issues one read per port is shown below. The FB is called from OB1 with a one-second cycle; the busy-state machine guarantees that only one acyclic transaction is active at a time across the whole network.

// FB_PortStatus - read 0x802A for a single port
FUNCTION_BLOCK FB_PortStatus
VAR_INPUT
    iHW_Submodule : HW_IO;    // e.g. HW_IO of port 1 of the IO device
    iCycleEnable  : BOOL;    // 1 = allow next read
END_VAR
VAR_OUTPUT
    oLinkUp       : BOOL;    // 1 = link OK
    oSpeed        : BOOL;    // 0=10M, 1=100M
    oFullDuplex   : BOOL;
    oAutonegOK    : BOOL;
    oDone         : BOOL;
    oBusy         : BOOL;
    oError        : BOOL;
    oStatus       : WORD;
END_VAR
VAR
    sRDREC : RDREC;          // or SFB52 on S7-300
    sBuf   : ARRAY[0..63] OF BYTE;
    sStart : BOOL;
END_VAR

BEGIN
    sStart := iCycleEnable AND NOT sRDREC.BUSY;

    sRDREC(REQ      := sStart,
           ID       := iHW_Submodule,
           INDEX    := 16#802A,
           MLEN     := 64,
           VALID    => oDone,
           BUSY     => oBusy,
           ERROR    => oError,
           STATUS   => oStatus,
           LEN      => ,
           RECORD   := sBuf);

    IF oDone AND NOT oError THEN
        // BlockHeader at +0/+2 skipped; assume PortState at offset 12
        // for the listed device family. Cross-check with GSD.
        oLinkUp     := (sBuf[12] AND 16#01) <> 0;
        oSpeed      := (sBuf[12] AND 16#02) <> 0;
        oFullDuplex := (sBuf[12] AND 16#04) <> 0;
        oAutonegOK  := (sBuf[12] AND 16#08) <> 0;
    END_IF;
END_FUNCTION_BLOCK

Call the FB once for each of the 20 devices and twice for the two ports of each device, in OB1, with a request trigger derived from a clock bit or a time accumulator so the entire scan finishes within one PROFINET update cycle.

On the S7-300, wrap the call in a "single-shot per OB1" pattern: a clock-bit generator in OB35 (e.g. 100 ms tick) gates REQ, and a 1-of-N sequencer walks through the 40 reads (20 devices × 2 ports) one per OB1 pass. This avoids piling up acyclic jobs on a CPU that has a limited RPC queue.

Diagnostic OBs as a Fast-Event Path

The acyclic scan catches steady-state link state, but a cable break usually arrives in the CPU as a hardware interrupt first. Capturing that interrupt delivers sub-100 ms fault-to-HMI latency, well before the 1-second cyclic 0x802A poll would notice. The relevant OBs are:

For the 20-device ring use case, the highest-value OB is OB86. A device that fully drops off the ring generates a "station failure" event (FLT_ID = B#16#C4) with the diagnostic address of the missing device in OB86_MDL_ADDR. A "station return" (FLT_ID = B#16#C5) is raised when the device reappears. Copy the address and the FLT_ID into a global diagnostic DB that the HMI polls:

// OB86 - PROFINET station failure / return
ORGANIZATION_BLOCK OB86
TITLE = "PROFINET Station Failure"
VERSION : 1.0
VAR_TEMP
    tInfo : DWORD;       // OB86_FLT_ID in first byte
END_VAR
BEGIN
    IF (OB86_FLT_ID = B#16#C4) THEN
        // Station failure - device went down
        gDiagDB.LastEvent  := 86;
        gDiagDB.EventState := 1;            // 1 = lost
        gDiagDB.MissingAddr := OB86_MDL_ADDR;
    ELSIF (OB86_FLT_ID = B#16#C5) THEN
        // Station return - device back
        gDiagDB.LastEvent  := 86;
        gDiagDB.EventState := 0;            // 0 = present
        gDiagDB.MissingAddr := OB86_MDL_ADDR;
    END_IF;
END_ORGANIZATION_BLOCK

OB82 and OB83 are required only if you want to show per-channel faults (e.g. a single DI card on an ET 200SP losing wire-break detection) or Pull/Plug events. OB85 and OB121/OB122 are usually generated when the application code still tries to read inputs from a missing device; provide a default empty OB to keep the CPU in RUN. See the TIA Portal V20 PROFINET diagnostics chapter for the full OB variable list and the corresponding local-data layout.

SNMP-Based Port Monitoring (Without SNMP OPC Server)

When the network contains managed switches (SCALANCE XC208, XC216, XR-100, etc.) and the user wants to display every switch port, not just the IO Device ports, the SNMP path becomes attractive. Standard MIB-II ifTable exposes ifAdminStatus and ifOperStatus; the PROFINET device MIB additionally exposes portState and linkState. Two implementation options exist:

1. SNMP OPC Server from SIMATIC NET, which exposes MIB-II variables as OPC DA items that WinCC reads directly. The historical choice, but adds a Windows service that must be licensed and started.
2. Self-written SNMP client in the S7-300/400 using the FB "SNMP" delivered with the SIMATIC NET OPC Server's SDK. Not recommended on S7-300 due to memory constraints.
3. Direct WinCC SNMP driver using a third-party OPC UA gateway (e.g. HMS Anybus PROFINET Diagnostics whitepaper for a full MIB walk).

The advantage of the SNMP OPC Server approach is the ability to reuse the standard ifOperStatus across vendors. A value of up(1) in ifOperStatus means the port is administratively and operationally up. A value of down(2), testing(3), unknown(4), or dormant(5) flags trouble.

For a pure 20-device ring with no managed switch, the SNMP path is overkill; stick with the RDREC + OB86 approach.

HMI Wiring with WinCC (Without an SNMP OPC Server)

The diagnostic DB built up by the FBs and OBs is exposed to WinCC as ordinary tags. The recommended layout for a 20-device screen uses a structure of 40 BOOLs (one per port of each device) plus an array of 20 BYTEs (per-device state).

In WinCC (TIA Portal or WinCC V7.5), map the structure to a graphic that uses the same ring topology as the hardware. The classic pattern is a circle of 20 colored circles representing devices, with each circle driven by a C-Script or a "Color animation" tied to gDiagDB.D[i].State:

Build the topology from a SmartLibrary "Conveyor" graphic or a user-defined SVG; bind the Fill color property of each circle to a script that converts the state value to a WinCC color. For a no-script solution, use the WinCC Flashing attribute for State=1 to draw operator attention. The HMS Anybus eBook on PROFINET diagnostics shows the typical web-server-based views and how to convert the same data records into a web visualization when an HMI is not present.

Ring Diagnostics with MRP

A ring topology is typically realized with Media Redundancy Protocol (MRP) as defined in IEC 62439-2. The SCALANCE switch is the MRM (Manager); the IO Devices and the CPU's PROFINET port are MRP clients. Two roles, two debug angles:

1. MRM normal state — One port of the manager is "blocked" (typically "Ring Port 2"). The other ring port is "forwarding". When a break occurs between two clients, the manager opens the blocked port and reroutes traffic.
2. MRM error state — The manager logs an entry in its own WebUI under Information → MRP showing the time of the last topology change, the blocked/active port, and the connected neighbours.

To expose MRP state to the HMI, two options exist. The simplest is the SCALANCE built-in web server (HTTP, port 80/443) which renders the ring status as an HTML page. The more deterministic option is to query the SCALANCE SNMP agent with mrpRingState (OID 1.3.6.1.4.1.4329.6.6.1.1) and mrpRingPortState (OID 1.3.6.1.4.1.4329.6.6.1.2). Map these two OIDs into the SCALANCE PROFINET MIB and the SNMP OPC Server can surface them in WinCC.

For the operator screen, the SCALANCE state can be reduced to a single BOOL RingHealthy. A cable break that triggers MRP reconfiguration momentarily shows RingHealthy = 0 until the manager completes the reconfiguration (typically <200 ms), then both ring ports show forwarding and the operator continues to see the actual device faults driven by 0x802A.

Hardware Diagnostics in STEP 7 (SIMATIC Manager)

For initial commissioning, the SIMATIC Manager offers three built-in views that complement the script-based approach:

1. Online → Accessible Nodes — Discovers every device reachable on PROFINET, shows IP, MAC, device name, and online status. Used to verify that all 20 devices answer after wiring.
2. PLC → Diagnostic Buffer — Shows the most recent OB82/83/86/85/121/122 events with a timestamp. This is the first place to look when the HMI says "station lost" and the operator wants the precise logical address and time.
3. PLC → Module Information → IO Device — Per-device port statistics (CRC errors, discarded frames, life-sign misses) for the PROFINET port of every device. Identical information to record 0x802A counters, fetched with no code.

On TIA Portal, the equivalent view is Online & Diagnostics → PROFINET diagnostics → Port statistics. The view shows the same data record and is the easiest way to confirm a port is healthy before relying on the HMI script.

Use these views to verify the build first, then deploy the SCL code. The Cognex support article on intermittent PROFINET disconnections describes a similar check using the same PROFINET diagnostics view, but adds the test of pulling the cable while the diagnostic buffer is open to confirm that the buffer records the event.

Handling Intermittent Disconnections

A field engineer should expect three recurring failure modes on a 20-device PROFINET ring, summarized in the troubleshooting matrix below. The fix for each is the same record 0x802A but with a different parser — use the error counters, not just the link bit.

General EMC rules for the S7-300 PN port to keep error counters at zero:

1. Use only CAT 5e or higher SF/UTP or S/FTP cable, with characteristic impedance of 100 Ω ± 15 %.
2. Maximum segment length 100 m between two PROFINET devices (100BASE-TX).
3. Maintain at least 200 mm of separation from VFD motor cables routed in parallel; cross at 90°.
4. Ground the cable shield on both ends to the cabinet PE bar, with a low-impedance bond (10 mm² minimum).
5. Avoid routing the PROFINET cable alongside 24 V power supply conductors of VFD intermediate circuits.

Refer to the HMS Anybus eBook "10 Costly PROFINET Mistakes" for the field-proven list of recurring installation faults, including misconfigured topology, wrong GSD revision, and improper device-name assignment.

Verification Procedure

After commissioning, validate that the HMI shows the correct node and port when a break is introduced. The recommended acceptance test runs in the following order:

1. Start with all 20 devices online, HMI shows 20 green circles, both ring ports of SCALANCE show "forwarding" (one "blocked").
2. Open SIMATIC Manager → Online → Accessible Nodes. Confirm 20 devices respond.
3. Open the diagnostic buffer, clear it (or note the time).
4. Pull the cable between Device 7 and Device 8. Within 1 second, the HMI should show Device 7 and Device 8 in the yellow "Port 1/2 down" state.
5. Wait 2 seconds. SCALANCE should reconfigure; one of its two ring ports should flip from "blocked" to "forwarding". The ring remains logically intact.
6. Open the diagnostic buffer. Verify one OB86 entry with FLT_ID = B#16#C4 referencing the logical address of Device 7 (or Device 8) — the device that lost both ring neighbours.
7. Reconnect the cable. Within 1 second, both devices return to green. The diagnostic buffer records a station-return entry (FLT_ID = B#16#C5).
8. Open the WinCC tag list. Confirm that the values of gDiagDB.D[i].State cycle through the expected states (0 → 2 or 3 → 0) for the affected i.
9. Run the same test on the remaining 19 break points. Each break should affect exactly two adjacent devices in the ring.

Acceptance criteria: every break location produces the expected HMI state within 1.5 seconds of the cable being pulled, and the SCALANCE reverts to "one blocked ring port" within 5 seconds of the cable being reconnected.

Troubleshooting Matrix

The compact field reference that follows condenses the preceding sections. Use it as a first-pass lookup before opening the diagnostic buffer.

FAQ