Fix HmiRuntimeSettingsData Logging Language Invalid Error on KTP400 HMI in TIA Portal

The runtime error string HmiRuntimeSettingsData: The logging language is invalid is emitted by the TIA Portal WinCC Advanced build pipeline when the language assigned to the HMI logging subsystem cannot be resolved against the project's active language list at compile time. On SIMATIC HMI Basic Panels (KTP400, KTP700, KTP900, KTP1200) this error blocks the Download to device transfer before any blocks are written and persists even after reverting the language selection in the UI. This technical reference documents the affected versions, the exact root cause at the LCID layer, three verified recovery paths, a verification procedure, a memory-budget formula for language tables, and the configuration lock-down steps that prevent the condition from recurring on regional Windows locales.

1. Problem Summary

The error appears in the TIA Portal Load preview dialog and is repeated in the Information pane of the editor:

HmiRuntimeSettingsData: The logging language is invalid.

Symptoms observed in field cases on KTP400 Basic PN (6AV2 123-2DB03-0AX0) and equivalent Comfort Panels:

• The offline compiler reports zero errors and zero warnings.
• The Download to device transfer starts, reaches the Preparing download stage, and aborts before any blocks are written.
• Reverting the HMI runtime language selection from English (South Africa) back to English (United States) does not clear the error.
• Restarting TIA Portal and rebooting the engineering station do not clear the error.
• The Online & diagnostics view shows the HMI in an inconsistent state with the project file timestamp older than the most recent compile.
• The WinCC Runtime Simulation launches but closes when the project attempts to open the logging database; the simulation exits without writing a usable runtime log.
• Password protection on PLC or HMI blocks does not affect the error; a fully password-free project still fails the download.

2. Affected Environment and Versions

Refer to the SIMATIC HMI KTP400 Basic PN Operating Instructions (entry 109767240) for the device firmware matrix and the SIMATIC HMI WinCC Engineering V17 manual (entry 109773506) for compiler behaviour.

3. Root Cause Analysis

3.1 The HmiRuntimeSettingsData block

Every TIA Portal HMI device stores a binary configuration block named HmiRuntimeSettingsData inside the device folder of the project tree. The block contains a serialized set of runtime parameters including:

• Project languages enabled at runtime
• Active language (the language the runtime displays on first power-up)
• Logging language (the language used for alarm logging, audit trail, and recipe logging)
• Date / time format
• Decimal separator
• Number of runtime languages
• Project ID and last-modified timestamp

The compiler validates this block against the language list defined under HMI device → Runtime settings → Languages & Fonts. The validation step requires the logging language field to reference a language code that exists in the project's enabled language list.

3.2 Why locale changes corrupt the language table

TIA Portal does not store language names as human-readable strings. Each language is keyed by a Win32 LCID (locale identifier). The English (South Africa) locale uses LCID 0x0435 (1077). English (United States) uses LCID 0x0409 (1033). The mapping that the compiler consults is:

When the operator changes the Windows display language in Settings → Time & Language → Language & Region, TIA Portal inherits the new locale through the Win32 MUI API. The next compile attempt reads the language list, sees that the logging language field still references the previous LCID, and flags the inconsistency as HmiRuntimeSettingsData: The logging language is invalid.

If the TIA Portal installation was performed with the English only media pack, the language pack for en-ZA is not present in the WinCC language database. The compiler cannot resolve en-ZA to any registered LCID and rejects the entire compile pass even after the operator manually switches the project back to en-US, because the cached HmiRuntimeSettingsData block on disk has not been regenerated.

3.3 Why the error is sticky

Three conditions make the error resistant to ordinary remediation:

1. Compile caches are not invalidated by a language switch. The intermediate compile cache in %LOCALAPPDATA%\Siemens\Automation\TIAPORTAL\Cache holds the old language resolution and is only flushed on a full rebuild.
2. The HmiRuntimeSettingsData block is a per-device artifact generated during the first compile after a device creation. A subsequent change to the device configuration does not regenerate the block; it is patched in place.
3. Runtime Simulation bypasses the compile cache but loads the same source project file. If the source project is intact, the simulation succeeds; if the source project has the cached language table corruption, the simulation also aborts when the logging database is opened.

