Tracing Alarm Texts in Legacy ProTool V6 Projects on Windows HMI

Problem Summary

A ProTool V6.0 SP3 configuration project runs on a third-party Windows industrial PC (IPC), not on a Siemens panel. The runtime displays alarm and event messages correctly on the screen and in popup windows. However, in the ProTool configuration tool the engineer cannot find the texts of those alarms - neither in the "Messages" node of the project tree nor in the area pointer documentation. The end result is that the team cannot trace the displayed messages back to a tag, a bit, a data block (DB) word, or any specific PLC memory location. Without that mapping it is impossible to modify the alarm text, retarget the trigger, or reconnect the alarm after a STEP 7 / TIA Portal migration.

This article reconstructs the most common reasons ProTool appears to hide alarm texts and provides a step-by-step diagnostic procedure to recover the connection between the visible HMI alarm and the PLC bit or word that triggers it. The guidance applies to ProTool/Pro RT V6.0 + SP3 on Windows (32-bit) and is forward-compatible to WinCC Flexible 200x and TIA Portal WinCC for engineers planning a migration.

Root Cause Analysis: Why ProTool Hides Alarm Texts

There are five distinct reasons a ProTool project can display alarms while the Messages tree appears empty. Identifying which applies is the first diagnostic step.

1. The configuration was migrated from an older ProTool version

ProTool V6.x reads back project files (.pdb) created with V5.x and earlier. During the upgrade, message definitions can be silently re-categorised. "Bit messages" (Bitmeldungen) and "Analog messages" (Analogmeldungen) created in V5 may surface under "Event messages" (Ereignismeldungen) or as a generated event log rather than as user-editable "Alarm messages" (Alarmmeldungen). They are still present in the project, but the project-tree filter does not display them under the expected node.

2. The runtime was compiled separately from the configuration

ProTool stores the editable configuration in the .pdb file and the runtime database in the compiled output (.fwd / .fwx). The "Messages" tree shows entries from the .pdb only. If a third-party integrator used a back-end runtime database or imported message texts via a CSV batch, the project tree will be empty even though the runtime shows them. This is the typical state of legacy "production" projects that have been touched up directly on the runtime IPC and never re-synchronised with the engineering source.

3. The alarms are not "messages" - they are screen-bound text fields

This is the most common cause in the field. The displayed text is not a configured alarm at all. Instead, a screen object (typically an "Output field" or "Symbolic I/O field" with text list or graphics list linkage) is driven by a tag whose value is mapped to a string from a Text List (Textliste) or from a Graphics List (Grafikliste). ProTool renders the value-to-text substitution at runtime; the configuration shows only a tag and a list reference, never a "message" object. Operators see what looks like an alarm, but the engineering tool shows nothing under Messages.

4. The alarms are driven by a system diagnostic tag

ProTool exposes a set of internal "PT_*" service tags (for example, "PT_current_user", "PT_date_time", "PT_recipe_number", "PT_service text"). Some integrator projects route PLC-side error numbers through one of these service tags as a workaround, which makes the message look like an internal diagnostic when in fact it is a user alarm. The "PT_service text" tag is a known carrier for free-form operator prompts in ProTool/Pro RT and is often used to display string content loaded from a PLC DB into a screen output field.

5. The project was re-saved in WinCC Flexible and re-imported

Round-tripping a ProTool V6 project through WinCC Flexible 200x is supported but not lossless. Message objects that depend on ProTool-only fields (long text, "go to screen" tag, free-form acknowledge tag) can be downgraded to "events" on import. The visible behaviour is preserved; the editable representation is not. A symptom of this case is that the Messages tree shows fewer entries than the operator remembers.

ProTool Message Architecture: Bit, Analog, Event, System

ProTool distinguishes four message classes. Knowing which one is in use determines where the text is stored.

Every configured message stores its text in the project database, keyed by message number, language, and class. If the project tree shows the node empty, none of the first three classes is in use, which is what points the engineer toward the Text List mechanism (case 3) or a runtime-only string source (case 2).

Area Pointers: The HMI-to-PLC Handshake

ProTool uses area pointers (Bereichszeiger) to establish typed handshakes with the PLC. The pointer configuration does not contain alarm text, but it controls how messages are acquired, time-stamped, and acknowledged. The pointers relevant to alarm tracing are:

Each configured bit alarm occupies one bit in a trigger word and (if acknowledged) one bit in an acknowledge word. The configured "alarm word" address is the first place to look when searching for the connection to the PLC. In the user's situation, the project tree does not list a Messages node, so the configured alarm words do not exist - reinforcing the Text List hypothesis.

Locating the Alarm Texts: Step-by-Step Procedure

Use this sequence in order. Each step is non-destructive; stop as soon as the source of the text is identified.

Step 1 - Confirm the project file in use

