ALARM_DQ Alarm Text: Add DB Descriptions in S7-300 TIA Portal

Overview

The Siemens S7-300/400 ALARM_DQ instruction generates acknowledgeable PLC alarms that surface natively in WinCC Advanced runtime - the engine that drives Comfort Panels. Each call emits an alarm entry whose text is defined once in the PLC alarm type editor and merged at runtime with dynamic tokens. When a multi-instance FB is used for repeated assets (motors, valves, pumps), the token $$Instance$$ is replaced with the instance DB name, producing per-asset messages from a single alarm type and removing the engineering overhead of authoring one alarm string per asset.

The catch surfaces in larger plants. The alarm replaces only the tag name; the operator still needs the role of the asset (for example, "Feeding water pump"). TIA Portal documents only four runtime tokens for the ALARM_SQ/ALARM_DQ family, and none of them exposes the instance DB comment or title fields. This reference explains the limitation, why it exists, and the field-proven workarounds that keep engineering effort proportional to the number of alarm types rather than the number of assets.

The ALARM_DQ Placeholder Mechanism

Each ALARM_DQ call binds to an entry under PLC Alarms > Alarm Types in the TIA project tree. The text field supports static strings and four documented substitution tokens. At runtime, the WinCC Advanced alarm banner substitutes the current call context for these tokens, which is what allows a single alarm type to serve N assets. The full set is enumerated in the STEP 7 Professional programming manual, "Configuring PLC alarms" section.

This table is the complete set documented in the STEP 7 Professional System Manual V12 "Configuring alarms" chapter. The manual documents these four tokens as exhaustive; no additional token exists for the DB title or DB comment column. Operators therefore see the asset tag but not its role.

The Description Problem in Multi-Asset FBs

Consider the common motor faceplate FB pattern used on a process plant:

1. A single FB ("MotorControl") encapsulates alarms, interlocks, and HMI tags.
2. Each physical motor is realized as one instance DB: 120-IST1-P003, 120-IST1-P004, etc.
3. Each instance DB carries a Title or Comment property (for example, "Feeding water pump") that documents the asset in the project tree.
4. The alarm type uses the text $$Instance$$ : Motor alarm, producing 120-IST1-P003 : Motor alarm at runtime.

The operator reading 120-IST1-P003 : Motor alarm must remember what P003 means. The Title field is exactly the additional text the engineer wants to surface, but TIA Portal V12 provides no syntax token to splice the Title into the alarm text. In effect, the metadata exists inside the offline project but is invisible at runtime.

Workaround 1: Text Lists (Siemens Documented Approach)

The cleanest field-proven workaround is to build a Text List in WinCC Advanced and reference it from the alarm text. The text list maps the instance DB name (the runtime value of $$Instance$$) to a human-readable description string. Operators see the descriptive string in the alarm row instead of the bare tag. The procedure is documented in the "Configuring alarms with text lists" subsection of the Siemens programming manuals (see the official Siemens manual entry for the alarm-text editing syntax).

Procedure

1. In the HMI project, open Runtime Settings > Text Lists and create a new list, e.g., MotorDescriptions.
2. Add an entry per asset. The Value column contains the instance DB name exactly as it appears in the project tree (for example, 120-IST1-P003). The Text column contains the human-readable description ("Feeding water pump").
3. Open the alarm type, replace the placeholder text with the text-list reference using the syntax %<TextListName>@$$Instance$$%. The %...@...% pattern signals a text-list dereference at alarm time.
4. Compile and download the HMI project. At runtime the alarm view resolves $$Instance$$, looks the value up in MotorDescriptions, and displays the descriptive text.
5. Switch the HMI language and re-trigger to verify each configured language has its own translated Text column.

This approach keeps the alarm type single-sourced and the descriptive data isolated to one editable list. Updates to descriptions require only an edit to the text list, not a regeneration of alarm instances.

Scaling the Text List Beyond 50 Assets

For plants with several hundred motors, the manual list maintenance argument returns. The same Excel-driven object list used to generate DBs can be used to script-generate the text list CSV. WinCC Advanced accepts UTF-8 text list imports for every language defined in the project. A simple PowerShell or Python transform that pivots the object list into the Siemens import format removes the manual touch entirely. STEP 7 Professional V15+ exposes this through the Openness API; see the "Generating Alarms from an External Object List" section below.

Workaround 2: Multiple Alarm Types per Functional Area

If the operator's mental model benefits from per-asset alarm text and the engineer is willing to absorb the type-creation overhead, organize the project so each asset area has its own alarm type. A motor FB for the water-treatment area uses an alarm type with text Water treatment motor $$Instance$$ alarm; one for HVAC uses HVAC fan $$Instance$$ alarm. The prefix is no longer fully dynamic, but it eliminates the runtime lookup and gives the operator immediate area context even when the text list is empty or stale.

This shifts the engineering burden from runtime configuration to project authoring but does not change the runtime character count per alarm, and is often acceptable on small plants where the number of functional areas is bounded.

Workaround 3: Manual Alarm Instance Editing (Last Resort)

Direct editing under PLC Alarms > Alarm Instances yields complete freedom over the rendered text. Each instance DB can carry a hand-edited alarm string. Tradeoffs:

