Resolving WinCC V7.2 Alarm Logging Message Text Update Failures

Problem Description

When updating message texts in a WinCC V7.2 Alarm Logging project—typically by importing a freshly prepared text file saved from Microsoft Excel 2010 in MS-DOS text format—the new strings do not replace the existing ones. The Alarm Logging editor continues to display the previous text even after deleting all messages, saving, closing, and re-importing, or after exporting the existing messages, editing them externally, and re-importing. The condition can be reproduced with the WinCC Runtime fully stopped, and it is independent of how the project was originally authored. Legacy projects that pre-date WinCC V7.2 follow the same behavior, because the Alarm Logging data model in V7.2 inherits the same text-identifier handling as V7.0 and V7.1.

Common triggers observed in the field include:

• Re-importing a CSV/TXT export that retains a populated TextID column. WinCC interprets the row as a duplicate keyed on the existing internal identifier and silently skips it.
• Mixing file encodings: MS-DOS Text (CP-1252/CP-850) versus Unicode (UTF-16 LE BOM) versus UTF-8. WinCC V7.2 expects Unicode Text for the Text Distributor and a defined codepage for the single-message import. Mismatched encoding can cause the import to drop rows without raising an error.
• Performing only an import without first deleting or explicitly overwriting rows. The "Import single messages" function has a non-destructive mode that appends or skips rows based on the text identifier.
• Projects with multiple runtime languages where the imported file only contains one language and the other languages are silently kept from the prior text library.

The practical impact is that mass text updates across hundreds of messages become impossible to perform reliably, forcing engineers to edit each message row manually inside the editor.

Root Cause Analysis

The Alarm Logging editor in WinCC V7.2 does not key message rows on a user-visible text field. It keys them on an internal text identification number (TextID) that is generated when the row is first created or imported. When the import function reads a file, the behavior is governed by the TextID column and by the import mode selected in the dialog:

1. Append / skip mode (default): If the TextID is present and matches an existing row, WinCC treats the imported row as a duplicate and skips it. The text content of the existing row is unchanged.
2. Overwrite mode: If the TextID is present and matches, WinCC overwrites the existing row. The standard export file generated by Alarm Logging always populates the TextID with the project's internal value, so the matching key is already in place—this is the intended path for in-place text replacement.
3. TextID = 0 mode: If the TextID is forced to zero (the "Set text identification to 0" export option), WinCC treats the imported row as a text replacement keyed on the message number alone. This is the path used when the source of truth is an external Excel workbook that does not (and should not) carry WinCC-internal IDs.

The Microsoft Excel "Save as Text (MS-DOS)" command writes CP-1252 or CP-850 encoded text. WinCC V7.2 expects Unicode (UTF-16 LE with BOM) for the Text Distributor and a defined codepage for the single-message import. Mismatched encoding can cause the import to silently discard rows. The end result is that the imported file "succeeds" because no errors are emitted, but the Alarm Logging table is never updated—or is updated only partially, with the rows that contained characters outside the source codepage being dropped.

Refer to the SIMATIC WinCC V7.2 documentation set on the Siemens Industry Online Support portal for the canonical explanation and the file format specification. The relevant chapter is the "Alarm Logging" section of the WinCC V7.2 Information System, which documents the import/export file layout and the behavior of the TextID column.

Solution Path A: Alarm Logging Editor Export/Import with TextID Reset

This is the canonical two-step workflow when the intent is to replace the texts of existing messages without creating new message numbers. It applies when the message tags, message numbers, message classes, and message priorities are already correct and only the human-readable text needs to change.

Prerequisites:

• WinCC V7.2 (any service pack) project, opened in the WinCC Explorer with full write access.
• WinCC Runtime stopped (recommended but not strictly required for editor changes; required for archive-related steps).
• Alarm Logging is editable: the project is not write-protected, no other user has the project open, and the WinCC Explorer is running with administrative rights on the project folder.
• A backup of the project folder has been taken before any destructive step.

Procedure:

1. Open the WinCC Explorer and double-click Alarm Logging in the left-hand navigation tree.
2. In the table view, choose Messages → Export single messages from the menu bar. WinCC prompts for a target file path and shows the export options dialog.
3. In the export options dialog, enable Set text identification to 0. This is the critical option—it forces every exported row to carry TextID = 0, which signals the import function that this row represents a text replacement rather than a row update keyed on the existing TextID.
4. Choose the file format (CSV with semicolon delimiter is the default for German and most European locales; tab-delimited is the default for English and US locales) and click OK. The file is written to the path you selected.
5. Open the exported file in Microsoft Excel or any text editor. Replace the text columns with the new message strings. Save the file. If you use Notepad, save as Unicode Text. If you keep it in Excel and save as Text (MS-DOS), you must verify that special characters (umlauts, ß, é, ñ, etc.) survive the round-trip without mojibake.
6. Return to the Alarm Logging editor and choose Messages → Import single messages. Select the file you just edited.
7. In the import dialog, perform the steps in this exact order:
   1. Click Delete Messages with the file loaded. This removes the matched rows based on the message number. WinCC confirms the number of rows to be deleted before committing.
   2. Click Overwrite Messages (the exact label varies by service pack—it may be "Import/Overwrite" or "Overwrite existing messages"). This re-creates the rows with the new text from the file, assigning fresh TextIDs.