1. Open the running runtime on the IPC. The title bar shows the project name and the project file path. In ProTool/Pro RT V6, the project is loaded from the path configured under Start Center > Settings > Project Path, default %ProgramFiles%\Siemens\ProToolRT\RT\PROSAVE.
2. Copy the running project (.fwd for the runtime database, plus .ldb for the language database) to an engineering workstation. The ProSave tool (File > Backup) extracts the live runtime data set.
3. Open the .pdb source project in ProTool V6.0 SP3. If the integrator left a .pdb, the message text will be visible under the Messages node. If the Messages node is empty, proceed to Step 2.

Step 2 - Cross-reference search

1. From the menu select Edit > Cross References (Querverweise) or press F11.
2. Type a fragment of the alarm text shown on the runtime (for example, "Drive fault" or the German "Antriebsstoerung").
3. ProTool will return hits in: Screens, Tags, Text Lists, Graphics Lists, Messages, and Area Pointers.
4. If the only hit is a Text List entry, the alarm is value-driven and not a configured message object. Continue to Step 3.

Step 3 - Decode the Text List

1. From the project tree, open Text Lists (Textlisten). Each list is identified by a numeric ID (1, 2, 3...).
2. Open the list referenced by the Cross Reference. The list contains one row per value: Value (DEC) | Value (HEX) | Text.
3. Identify the entry that matches the visible alarm. The corresponding value is the data word the PLC writes into the tag.
4. Open the tag editor for the tag bound to this text list. The tag address - for example DB 50.DBW 12 - is the PLC location that drives the alarm text.

Step 4 - Confirm the tag-to-PLC address path

1. From Tags > Choose, locate the tag name found in Step 3.
2. Inspect the Properties > Connection tab. The path is one of:
   • DB <n> . DBX <b> for a BOOL bit (alarm trigger)
   • DB <n> . DBW <w> for an INT / WORD (text list value)
   • M <b> / MW <w> for a flag or flag word
   • E <b> / A <b> for direct I/O
3. Cross-reference the address in STEP 7 (or TIA Portal) using Go to > Location. The PLC code that writes this address is the source of the alarm event.

Step 5 - When even the cross-reference fails

If Step 2 returns no hit at all, the alarm text is not stored in the ProTool project file. Two further locations remain:

1. Compiled language database (.ldb / .bin): The runtime may have been deployed with a separate language file. Open the .ldb with the ProTool Language Editor (Start > Programs > Siemens ProTool > Language Editor). Search for the text. If found, the message is in the language database but not in the project tree because the source .pdb never contained the object - it was added through the language editor only.
2. Project integration with STEP 7: If the project is integrated in STEP 7 (ProTool/Pro integrated in STEP 7 add-on), the message is stored in the STEP 7 project under S7 Program > Sources > ProTool Project. Open the STEP 7 project, navigate to the ProTool sub-project, and the Messages node will be populated. The original .pdb opened standalone will not show these messages because they live in the STEP 7 wrapper.

Tracing an Alarm to a PLC DB

Once the trigger tag and address are known, follow this procedure to map the alarm end-to-end.

1. Open the STEP 7 project associated with the ProTool project (same path, integration enabled).
2. Use Options > Cross References on the tag address. STEP 7 will list every network that reads or writes the address.
3. Read the network that sets the trigger bit. The condition that drives that network (limit exceeded, FB error code, communication loss) is the actual root cause of the alarm.
4. Confirm by setting the trigger manually in PLCSIM (S7-PLCSIM V5.x for STEP 7 V5.5, or PLCSIM in TIA Portal). The alarm must appear on the runtime within the configured acquisition cycle (default 1000 ms; can be 250 ms, 500 ms, 1000 ms, 2000 ms, 5000 ms, or 10000 ms).

Text/Graphics List Mechanism: The Hidden Alarm Source

Text Lists (Textliste) and Graphics Lists (Grafikliste) are the most common reason for "ghost" alarms in legacy ProTool projects. They are not messages; they are value-driven display elements. The runtime selects a text from the list based on the current value of the configured tag.

To find every Text List used as a hidden alarm:

1. Open every screen in the project. Search for "Output field" and "Symbolic I/O field" objects.
2. For each output field, open the Properties > Display tab. If "Text list" is checked, the field renders values as text list entries.
3. For each output field bound to a text list, follow Step 4 above to identify the source tag and PLC address.

This is the case the user is most likely facing: alarms displayed on a screen are not "alarm" objects, they are output fields with text list linkage.

Special Case: Alarms in Popup Windows

The source notes that alarms "appear in both variants: in message view (object) and in popup window (object)." Two interpretations are possible:

1. The popup window is an "Alarm window" (Alarmfenster) tied to the configured alarm class. In this case the alarm IS a configured message, and the Messages node should be populated. If it is empty, the project was likely saved in a non-default template and the messages are stored in a separate source file - see Step 5 above.
2. The popup window is a screen that is opened via the "go to" tag of a message, and the visible text inside the popup is itself an output field bound to a text list. This is the integration pattern used to implement "modal" alarms with rich formatting that the standard alarm view cannot display.