4. Pre-Diagnostic Checklist

Confirm the following before applying any remediation. Capture every value for the post-remediation comparison:

1. Open the project on a clean engineering station with the same TIA Portal version and Service Pack.
2. Verify the Windows display language: Settings → Time & Language → Language → Windows display language. Note the value.
3. Verify the TIA Portal UI language: TIA Portal → Options → Settings → General → User interface language. Note the value.
4. Verify the project language configuration: Project tree → Languages & Resources → Project languages. Note the enabled list.
5. Verify the HMI runtime languages: HMI device → Runtime settings → Languages & Fonts → Active runtime languages.
6. Verify the HMI logging language: HMI device → Runtime settings → Languages & Fonts → Logging language.
7. Capture a screenshot of the Information pane error message with timestamp.
8. Save a backup copy of the project under a new name before any modification.

If steps 4 and 5 do not list the same locale as step 3, the HMI device configuration is out of sync with the project configuration. This is the most common precondition for the error.

5. Solution 1 — Compile / Rebuild All

The fastest verified recovery. Rebuild All forces the compiler to regenerate every HmiRuntimeSettingsData block, every language table, and every cross-reference from scratch. This is the procedure that the Siemens WinCC engineering team recommends as the first response to the error.

1. Close all open editor tabs in TIA Portal.
2. Right-click the HMI device in the project tree.
3. Select Compile → Rebuild all (Hardware and Software).
4. Wait for the compile to complete. The Information pane should display Compile finished. Errors: 0. Warnings: 0. If errors persist, proceed to Solution 2.
5. Right-click the PLC station and select Compile → Rebuild all (Hardware and Software).
6. Attempt the Download to device operation. The transfer should complete successfully.

If the project has multiple HMI devices, repeat step 3 for each device in dependency order (master HMI first, slave HMI second).

TIA Portal menu: Project → Compile → Rebuild all (Hardware and Software)
Keyboard shortcut: Ctrl + Shift + B

Typical rebuild duration for a single KTP400 project: 25 – 90 seconds on a workstation with an SSD. Duration scales linearly with the number of HMI tags and the number of enabled runtime languages. A project with 10 enabled languages and 5000 tags typically rebuilds in 90 – 180 seconds.

6. Solution 2 — Recreate the HMI Device

If Solution 1 fails or if the project tree shows phantom warnings after the rebuild, recreate the HMI device. This procedure is field-tested on KTP400 projects with WinCC Advanced V16 and V17.

1. In the project tree, note the Profinet device name and IP address of the existing HMI device (right-click → Properties → PROFINET interface).
2. Note the connection partner configuration for every cross-reference (PLC tag connections, area pointers, alarm routes).
3. Right-click the HMI device in the project tree and select Copy.
4. Right-click the HMI station folder and select Paste. A new device appears with the suffix _1.
5. Delete the original HMI device: right-click → Delete. Confirm the deletion of all associated DBs and connections when prompted.
6. Rename the new HMI device to match the original device name.
7. Open the PROFINET interface properties of the new device and assign the same IP address and Profinet device name as the original device.
8. Recompile the new device. The compiler regenerates HmiRuntimeSettingsData with the correct language table.
9. Run WinCC Runtime Simulation against the new device to confirm the logging database opens cleanly.
10. Download to the physical HMI.

6.1 Why this works

Deleting and recreating the HMI device forces TIA Portal to allocate a new device GUID. The cached HmiRuntimeSettingsData block from the previous device is discarded. The new device compiles against the current project language list, which now resolves correctly because the Windows locale and the project locale are aligned.

6.2 Caveats

• All screen references from the PLC to the original HMI are dropped. Re-establish them through the HMI connection table after the device is recreated.
• If the HMI used symbolic addressing to the PLC, the symbols are re-imported automatically on the first successful compile.
• Area pointers (date/time, job mailbox, coordination) must be re-mapped if they were using absolute DB addressing.
• The HMI device certificate (if HTTPS is enabled) is regenerated. Update any external HTTPS clients accordingly.
• If the original device used an HMI tag prefix, re-enter the prefix under HMI tags → Properties → Prefix after the new device is created.

