Displaying S7-1500 System Diagnostic Alarms on Comfort HMI

Overview

System diagnostic alarms generated by a SIMATIC S7-1500 CPU (for example, "Hardware component removed or missing", "Hardware component not available due to type mismatch", or "IO device failure - IO device not found") do not appear automatically in a WinCC Comfort/Advanced alarm view. The alarms must be explicitly routed from the PLC to the HMI through the integrated HMI connection, and the HMI runtime must be configured to receive and render Controller alarms. This article explains the complete configuration path for an S7-1511-1 PN (firmware V2.0.5) paired with a TP1200 Comfort panel (image version V14.0.0.0) in TIA Portal V14 SP1 Update 2 on Windows 7 SP1, with verification steps and a fault matrix for the most common configuration gaps.

Alarm Terminology: System vs. Diagnostic vs. Controller Alarms

TIA Portal uses three distinct alarm categories that are easy to confuse:

When the user reports "My System events list is imported, but it starts with ID 9999", they are looking at the wrong category. The S7-1500 system diagnostic alarms populate the Controller alarms list, not the System events list. The Controller alarms list will remain empty until the integrated HMI connection has system diagnostics enabled.

Prerequisites

1. TIA Portal V14 SP1 Update 2 (or V15 / V16 / V17 / V18 / V19 / V20 - the menu paths are stable across versions). For V20 documentation, refer to Activating system diagnostics - Basic Panels, Panels, Comfort Panels (RT Advanced / RT Professional).
2. SIMATIC S7-1500 CPU with firmware ≥ V2.0 (the example uses 6ES7511-1AK02-0AB0 with FW V2.0.5). The diagnostic buffer and PROFINET diagnostics are always active; no PLC-side program changes are required to emit system diagnostic alarms.
3. Comfort Panel TP1200 Comfort (6AV2124-1MC01-0AX0) with image V14.0.0.0 or later. The TP1200, TP1500, TP1900, TP2200, and KP/ KTP Comfort families all support the same controller alarm path.
4. An integrated HMI connection in the TIA project (Devices & Networks → Connections). A "non-integrated" connection compiled separately will not automatically subscribe the HMI to the PLC's diagnostic stream.
5. The HMI project must be compiled and downloaded to the panel after the PLC project is compiled and downloaded. Compile order matters: PLC first, then HMI, otherwise the HMI's Controller alarms table will be regenerated empty.

Configuration Step 1 - Enable System Diagnostics on the HMI Connection

The single most common reason Controller alarms do not appear is that the per-connection system diagnostics switch is disabled. Activate it as follows:

1. In the project tree, open Devices & Networks.
2. Select the network view and click the HMI-to-PLC connection line (the solid line between TP1200 and S7-1511).
3. In the inspector window (lower right) open the Properties tab.
4. Navigate to Alarms in the connection properties.
5. Check Enable system diagnostics (German: Systemdiagnose aktivieren). This subscribes the HMI to the PLC's diagnostic events over the integrated connection.
6. (Optional) Adjust the acknowledgment model. The default for system diagnostics is "no acknowledgment required"; some events (e.g., remove/insert alarms) are configured by Siemens to require acknowledgment.
7. Click Save project and recompile both the PLC and the HMI.

Configuration Step 2 - Activate System Diagnostics in HMI Runtime Settings

Per-connection enablement is necessary but not sufficient. The HMI runtime must also be told to display controller alarms:

1. Project tree → right-click the TP1200 Comfort → Runtime settings.
2. Navigate to Alarms → Controller alarms.
3. Check System diagnostics. This is the global switch for the HMI runtime to poll the PLC's diagnostic buffer.
4. (Optional, V14 and later) Check S7 diagnostic alarms if you also want raw S7 diagnostic SFCs (SFC 17 / SFC 18 / SFC 107 / SFC 108) to surface. Most users only need "System diagnostics".
5. Click OK and recompile the HMI.

The equivalent path in TIA Portal V20 (RT Unified) is documented at Configuring the display of system diagnostics alarms (RT Unified). Although the example uses RT Advanced (Comfort), the underlying controller-alarm subscription mechanism is identical.

Configuration Step 3 - Configure the Alarm View and Alarm Classes

With the connection and runtime switches enabled, the PLC will populate the HMI's Controller alarms text list. The alarm view must be configured to render them:

1. Open the screen containing the alarm view (or insert a new "Alarm view" from the toolbox → Controls).
2. In the alarm view's properties, open the Alarm classes column.
3. Ensure the following classes are enabled in the alarm view's filter (or remove the filter entirely for first-pass debugging):
   • Acknowledgment (Quittungspflichtig) - for events the user must acknowledge.
   • No Acknowledgment (Nicht quittungspflichtig) - for informational events.
   • System and Diagnosis event (Diagnose-Ereignis) - color and behavior classifications.