• Manual edits do not survive a regenerate-from-source cycle if the project is built from a master Excel object list.
• Each language configured on the Comfort Panel requires its own translated string per instance. A 50-motor plant with 3 languages becomes 150 strings to maintain.
• Audit trail is poor: there is no enforced link between the edited text and the offline DB title/comment.

Reserve this approach for alarm types that genuinely diverge from the shared pattern - special-case assets with bespoke wording requirements, regulatory texts, or one-off commissioning messages.

ALARM_DQ Instruction Mechanics

Understanding the instruction's calling convention is necessary to design the FB that produces the alarm correctly. From the official TIA Portal documentation for ALARM_DQ, with every call the instruction generates an alarm to which you can append an associated value; the family is the acknowledgeable variant of ALARM_D / ALARM_S. All configuration is stored in the PLC alarm type resources - not in an instruction-specific instance DB - which is why the instance DB name (not the instruction instance) becomes the substitution source for $$Instance$$.

EV_ID is the critical scalar per asset: it must be unique for every motor FB instance so the alarm router delivers the right alarm to the right HMI. A common pattern computes EV_ID by hashing the instance DB name or assigns from a counter block that increments during FB initialization; either approach guarantees project-wide uniqueness without a manual spreadsheet.

Token Coverage Across the ALARM Family

The four documented tokens apply uniformly to the ALARM_S* and ALARM_D* families. NOTIFY has a reduced substitution set; refer to the family-specific reference for the exact strings permitted.

Generating Alarms from an External Object List

The plant engineering pattern (Excel object list -> DB generation -> alarm population) is well-established. The complete flow is:

1. Maintain a master spreadsheet with one row per asset: TagName, Description, Area, EV_ID, AlarmClass.
2. Use the TIA Portal Openness API (introduced in V14, stable from V15) to script the project generation. Iterate the spreadsheet rows; for each row:
• Create the instance DB of MotorControl with the symbolic name TagName.
• Set the DB Title and Comment properties to Description.
• Assign a unique EV_ID.
• Append an entry to the runtime text list mapping TagName -> Description.
3. Recompile and download. The text list is rebuilt automatically on every regeneration, eliminating the "manual edits don't survive regeneration" problem.

Verification and Commissioning

1. After project compile, download the S7 program and the HMI image to the Comfort Panel.
2. Force the IN input of an ALARM_DQ instance high in the FB watch table.
3. Confirm the alarm appears in the WinCC Advanced alarm banner with the expected substitution - e.g., 120-IST1-P003 : Motor alarm.
4. If a text list lookup is configured, confirm the descriptive string replaces the bare tag and matches the configured text list entry.
5. Trigger EV_ID duplicates (two FBs sharing the same event ID) and observe that only the first alarm fires. Engineering tool should warn at compile time; the watch table is the runtime check.
6. Test multi-language: switch HMI runtime language and confirm the appropriate text-list translation renders.
7. Acknowledge the alarm and verify that the ACK output of the ALARM_DQ block transitions to TRUE while the alarm is acknowledged, then back to FALSE when a new occurrence arrives.

Troubleshooting Matrix

Platform Differences: S7-300/400 vs S7-1200/1500

Engineers migrating from S7-300/400 to S7-1200/1500 will find the alarm model fundamentally different. The newer platforms use ProDiag and the Program_Alarm / Alarm_8 instructions, both of which accept user-defined fields directly in the FB source. The "instance DB description" problem does not arise because the alarm text is built in code with full string control:

// S7-1500 style - message text is a STRING input
PROGRAM_ALARM_DB := Program_Alarm(
    SIG      := bAlarmCondition,
    ID       := dwAlarmID,
    TextList := 'Motor alarms',
    SD       := iAssociatedValue
);

The Program_Alarm call takes the message text as an input string parameter, eliminating both the placeholder token and the text list lookup. For greenfield panels on S7-1500, prefer this instruction family. Related Siemens automation platforms have followed the same trend - Inductive Automation's Ignition tag alarm properties expose priority, notes, and display path directly on the tag, and Schneider IGSS treats the alarm text as a structured object with priority, category, and description fields, so the descriptive text is defined independently of the triggering tag rather than spliced at runtime.

Related HMI / SCADA Alarm Models

The "substitute a runtime field with a tag-derived description" pattern is universal across SCADA platforms. For reference, other vendors implement it as follows:

• AutomationDirect C-more event actions use the "Alarm" action to print the configured alarm text into a screen-level banner when the event triggers; tag values can be embedded but no per-instance lookup is built in.
• Inductive Automation Ignition tag alarms expose a comprehensive property block (display path, priority, notes, etc.) so the analog of the instance DB title is configured on the tag itself rather than substituted at runtime.
• Schneider IGSS documents the concept of an alarm text as a structured object with priority, category, and description, allowing the descriptive text to be defined independently of the triggering tag.
• EcoStruxure Building Operation alarm configuration likewise separates the alarm message from the triggering point.

The Siemens ALARM_DQ family predates these richer models; if the broader Siemens ecosystem is the long-term platform target, planning around the four-token constraint - typically with a HMI text list - is the lowest-risk path. If the plant is migrating to S7-1500 within the asset horizon, the modern Program_Alarm / ProDiag flow is structurally simpler.

FAQ