To disambiguate: select the popup window in the project tree, open the screen editor, and inspect every output field. If they reference a text list, the popup is a value-driven modal, not a message-driven modal.

PT_* Service Tags and Operator Prompts

The "PT_service text" tag (also documented in the ProTool V6.0 communication manual) is a runtime-reserved tag that can be written by the PLC with a string up to 256 bytes. The runtime renders the string content in any output field configured with "Display PT service text = yes". This is a documented side channel used by some integrators to display diagnostic strings pushed from the PLC without configuring any message object. The trade-off is that the text is not archived in the alarm log, not language-switchable, and not acknowledgeable.

To detect this pattern, look for output fields whose Properties > Display tab has the checkbox "PT_service_text" enabled, with no tag and no text list assignment. The PLC code that writes PT_service_text is found in the STEP 7 cross-reference of the PT service text internal address - typically DB 0.DBB 0 through DB 0.DBB 255 reserved for HMI internal services.

Recovery from a Missing .pdb

If only the compiled runtime files exist, the message texts can still be recovered, but not the message-to-tag mapping.

1. Use ProSave to back up the runtime. This produces a .psb archive containing the runtime database, language database, and any embedded project data.
2. Use ProTool > File > Retrieve > Backup to import the .psb into a fresh ProTool V6.0 SP3 session. This re-creates a .pdb with as much of the original structure as the backup preserves.
3. Message numbers and text are recovered with full fidelity. Connection and tag address data is also recovered if the project was integrated with STEP 7; otherwise the connection data is reset to the default and must be re-entered.

Tag Database Structure

Understanding the internal layout of the ProTool tag database clarifies how text-list driven alarms can exist without a Messages entry.

An output field bound to an INT tag with a text list will show different text for each possible value of the tag. The runtime updates the display whenever the tag value changes, regardless of whether any message object is defined. This is the mechanism that produces "alarms that aren't alarms".

Migrating to a Modern Toolchain

ProTool V6.0 SP3 is end-of-life since 2017. The standard migration path is ProTool V6.x → WinCC Flexible 2008 SP5 → TIA Portal V18 / V19 / V20 / V21. Two points matter for alarm handling:

1. WinCC Flexible import: Open the ProTool .pdb in WinCC Flexible 2008 SP5. The migration wizard imports configured messages (Alarm messages, Event messages, Analog alarms) faithfully. Text list-based "ghost" alarms are imported as symbolic I/O fields with text list - the engineer must manually re-link the screens, and any new text list value must be added to the receiving project's text list database.
2. TIA Portal import: Open the WinCC Flexible project in TIA Portal. The HMI tags and message objects are migrated. PLC text lists are imported as PLC data types; the TIA Portal Openness API for managing PLC text lists can be used to copy PLC text lists to a library as master copies for reuse across devices, eliminating the manual re-entry that the legacy migration otherwise requires.

For comparison with a non-Siemens HMI/SCADA platform: a FactoryTalk Alarms and Events deployment stores message texts on a central AE server (for example, the tag-based alarm server "TagAE"), separate from the HMI display application. The diagnostic path is "alarm server → tag database → controller tag" rather than the ProTool "message object → HMI tag → PLC address" path. The architectural difference is that FactoryTalk AE alarm texts are not stored in the HMI display application; they are stored once on the server and consumed by multiple clients, which removes the "text hidden in the project tree" ambiguity by design.

Performance and Acquisition Cycle

The configured cycle for area pointer acquisition directly affects whether fast PLC events become visible alarms.

Set the cycle in the connection's Properties > Area Pointers. A too-fast cycle on MPI saturates the bus; a too-slow cycle on PROFINET IO wastes available bandwidth. Match the cycle to the slowest event the operator must see within one cycle period.

Verification Checklist

Use this matrix after the diagnostic procedure to confirm the alarm chain is recovered.

Diagnostic Decision Flow

Use this decision sequence when the Messages tree is empty but the runtime shows alarms.

Field Commissioning Notes

Three operational caveats from the field that the configuration tool does not warn about.

1. Acquisition vs. display cycle: ProTool separates the tag acquisition cycle (when the HMI reads the PLC) from the display update cycle (when the screen re-renders). The two are independent. An alarm can be acquired in 250 ms but rendered with a screen-level delay of 1 s on busy screens. Validate end-to-end latency with a stopwatch during commissioning, not by inspecting the configuration.
2. Text list overflow: A text list value outside the configured range shows the default entry. The default entry is often an empty string, which appears as a blank line on the screen. Operators report "the alarm disappeared" when in fact the text list value went out of range. Always configure a non-empty default entry (e.g. "Unknown error: see PLC") when using a text list for alarm display.
3. Power-loss behaviour: ProTool/Pro RT persists the active alarm buffer to disk on a configurable interval. The default is 0 (immediate). A value of 0 combined with an unexpected IPC power loss can corrupt the alarm archive file (.alm). After any uncontrolled shutdown, validate the alarm archive integrity with Start Center > Tools > Check Alarm Archive before trusting the historical view.

FAQ