7. Solution 3 — Project Archive Recovery

If both Solution 1 and Solution 2 fail — typically because the project source file itself is corrupted — recover from a TIA Portal project archive.

1. Locate the most recent project archive (.zap file). TIA Portal archives are stored at %USERPROFILE%\Documents\Automation\Projects\ by default.
2. Copy the archive to a working directory.
3. Launch TIA Portal and select Project → Retrieve. Select the .zap file.
4. Specify a new project directory. Do not overwrite the current project.
5. Allow the retrieval to complete. The recovered project has a clean language table.
6. Compare the recovered project against the corrupted project using a file-level diff. Apply any pending PLC program changes that were not yet archived.
7. Compile, simulate, and download from the recovered project.

7.1 Recovering without an archive

If no archive exists, the following manual repair can recover the project:

1. Close TIA Portal.
2. Navigate to the project directory.
3. Delete the folder <project>\System\HMI\HmiRtm.
4. Delete any files matching *.hmi_rtm in the project root.
5. Open the project in TIA Portal. The compiler will regenerate the runtime cache on the next compile.
6. Run Compile → Rebuild all (Solution 1) before attempting the download.

8. Verification Procedure

After applying any of the three solutions, verify the fix with the following checklist. Each row is a binary pass/fail check; do not sign the work off until every row is green.

9. Language Configuration Reference

9.1 Language-related properties and limits

9.2 Memory budget calculation

Each enabled runtime language consumes runtime memory for the text database and font cache. Approximate budget for KTP400 Basic PN (FW 17.x):

Memory budget formula:

Text_DB_KB = N_languages × (4 + 0.012 × N_strings)
Font_Cache_KB = 64 + (256 × N_CJK_languages)
Total_KB = Text_DB_KB + Font_Cache_KB

Where:

• N_languages = number of enabled runtime languages
• N_strings = total number of distinct text strings in the project
• N_CJK_languages = number of Chinese / Japanese / Korean languages

Example: a project with 5 runtime languages, 2000 strings, and 1 CJK language:

Text_DB_KB = 5 × (4 + 0.012 × 2000) = 5 × 28 = 140 KB
Font_Cache_KB = 64 + 256 × 1 = 320 KB
Total_KB = 140 + 320 = 460 KB

KTP400 has 4 MB of usable project memory. A 460 KB language budget leaves 3.5 MB for screens, tags, and alarms. Plan accordingly.

10. Preventive Best Practices

1. Lock the Windows display language on every engineering station that opens TIA Portal projects. Use intl.cpl to verify. Document the locale in the project README.
2. Disable the option “Let Windows update the runtime language list automatically” in TIA Portal: Options → Settings → General → User interface language → “Use Windows display language”. Clear this checkbox.
3. Standardize the TIA Portal UI language across the engineering team. Mixed UI languages on a shared project cause inconsistent compile artifacts.
4. Enable automatic project archiving under Options → Settings → General → Archive settings. Set the archive interval to the smallest acceptable value (daily for production, weekly for development).
5. Document the logging language in the project specification. Treat it as a contract that requires explicit change-control.
6. Verify the HmiRuntimeSettingsData block after any TIA Portal Service Pack update. SP updates can invalidate cached language tables.
7. Run the WinCC Runtime Simulation as a smoke test after every compile. A simulation that opens the logging database cleanly is the strongest single signal that the HmiRuntimeSettingsData block is valid.
8. Pin the project locale in the project file by opening the .ap16 / .ap17 archive and inspecting the ProjectSettings.xml entry <DefaultLanguage>. The value should match the engineering station locale.
9. Validate after any firmware update on the physical KTP400. A firmware upgrade can require a re-bind of the language table; trigger a Rebuild All before the first download after a firmware change.

11. Related Errors and Diagnostic Matrix

12. Frequently Asked Questions