TIA Portal Discrete Alarms: Refreshing Dynamic Tag Values

Overview

Siemens TIA Portal and the HMI panels it programs (KTP400 Basic, KTP700 Basic PN, KTP1000 Basic PN, KTP1200 Basic, Comfort Panels, and the SIMATIC WinCC RT Advanced / RT Professional PC runtime) all implement discrete alarms by capturing a snapshot of any inserted tag field at the moment the alarm event fires. Engineers migrating from SIMATIC WinCC Flexible 2008 often assume the bracketed syntax (Code=<tag>) behaves identically inside TIA Portal discrete alarms, and then discover that the displayed value never updates even though the source tag continues to change on the PLC.

This reference explains the underlying acquisition model, demonstrates the correct way to insert a tag field in the alarm text, and provides a field-proven PLC-side refresh sequence that forces the HMI to re-acquire the latest value. It also documents the alarm-buffer and alarm-log consequences of repeatedly triggering the alarm, which is the single most common follow-up failure when the workaround is deployed without forethought.

Prerequisites

1. Engineering station with TIA Portal installed. The minimum version for Basic Panels 2nd generation is TIA Portal V13 SP1; for 2nd generation firmware 2.x features use TIA Portal V16 or later. Comfort Panels and RT Advanced / RT Professional require TIA Portal V15.1 or later for current firmware.
2. SIMATIC HMI panel firmware compatible with the TIA Portal version. KTP700 Basic PN 6AV2 123-2GB03-0AX0 supports firmware V2.x; Comfort Panels (TP700 Comfort 6AV2 124-0GC01-0AX0 and successors) support firmware V17/V18/V19/V20.
3. Configured HMI connection to a SIMATIC S7-1200, S7-1500, ET 200SP CPU, or S7-300/400 with PROFINET.
4. A trigger tag (BOOL) of any length that the PLC sets/clears to indicate the alarm condition. For drive applications, a typical pattern is a status word bit such as ARM.sw.state referencing SINAMICS parameter r2132 in the cyclic telegram.
5. A value tag of an appropriate HMI data type (INT, WORD, DINT, REAL, or STRING) that holds the dynamic content you want to show in the alarm line, for example the fault code from a frequency inverter (SINAMICS V20, G120, S120) or the days remaining in a maintenance countdown.
6. Project-side knowledge of the configured alarm acquisition cycle (default 1000 ms on most panels; 500 ms or 250 ms available on Comfort Panels and RT Advanced). The acquisition cycle sets the lower bound for the refresh workaround described later.

How TIA Portal Captures Tag Values in Discrete Alarms

A discrete alarm in TIA Portal is event-driven, not polled. When the HMI runtime detects a state change of the trigger tag (rising edge for "incoming", falling edge for "outgoing"), the runtime freezes the alarm record. At that instant the runtime also snapshots the value of any tag field embedded in the alarm text. The frozen value is stored in the alarm buffer and is what every viewer (active alarm screen, alarm log, archive) will display for the lifetime of that alarm record.

Three event types trigger the snapshot:

• Incoming — rising edge of the trigger tag (BOOL transitions 0 → 1).
• Outgoing — falling edge of the trigger tag (BOOL transitions 1 → 0).
• Acknowledged — operator presses the ACK key on the panel or the PLC sends an acknowledgment bit per the configured acknowledgment model.

This explains why the same physical alarm can display different values at different times: each event is a separate snapshot. The alarm is only "updated" in the sense that a new event is appended to the buffer; the old event still shows the value it captured originally.

Inserting a Tag Field in a Discrete Alarm

1. In the project tree, open HMI → Alarms → Discrete Alarms. For WinCC RT Advanced/Professional navigate to the same node under your HMI device.
2. Select the discrete alarm that should display the dynamic value (or add a new one with the Add button).
3. In the alarm text editor, place the cursor at the position where the value should appear.
4. Right-click and choose Insert Tag Field from the context menu. In TIA Portal V17/V18/V19/V20 the equivalent command is on the toolbar of the alarm text editor: Insert → Tag Field.
5. In the dialog, browse the HMI tag table and select the value tag. Confirm with OK.
6. The tag field is inserted as a placeholder. Optionally right-click the field and choose Properties to set the display format (decimal, hex, binary, floating point with N decimals, or string). For drive fault codes, the most common choice is Decimal with 0 decimals and a field width that matches the maximum expected code value (e.g., 5 digits for SINAMICS F-class codes up to 65535).

The configured alarm text will look like the WinCC Flexible 2008 syntax for forward-compatibility projects:

Internally TIA Portal stores this as a token list; the <...> notation is the editor's visual representation. The same string imported from a WinCC Flexible 2008 source file via the TIA Portal migration tool is converted automatically to the new tag field token.

The Refresh Problem: Why the Value Appears Frozen

Consider a SINAMICS G120 drive reporting fault code F07900 (motor over-speed) followed within seconds by F30002 (DC-link overvoltage). The PLC fault word is wired to DB_Drive.fault_code (INT). The discrete alarm is configured as:

When F07900 occurs, the trigger tag rises. The HMI captures DB_Drive.fault_code = 7900 and displays "Drive 1 Fault (Code=7900)". The fault clears, the trigger falls, the alarm is acknowledged, and the operator sees the line at the top of the alarm screen. A second later F30002 fires. The trigger rises again. Because the trigger tag is the same, TIA Portal treats this as the same alarm record and overwrites the existing entry. The new snapshot is 30002. The operator therefore sees "Drive 1 Fault (Code=30002)" but loses the prior event from the buffer.

If the operator instead expects to see F07900 until acknowledged and only then have the line update to F30002, the snapshot model will not deliver that behavior. That is the gap the workaround closes.

PLC-Side Refresh Workaround

The workaround makes the HMI re-trigger the alarm so the runtime re-snapshots the embedded tag field. The sequence is implemented entirely on the PLC; the HMI configuration is unchanged.

Sequence of Operations

1. Evaluate the value tag on the PLC using a change-detect block (for example a TON plus edge detection, or a dedicated FB that compares the current value with the last latched value).
2. On detected change, disable the discrete alarm for 2 × the HMI alarm acquisition cycle. On a KTP700 Basic PN with default 1000 ms acquisition this is 2000 ms; on a Comfort Panel set to 250 ms this is 500 ms.
3. After the disable period elapses, send a positive ACK pulse to the panel for the corresponding alarm (PLC-side acknowledgment tag or HMI-side operator ACK).
4. Re-enable the alarm. On the next acquisition cycle the HMI re-fires the alarm, re-snapshots the tag field, and the operator sees the latest value.

SCL Implementation (S7-1200 / S7-1500)

// Refresh helper FB for one discrete alarm with one value tag
// Inputs:  i_trigger   : BOOL  - discrete alarm trigger (wire to HMI tag)
//          i_value     : INT   - the value to display in the alarm text
//          i_acqCyc_ms : TIME - HMI alarm acquisition cycle in ms
// Outputs: q_disable   : BOOL  - drives the HMI alarm "Disable" tag
//          q_ackPulse  : BOOL  - one-shot ACK pulse
//          q_value     : INT   - mirrored to the HMI value tag

FUNCTION_BLOCK FB_AlarmRefresh
VAR
    lastValue    : INT;
    changeDet    : BOOL;
    tOff         : TON;
    tPulse       : TP;
    edgeValue    : R_TRIG;