8. Click OK to commit. The Alarm Logging editor refreshes and the new texts appear in the table.
9. Save the project (Ctrl+S or the "Save" toolbar button). If the runtime was running when you made the changes, the Alarm Logging service picks up the updated configuration on the next start or on an explicit reconfiguration command.

Solution Path B: Text Distributor for Text-Only Changes

When the project is multilingual and the goal is to change the visible text without disturbing the message structure, the Text Distributor tool is the recommended approach. It is the only flow in WinCC V7.2 that updates the Text Library entries without rewriting the Alarm Logging table itself. The Text Distributor is invoked from the WinCC Explorer under the project tree.

Prerequisites:

• WinCC V7.2 project with one or more runtime languages installed in the Text Library (configured under Project Properties → Runtime Language).
• Runtime stopped or scheduled for reconfiguration immediately after the import.
• Microsoft Excel (any version 2007 or later) or a Unicode-aware text editor that can save UTF-16 LE with BOM.

Procedure:

1. Open the WinCC Explorer and double-click Text Distributor. In older V7.2 project templates the entry is under "Language & Resources"; in newer project templates it is directly under the project root.
2. In the Text Distributor wizard, select Export from current project and choose Alarm Logging as the only category to export. Selecting other categories (Graphics Designer, Tag Logging, Report Designer, etc.) exports their texts as well and is usually not desired for a focused change.
3. Choose Export to file, select a path, and complete the wizard. The output is a tab-separated Unicode text file (.txt) with one column per runtime language plus the TextID column.
4. Open the file in Microsoft Excel. Edit only the text columns for the languages you need to change. Do not modify the internal ID columns or the message number columns—these are used as the import key and changing them creates new messages instead of updating existing ones.
5. Save the file as Unicode Text (.txt) with the encoding UTF-16 LE. This is the only encoding the Text Distributor accepts on re-import. Saving as CSV, UTF-8, or MS-DOS text causes the import to fail outright or to drop rows without surfacing an error.
6. Reopen the Text Distributor, this time with Import into current project, again limiting the scope to Alarm Logging. Point the wizard at the file you saved.
7. Click Import and review the import log. The Text Distributor reports the number of texts imported per language and any rows that were rejected (typically due to encoding errors, length overflow, or a missing language code in the header).

The Text Distributor preserves the text identification numbers internally—it generates new TextIDs for the updated rows and rewrites the references in the Alarm Logging table. This is why the editor immediately shows the new text after a successful import, even though the underlying Text Library entries are different objects than before. The benefit of the Text Distributor flow over the Alarm Logging import flow is that the file is a flat language matrix, which is more natural to maintain in Excel for projects with many languages.

Multi-Language Project Handling

WinCC V7.2 supports up to 32 runtime languages per project. Each message can carry a separate text in each language. The texts are stored in the project's Text Library—both as <project>_<language>.txt files in the project folder and as rows in the internal TextLibrary SQL table that is part of the project database (<projectname>.mdf). When you import a single-language file via "Import single messages", WinCC only updates the language that the file specifies (typically the language the editor was opened in); the other languages retain their previous texts.

Table: Language handling by import tool

For a project with German, English, and French runtime languages, the typical workflow is to run the Text Distributor export/import three times (once per language file), or to build a single multi-column file with one column per language and import it once. The latter is faster but requires careful column ordering: the Text Distributor's expected column order is <Language 1> <Language 2> ... <Language N> <TextID>.

Archive Database Reset Procedure

When the WinCC Runtime has been active and alarms have been archived, the displayed message texts in archive views (Alarm Control, archives of the Alarm Logging, exported CSVs from the alarm archive) come from a separate copy of the texts. This copy lives in two SQL Server files in the WinCC project folder:

• <projectname>Alg.mdf — the SQL Server primary data file for the Alarm Logging archive.
• <projectname>Alg.ldf — the SQL Server transaction log file for the Alarm Logging archive.

The default project folder is C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<projectname>\. If you change texts in the Alarm Logging editor while the runtime is active, new alarm events use the new texts, but historical events continue to show the old text because they were stored with the old text string at the time the event was raised. To force a complete refresh of the archive contents:

1. Stop the WinCC Runtime (right-click the WinCC Explorer systray icon → Stop Runtime, or run WinCC_RT.exe /deactivate from the Windows command line, or use the standard DeactivateRuntime VBScript function).
2. Close WinCC Explorer and any open WinCC clients (Graphics Designer, Tag Logging, Alarm Control).
3. In Windows Explorer, navigate to the project folder.
4. Delete the files <projectname>Alg.mdf and <projectname>Alg.ldf. Do not delete the <projectname>.mdf and <projectname>.ldf files—those are the project database (configuration data), not the alarm archive.
5. Restart the WinCC Runtime. WinCC recreates the archive files with an empty contents table; the schema and the text library references are recreated from the live project database on first archive write.

For projects running WinCC V7.2 with the redundant option or with a separate archive server, the archive files may reside on the archive server's local drive. The path is configured under Computer → Archive Configuration in the WinCC Explorer. The reset procedure is the same, but the deletion must be performed on the archive server, not on the WinCC server.

File Encoding, Delimiters, and Column Layout

The two import tools in WinCC V7.2 expect different file layouts. Mixing them is the most common cause of the "import succeeded but text did not change" symptom.

Table: Import tool file requirements

A reference template for the "Import single messages" file (semicolon-delimited, with header):

Number;Class;Type;TextID;Text_EN
1001;1;1;0;Pump 1 running
1002;1;1;0;Pump 1 stopped
1003;1;2;0;High temperature in tank 1
1004;2;3;0;Tank 1 level low

A reference template for the Text Distributor file (tab-delimited, German + English):

Reference	GermanText	EnglishText	TextID
ALG_1001	Pumpe 1 läuft	Pump 1 running	0
ALG_1002	Pumpe 1 gestoppt	Pump 1 stopped	0
ALG_1003	Hochtemperatur Tank 1	High temperature in tank 1	0
ALG_1004	Füllstand Tank 1 niedrig	Tank 1 level low	0

The exact column names in the header are language-dependent. WinCC V7.2 matches them by position and by the language codes configured in the project, not by the literal string. The TextID column is write-protected on import—WinCC assigns new IDs and ignores the values in the file.

Encoding reference for common national characters in WinCC V7.2:

If the text file was saved as UTF-8 and WinCC reads it as ANSI, the multi-byte UTF-8 sequences are misinterpreted as Latin-1 characters and the message text shows up as mojibake ("Pumpe 1 läuft" instead of "Pumpe 1 läuft"). The fix is to re-save the file as UTF-16 LE and re-import.

Verification Procedure

After performing either Solution Path A or B, validate the change with the following checks. The goal is to confirm both the editor state and the runtime state—a successful editor import does not guarantee a successful runtime display.