4. Under Display → Source, enable "Controller alarms" so the view queries the controller alarm buffer, not only local HMI system events.
5. Optionally insert the SystemDiagnosticsControl (Systemdiagnose-Sicht) instead of a generic alarm view. This control is purpose-built for S7-1500 diagnostics and renders the diagnostic status, module status, and the live diagnostic buffer in a single screen.

PLC System Diagnostic Alarm Sources

S7-1500 system diagnostic alarms are emitted by several internal mechanisms. The three events in the original problem report map to the following sources:

All three are non-user-programmed events. They are generated by the CPU firmware's diagnostic state machine and pushed to any subscribed HMI as controller alarms. No code in OB82 / OB83 / OB86 is required for the alarms to be created; the OBs only control behavior on receipt of the diagnostic interrupt.

Importing PLC Messages vs. Automatic Generation

A frequent source of confusion is the HMI messages → Controller alarms table. There are two valid ways to populate it:

1. Automatic generation (recommended for system diagnostics): TIA Portal generates default controller alarm entries for every module / device referenced in the PLC hardware configuration. The HMI subscribes to these entries and renders the live diagnostic text returned by the CPU. This is what activates when you check "Enable system diagnostics" on the connection. No manual import is required.
2. Manual import: You can import additional PLC messages from the PLC project (PLC → right-click → "Import PLC messages to HMI"). Use this for custom user alarms, not for system diagnostics.

Verification

After downloading both the PLC and the HMI, perform the following checks:

1. On the HMI, navigate to the alarm view. The status bar of the alarm view should show a non-zero "Connected" state to the PLC.
2. Trigger a known diagnostic: power-cycle a PROFINET IO device (e.g., the M-B1D encoder) or briefly remove and reinsert a module.
3. Within 1-2 seconds, a new alarm line should appear with the CPU's timestamp, the affected module's name (e.g., "+M-B1D"), and the diagnostic text. The alarm should have a state color from the configured alarm class (typically orange/red for "Diagnosis event").
4. Open the PLC webserver in parallel and confirm the same diagnostic event appears in the diagnostic buffer. The event IDs and timestamps should match.
5. If using the SystemDiagnosticsControl, verify that the module status indicator turns red/yellow and that the diagnostic buffer pane lists the active fault.

Troubleshooting Matrix

Firmware and Software Compatibility

The configuration path described is stable across TIA Portal V14 through V20, with two minor differences:

• TIA V14 / V15: "Enable system diagnostics" lives on the connection's Alarms tab. Runtime switch is at Alarms → Controller alarms → System diagnostics.
• TIA V16+: The same paths apply; additionally, TIA V16 introduced the "SystemDiagnosticsControl" with an enhanced diagnostic buffer view (read-only on Comfort panels; full read/write on RT Professional).
• TIA V20 (RT Unified): The Comfort panel switches to the Unified runtime only if explicitly migrated. Comfort panels running RT Advanced continue to use the V14-style configuration. See Activating system diagnostics - Comfort Panels (RT Advanced).

CPU firmware V2.0.5 (used in the original report) is sufficient. Firmware ≥ V2.0 supports all system diagnostic events listed in the troubleshooting matrix. CPU firmware V2.6 and later add expanded PROFINET diagnostics (e.g., port-level cable diagnostics) that surface in the HMI automatically once the connection is enabled.

Suppressing Diagnostics for a Faulted Device

The follow-up question asked whether diagnostics can be suppressed for a single faulted device. The answer is conditional: the S7-1500 firmware does not provide a generic per-device diagnostic suppression switch, but two workarounds exist:

1. Disable the module's channel diagnostics: In the PLC device configuration, open the module → Properties → Diagnostics → uncheck the specific diagnostic categories (e.g., "Wire break", "Short circuit"). The module will then no longer emit those events to the diagnostic buffer.
2. Filter in the HMI: In the alarm view, add a filter that excludes the affected module's name. The diagnostic event is still emitted and visible in the PLC webserver, but is hidden on the HMI.

Suppression should be used sparingly; the S7-1500 diagnostic buffer is the primary tool for troubleshooting field faults, and hiding events on the HMI does not silence them in the PLC.

Field Commissioning Checklist

1. Compile PLC, then compile HMI. Both compilations must finish with 0 errors.
2. Download PLC first; verify the PLC webserver shows the expected diagnostic buffer.
3. Download HMI; verify the alarm view is connected to the PLC.
4. Trigger a known pull-plug event (e.g., remove a module for 2 seconds).
5. Confirm the alarm appears on the HMI within 2 seconds, with the correct module reference and timestamp.
6. Reinsert the module; confirm a "return" diagnostic event also appears.
7. Acknowledge the alarm from the HMI (if the class requires it) and confirm the alarm clears from the active list but remains in the archive.
8. Document the final Controller alarms table IDs and text for the maintenance team.

FAQ