END_VAR
BEGIN
    edgeValue(CLK := (i_value <> lastValue));
    changeDet := edgeValue.Q;

    // Latch the value mirrored to the HMI
    IF changeDet THEN
        lastValue := i_value;
    END_IF;
    q_value := lastValue;

    // 2x acquisition cycle disable window
    tOff(IN := changeDet, PT := i_acqCyc_ms * 2);
    q_disable := tOff.Q;

    // ACK pulse on falling edge of disable window (re-enable event)
    tPulse(IN := NOT tOff.Q AND tOff.IN, PT := T#200ms, Q => q_ackPulse);
END_FUNCTION_BLOCK

Ladder Snippet Equivalent

|     i_value <> lastValue        |
|-----[/]----------------[P]------(S) changeDet---|

|     changeDet                     |
|------[ ]----------------[TON tOff PT=2s]----|
|                                          tOff.Q -> q_disable

|     NOT tOff.Q AND tOff.IN         |
|----------[/]----[ ]----[TP tPulse PT=200ms]----( ) q_ackPulse---|

|     changeDet                     |
|------[ ]----------------[MOV lastValue := i_value]---|
|------[ ]----------------[MOV q_value  := lastValue]---|

Alternative Display Strategies

The refresh workaround is not free. It generates an extra alarm event for every value change, which can quickly overflow the alarm buffer and alarm log. For most operator-screen applications, one of the following alternatives is preferable.

Screen Output Field for the Live Value

Place an Output field on the alarm overview screen that is bound to the same value tag. Output fields are polled on the configured update cycle (default 1 s) and always show the current value. The discrete alarm text can then be a static message that identifies which alarm (e.g., "Drive 1 Fault Active") and the live value is read from the screen. The operator still has the alarm event in the log, but the current value is sourced from the polled output field, not from the alarm snapshot.

Separate Discrete Alarm per Code

If the number of possible values is small and bounded, configure one discrete alarm per code. For 16 fault codes this means 16 alarm rows; for hundreds of codes it is unworkable, but for a typical drive with 8–16 common faults it is the cleanest solution. Each alarm can have a fully formatted text, no embedded tag field, and no refresh workaround. The PLC demultiplexes the fault code into 16 individual trigger bits.

User-Defined Alarm Class with Multiple Value Placeholders

For Comfort Panels and RT Advanced, TIA Portal supports up to ten process value fields per alarm. Each is a separate snapshot. Use this for alarms where the message itself is variable but the count of variables is fixed (for example "Tank <tag1> at <tag2>% reached level <tag3>"). Each tag field is independent and refreshes only on the next alarm event, so the workaround above still applies if any one of the values can change while the trigger remains high.

AVeVA InTouch-Style Priority Note

Engineers familiar with AVEVA InTouch HMI should note that TIA Portal's discrete alarm priority is independent of trigger state: priority 1 is the highest, the default is 1, and the range is 1–999. Higher-priority alarms do not refresh embedded tag fields; priority is for sorting, color, and filter, not for capture behavior. The AVEVA reference is useful only as a model for the numeric priority range when porting a cross-vendor spec.

Performance and Alarm Buffer Considerations

The HMI alarm buffer size is finite and configured under HMI → Alarm settings → Alarm buffer. Typical values:

Each value change on the PLC, in the refresh workaround, generates one incoming and one outgoing event in the buffer. A value that changes once per second for one shift will produce 28800 events in 8 hours — more than the default buffer of a Basic Panel. If the alarm log is also written, the CSV / SQLite file grows by roughly 80–120 bytes per event, so a single high-frequency alarm can write several megabytes per day.

Mitigation Checklist

• Raise the acquisition cycle to the largest acceptable value (1–2 s is usually fine for operator-displayed alarms).
• Disable the alarm log for the specific alarm class if a live log is not required.
• Use the screen-output-field approach when only the current value matters and history is not needed.
• If history matters, set up a periodic archive rollover (daily or weekly) to a network share, not the panel's local storage.
• Consider the discrete alarm with a single trigger and let the operator drill into a details screen for live values; the alarm log only records the trigger, not the value's evolution.

Verification Procedure

After deploying the workaround, validate it on the live panel or on the PLCSIM / HMI simulation.

1. Force the value tag to a known code, e.g., DB_Drive.fault_code = 1234, and trigger the alarm. Confirm the alarm text shows Code=1234.
2. Without clearing the alarm, change the value tag to 5678 on the PLC.
3. Wait at least 2× the configured acquisition cycle (e.g., 2 s for a 1 s cycle).
4. Verify the alarm text on the panel now shows Code=5678. The alarm may briefly disappear and reappear during the disable window; this is expected.
5. Check the alarm buffer count before and after. The refresh must add at most 2 events (one outgoing during disable, one incoming on re-enable). More than 2 events per change indicates the timing is wrong (e.g., the disable window is too short and the alarm is retriggering during the same cycle).
6. If a log is enabled, confirm the log file size per hour is within the planned budget.
7. Force the operator ACK on the panel and confirm the alarm is removed from the active list, indicating the ACK pulse was received.

Edge Cases and Field-Proven Caveats

• Acknowledgment model mismatch: If the discrete alarm is configured as "Acknowledgment required" but the PLC does not send the ACK bit, the alarm will never clear after the disable window. The operator must ACK from the panel. Decide the acknowledgment model deliberately: panel-side ACK for operator-driven flows, PLC-side ACK for SCADA-driven flows.
• String tag fields truncate to 16 characters on Basic Panels. Longer messages must be split or shortened. Comfort Panels support up to 256 characters per tag field.
• REAL values lose precision if the display format is not set; default is 1 decimal place. Drive current or temperature must use 1 or 2 decimals explicitly.
• Bit-packed trigger tags (e.g., a WORD where bit 3 means "drive fault active") must be demultiplexed in the PLC to a single BOOL before wiring to the HMI trigger. The HMI discrete alarm mechanism requires a BOOL trigger.
• Cyclic telegram mismatches with SINAMICS: if the value tag is bound to PZD word 5 but the drive is configured for telegram 1 (which only has 2 PZD words), the HMI will read garbage or 0. Confirm the drive's telegram configuration (p0922) matches the HMI tag address.
• Cross-project tag references: in TIA Portal V16+ a discrete alarm can reference tags from a sub-device or shared DB only if the HMI connection is correctly configured and the tag's access path is resolved. Otherwise the value will display "####" or "Invalid".
• Re-import after edit: editing the alarm text and re-importing from CSV will renumber the alarm if the alarm number is not preserved. Always preserve the alarm number column when re-importing.

Migration Notes from WinCC Flexible 2008

WinCC Flexible 2008 and TIA Portal use the same conceptual model: tag values are snapshotted on event edges. The visible difference is the editor: WinCC Flexible 2008 used inline (Code=<tag>) text; TIA Portal uses a token inserted via the right-click menu. The migration tool converts inline notation to the new token form on import, but the engineer should verify each alarm text post-migration, especially when the project contains hundreds of alarms.

Known migration anomalies to watch for:

• STRING tag fields where the source string was longer than 16 characters are silently truncated on Basic Panels.
• Bit-numbered trigger tags in WinCC Flexible 2008 (e.g., "Bit 5 of MW10") are translated to BOOL tags in TIA Portal but the connection may be re-bound to a different DB; verify the trigger source after migration.
• Alarm colors and acknowledgment classes are preserved but alarm classes can be merged if duplicate names existed in the source project.

Specification Summary

FAQ