1. Editor check: Open Alarm Logging, scroll to a sample of 10 messages from different classes. Verify the text matches the imported file exactly, including leading/trailing spaces, special characters, and the configured message priority.
2. Text Library check: In the WinCC Explorer, open the Text Library and filter by "Alarm Logging". Confirm that the language entries for the sample messages are present, that the new TextIDs are valid (non-zero, unique), and that no orphan entries (TextIDs with no referencing message) were created.
3. Runtime simulation check: Activate the project (right-click the project root in the WinCC Explorer → Activate). Open a graphics picture that contains an Alarm Control (typically the standard @AlarmControl.pdl or a project-specific picture). Trigger a sample alarm—for example, toggle a process tag in the tag simulator that triggers message number 1001. Verify that the message appears in the Alarm Control with the new text, the configured priority, and the configured acknowledgment requirement.
4. Multi-language check: If the project has more than one runtime language, switch the runtime language (via the project's language switch button or the @Language switch picture). Re-trigger the alarm and confirm the new text appears in the target language. Pay special attention to languages with non-Latin scripts (Chinese, Japanese, Korean, Cyrillic), which require UTF-16 throughout the pipeline.
5. Archive check: Wait for the new alarm to be archived (the default cycle is 500 ms; configurable in the Alarm Logging archive settings). Open the Alarm Control's archive view (right-click → Archive → Show). Confirm that the archived message shows the new text. If it shows the old text, the archive database reset procedure (see above) is required.
6. Client check (for distributed projects): If the project uses WinCC clients, log in to at least one client and verify the message text in its Alarm Control. Clients cache the alarm configuration; the cache is refreshed on the next reconfiguration cycle or on a manual cache reset (right-click the client computer → Configuration → Reset cache).

If any of the above steps show the old text, the import did not commit properly. The most likely causes, in order of frequency, are:

1. TextID in the import file was non-zero, causing the import to skip the row.
2. The file was saved in the wrong encoding, causing WinCC to silently reject rows with non-ASCII characters.
3. The runtime is referencing a cached copy of the alarm configuration. Restart the runtime (or the affected client) to force a reload.
4. The project was opened in read-only mode (network share with read-only access, DFV-encrypted volume mounted read-only, or another engineer has the project open in exclusive mode).

Common Pitfalls and Edge Cases

The following failure modes are observed in field deployments of WinCC V7.2 with the same root cause (text identification handling) and should be checked first when the symptom is "text not updating after import":

Table: Pitfalls and resolutions

For multi-engineer teams, the recommended practice is to maintain the message texts in a version-controlled Excel workbook and run a scripted export to the WinCC import format. The workbook is the single source of truth, and the Alarm Logging editor is a derivation. This avoids the "who changed what" problem in legacy projects where the source of the message text is unclear. A VBScript macro in Excel can generate the import file directly from a worksheet, with the TextID column set to zero by construction.

Scripted Automation with VBScript

For projects with hundreds or thousands of messages, manual export/import cycles become impractical. WinCC V7.2 supports programmatic access to the Alarm Logging via the HMIRuntime and Alarm COM objects. A typical automation script reads an Excel workbook, builds a tab-separated import file in memory, and triggers the import via the Alarm Logging's automation interface.

Reference pattern (to be adapted to the specific project structure and message classes):

' VBScript snippet - to be hosted in WinCC Explorer as a project function
Sub UpdateAlarmTextsFromExcel(sExcelPath As String, sSheetName As String)
    Dim oExcel, oBook, oSheet, oCell
    Dim sImportFile, sLine, sNumber, sText
    Dim fso, ts
    
    Set oExcel = CreateObject("Excel.Application")
    oExcel.Visible = False
    Set oBook = oExcel.Workbooks.Open(sExcelPath)
    Set oSheet = oBook.Sheets(sSheetName)
    
    ' Build tab-separated import file with TextID = 0
    sImportFile = "C:\Temp\AlarmImport.txt"
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set ts = fso.CreateTextFile(sImportFile, True, True) ' Unicode
    
    ts.WriteLine "Number" & vbTab & "Class" & vbTab & "Type" & vbTab & "TextID" & vbTab & "Text"
    
    Dim i As Long
    i = 2 ' skip header row
    Do While oSheet.Cells(i, 1).Value <> ""
        sNumber = CStr(oSheet.Cells(i, 1).Value)
        sText = CStr(oSheet.Cells(i, 2).Value)
        sLine = sNumber & vbTab & "1" & vbTab & "1" & vbTab & "0" & vbTab & sText
        ts.WriteLine sLine
        i = i + 1
    Loop
    
    ts.Close
    oBook.Close False
    oExcel.Quit
    
    ' Trigger the Alarm Logging import via the project function
    ImportAlarmMessages sImportFile
End Sub

The ImportAlarmMessages helper invokes the Alarm Logging editor's "Import single messages" function via the AlarmLogging OLE object. The exact object name and method signature depend on the WinCC V7.2 service pack; refer to the WinCC Information System chapter on "VBScript for Alarm Logging" for the current API.

Cross-Version Compatibility Notes

The export/import mechanism documented here applies to WinCC V7.0, V7.2, V7.3, V7.4, and V7.5 with the following caveats:

• In WinCC V7.3 and later, the option label changed from "Set text identification to 0" to "Reset text identification". The behavior is identical—the exported rows carry TextID = 0 and the import is treated as a text replacement.
• In WinCC V7.4 and later, the Text Distributor can also export to a SQL Server-staged file (CSV-UTF8 with BOM), which simplifies the round-trip through Excel and reduces encoding errors. The legacy tab-separated Unicode file is still supported for backward compatibility.
• In WinCC V7.5, the Alarm Logging editor was moved to a tabbed view in the WinCC Explorer, but the menu path Messages → Export single messages remains available and behaves identically.
• TIA Portal WinCC Professional uses a different import workflow (CSV with a defined schema, no TextID concept). Projects migrated from WinCC V7.x to TIA Portal need to be re-imported with the TIA tool, not with the V7 export/import. The Siemens migration tool "SIMATIC WinCC Migrator" handles the one-time conversion of the message database.
• WinCC Unified (TIA Portal) uses a different alarm model based on the "Alarm" and "Logged alarm" data types, with texts stored in the PLC or in the HMI's multi-language text tables. The V7.x export/import workflow does not apply.

For projects that need to be supported on both V7.2 and a newer runtime, the recommended approach is to perform the export/import in V7.2 (where the source data lives) and then re-save the project in the newer version. The new version reads the V7.2 import format without conversion. For projects migrating to TIA Portal, use the official Siemens migration tooling rather than attempting to reuse the V7 export files—the schema differences (especially around the message class and priority encoding) are not handled by a simple import.

FAQ