Resolving WinCC Flexible "No Unique Name for Object" Compiler Warnings

The WinCC Flexible 2005 engineering system (ES) introduces a strict object-name uniqueness check that did not exist in WinCC Flexible 2004. Projects migrated from 2004, or projects that have undergone extensive copy/paste operations, template revisions, or screen duplications, generate hundreds of warnings of the form:

The warnings are cosmetic at runtime (the project loads, runs, and the screens display correctly), but they clutter the build log, obscure real errors, and signal an inconsistency in the compiler's internal name index. The standard, supported fix is the Project → Compiler → Rebuild All command. The procedure, the underlying root cause, and the long-term prevention measures are covered in detail below.

Problem Details

After migrating a project from WinCC Flexible 2004 to 2005, the first incremental build produces a high warning count, often 100–400 entries for a mid-sized process project (300–500 HMI tags, 40–80 screens, multiple template-derived objects). A representative example is a thickener feed pump faceplate project with 12 pump instances, each using the same template:

The warning repeats for every screen that contains a template instance with a duplicated base name. The 2004 build engine tolerated the duplication silently. The 2005 engine enforces the uniqueness rule and reports the violation. The project does not fail to compile (the build completes with success status), but the warning list is dominated by these entries, making it difficult to identify real errors.

Warning Code Format Breakdown

Affected Versions and Configurations

The issue is independent of the target HMI device. It has been reproduced on OP 73, OP 77A, OP 77B, TP 170A, TP 170B, TP 177A, TP 177B, OP 177B, TP 270, MP 270B, MP 370, MP 377, and PC Runtime targets. The problem is purely a compile-time condition in the engineering system.

Root Cause Analysis

The root cause is a mismatch between the WinCC Flexible 2004 object model and the 2005 strict naming check. Three contributing factors are consistently observed in field reports:

1. Stale Cross-Reference Data from the 2004 Build

When a 2004 project is opened in 2005, the 2004-compiled object registry is read as the starting point. Incremental builds in 2005 use this registry as the baseline. If two template-derived objects shared a base name in 2004 (which 2004 allowed), the 2005 build engine flags the pair as non-unique on the next change-driven compile. The data is not "wrong" in 2004 semantics, but it violates the 2005 invariant.

2. Copy/Paste Duplication of Graphic Objects

Copying a faceplate or a control from one screen to another in the Graphics Designer, then renaming only the visible label (Anzeige) but not the underlying object name (Name property in the property view), creates two objects with the same internal identifier. WinCC Flexible 2004 tolerated this; 2005 reports it.

3. Template Revision Without Rebuild All

Editing a screen template (Vorlage) and then saving the dependent screens triggers a partial compile. The partial compile updates instance data (positions, properties, animations) but does not always regenerate the master name index. The compiler reports the warnings during the next full project load or change-driven compile. This is the most common cause of the warning reappearing after an initial Rebuild All clears it.

4. Imported Graphics Libraries with Pre-Assigned Object Names

Third-party or vendor-supplied graphics libraries (Siemens WinCC Flexible faceplate libraries, vendor pump and valve faceplates) often include objects with hard-coded `OBJECT_n` names. When two libraries are imported into the same project, or when the same library is imported twice, the object names collide. The 2005 compiler flags the collision; the 2004 compiler did not.

Solution: Rebuild All

The supported fix is to force a complete regeneration of the compiler's object registry using Project → Compiler → Rebuild All. The German menu path is Projekt → Übersetzen → Alles neu erstellen.

Step-by-Step Procedure

1. Close any open screen editors in WinCC Flexible 2005 to prevent file locks during the rebuild.
2. In the project tree, right-click the project node (the root entry that displays the project name).
3. Select Compiler → Rebuild All from the context menu. The shortcut is unavailable by default; the menu is the only entry point.
4. A dialog box titled Rebuild All appears, listing the project components: Screens, Tags, Messages, Recipes, Scripts, Alarms, Logs, and User Administration.
5. Click Start to begin the rebuild. A progress bar shows the current component being processed.
6. When the rebuild completes, the dialog displays a summary. Click Close.
7. Open the Results window from the menu View → Results or by pressing Ctrl+Shift+O.
8. Verify the warning count. A correctly rebuilt project should show zero W16:31:33.11 warnings.
9. Save the project with Project → Save (Ctrl+S). The save persists the regenerated registry.
10. Subsequent incremental compiles should remain clean unless new copy/paste or template-edit operations reintroduce the condition.

Expected Rebuild Times by Project Size

The rebuild is CPU-bound. Disk I/O and RAM are secondary factors. A modern Windows 10/11 workstation with an SSD will complete a large rebuild in 8–15 minutes; a Windows XP-era workstation with a mechanical disk may take 20–40 minutes for the same project.

Why Rebuild All Works

Incremental compilation compares the current project state against the last-compiled state and recompiles only the changed components. The object name index, however, is a project-wide table. When the index is corrupted or out of date, incremental compilation cannot resolve it because the comparison algorithm does not detect name-table corruption — it only detects source-file changes. Rebuild All discards the existing index and regenerates it from the project source. The new index reflects the actual object hierarchy as WinCC Flexible 2005 expects it, satisfying the unique-name invariant.

Alternative Workarounds

If Rebuild All is not feasible (rebuild time blocks a production deadline, the workstation is shared with a live operator, or the project must remain in service), the following manual workarounds can be applied. They are slower and riskier than Rebuild All, but they are valid for small warning counts.

Manual Object Renumbering

For each W16:31:33.11 warning:

1. Double-click the warning in the Results window. WinCC Flexible opens the relevant screen and selects the offending object.
2. Right-click the object → Properties. The property view opens in the right pane.
3. Click the Name field in the General tab.
4. Append a unique suffix to the name (e.g., `OBJECT_2` becomes `OBJECT_2_Pump1`, `OBJECT_2_Pump2` for the second instance).
5. Press Enter to commit the change.
6. Save the screen (Ctrl+S).
7. Move to the next warning and repeat.

With 350 warnings, this procedure takes 2–4 hours of focused work. It is not recommended for projects with more than 50 warnings. The risk is introducing further naming inconsistencies if the engineer is not familiar with the project structure.

Project Copy with Clean Rebuild

If the warnings persist after multiple Rebuild All cycles (rare, but reported in projects with deeply nested template inheritance):

1. Use Project → Save As to create a copy of the project. The new file is a clean copy of the corrupted project.
2. Open the copy. The open operation triggers a full load of all project data.
3. Run Rebuild All on the copy.
4. Verify the copy is clean. Continue development on the copy.
5. Discard the original project file once the copy is confirmed clean.

Template Cleanup

If the warnings concentrate on screens that share a common template:

1. Open the template (Vorlage) in the Graphics Designer. Templates are stored under Project → Templates in the project tree.
2. Click each graphic object and check the Name property in the property view.
3. Ensure no two objects share the same Name. If duplicates are found, rename the duplicate using a role-based convention (e.g., `Btn_PumpStart`, `Btn_PumpStop`, `Ind_PumpRunning`).
4. Enable the "Use instance name" property for objects that should receive a screen-level suffix on instantiation. The option is in the property view under General → Miscellaneous → Use instance name = Yes.
5. Save the template.
6. Open each dependent screen and re-link any references that were broken by the rename.
7. Run Rebuild All.

Object Naming Best Practices

To prevent the warning from recurring, follow these naming conventions in the Graphics Designer. The convention applies to the internal object Name property, not the visible label or text.

The sequencing suffix (`_01`, `_02`) provides a deterministic, compiler-friendly unique name. The default `OBJECT_n` placeholder should be treated as a temporary name. Always assign a meaningful name before saving the screen. This is documented in the Siemens WinCC Flexible engineering manual under the Graphics Designer reference.

Template vs Instance Behavior

WinCC Flexible templates (Vorlagen) are reusable screen fragments stored in the project tree. When a template is instantiated on a screen, the instance inherits the template's object names. The compiler expects the instance to receive a unique name suffix; the suffix is the screen-level identifier that distinguishes one instance from another. The instance name is set in the Instance Name field of the template properties dialog.

Common failure modes:

Missing Instance Suffix

The instance is inserted but the "Use instance name" option is disabled in the template's property view. The object is named identically to the template's source object on every screen. With 12 pump instances, the compiler sees 12 objects named `OBJECT_2` and reports 11 duplicates.

Conflicting Manual Name

The user manually renames an instance to a name that already exists elsewhere in the same screen. For example, two I/O fields are both renamed to `IO_Flow_SP` because the engineer intended them for the same tag. The compiler sees a duplicate and reports the warning.

Template Change Propagation Failure

The template is updated (e.g., a new button is added), but some dependent screens are not refreshed before the next compile. The screen still contains the old instance structure, which may have a name conflict with the new template structure. The fix is to re-link the affected screens: open the screen, delete the old instance, re-drag the template from the project tree, and re-link the tags.

Enabling "Use instance name = Yes" in the template's property view forces the compiler to apply the screen-level instance name as a suffix, eliminating the most common source of duplicate-name warnings.

Migration from WinCC Flexible 2004 to 2005

Projects migrated from 2004 should follow this sequence. Skipping the Rebuild All step is the most common cause of unresolved warning counts after migration.

1. Backup the 2004 project before opening it in 2005. The migration is one-way; once saved in 2005, the project cannot be opened in 2004. Store the backup on a separate physical drive or removable media.
2. Open the project in 2005. WinCC Flexible 2005 detects the 2004 format and performs an automatic migration. The migration is logged to a text file in the project directory; review the log for any "data lost" or "object skipped" entries.
3. Do not edit the project before the first Rebuild All. The first action after migration should be Project → Compiler → Rebuild All. Editing before the rebuild risks introducing further name conflicts on top of the migration-induced ones.
4. Save the migrated project with a versioned file name (e.g., `Project_2005_Migrated.hmi`) to distinguish it from the original 2004 backup.
5. Verify the Results window is clean before beginning new development. The expected count is zero W16:31:33.11 warnings.
6. Apply the same Rebuild All after any large change set (more than 20 screens modified, more than 50 object properties changed, or any template revision).

Verification Procedure

After applying the Rebuild All fix, verify the result with the following steps before declaring the issue resolved.

1. Open View → Results (or press Ctrl+Shift+O).
2. Confirm the warning list contains zero W16:31:33.11 entries.
3. If the Results window still shows warnings, perform a second Rebuild All. Two consecutive Rebuild All cycles with zero warnings indicate a stable state.
4. Simulate the project: Project → Start Runtime (or click the simulator button on the toolbar). Verify all screens display correctly, all template instances render, all animations execute, and all tag values update.
5. If a target HMI device is available, transfer the project via Project → Transfer → Transfer to Device. The transfer medium depends on the panel: Ethernet for TP/OP 177B and higher, MPI or PROFIBUS for older panels, USB for most modern panels.
6. Confirm the panel boots into the main screen without a "Project data inconsistent" alarm. This alarm indicates the project file on the panel is out of sync with the engineering project; a clean transfer should clear it.
7. Re-open the project, modify a single tag, save, and recompile. The incremental compile should produce zero warnings. If the incremental compile produces new warnings, the template or copy/paste hygiene of the modified screen is the likely cause.

Related Compiler Warnings

The W16:31:33.11 warning often appears alongside the following warnings and errors. Resolving the unique-name issue via Rebuild All typically clears the secondary warnings as well, because the secondary warnings are also caused by stale name indices.

A complete run-down of error codes is available in the WinCC Flexible documentation under Help → Contents → Reference → Error Messages. The same code list applies to WinCC Flexible 2007 and 2008. The Siemens Industry Online Support portal maintains an updated list of error codes and resolutions for the TIA Portal generation of WinCC.

Project Hygiene Best Practices

Long-term prevention of the warning requires disciplined project hygiene. The following practices have been validated in operational plants running WinCC Flexible 2005 SP3 and later.

1. Establish a naming standard before the first screen is created. Document the convention in the project README and enforce it in code reviews. The standard should specify the prefix conventions, sequencing rules, and the role of the "Use instance name" property.
2. Avoid copy/paste of graphic objects between screens when a template can be used instead. Templates are designed for reuse; copy/paste is the primary source of name conflicts. When copy/paste is unavoidable, immediately rename the pasted object before saving the screen.
3. Run Rebuild All after every milestone: project handover, major template revision, panel firmware upgrade, integration with a new PLC type, and before any production transfer. The rebuild is non-destructive; running it more often than needed has no downside.
4. Maintain a project backup rotation — at least three generations. The Rebuild All process is non-destructive, but a corrupted project file can force a recovery from backup. Store backups on a separate physical drive and label them with the project version and date.
5. Limit concurrent developers. WinCC Flexible 2005 does not support multi-developer source control in the way that TIA Portal does. Concurrent edits to the same `.hmi` file by two engineers can introduce name-table corruption. Use a check-out / check-in procedure on a shared network drive, or split the project by panel and merge carefully.
6. Avoid renaming objects in the Graphics Designer when the object is referenced by an event or a script. Renaming breaks the reference. The compiler reports the broken reference as a secondary warning (W16:31:34.05). When renaming is necessary, update all event handlers and script references in the same edit session.
7. Validate after every template change. After editing a template, open at least one dependent screen and re-link any broken references. Run Rebuild All before transferring the project to the target panel.
8. Use a separate template library project for reusable faceplates. Import the library into consuming projects rather than copying faceplate screens between projects. This isolates library version control and prevents name conflicts between library instances.

When Rebuild All Does Not Help

In rare cases (approximately 2–5% of reported field issues), Rebuild All does not clear the warnings. The typical causes and the resolution paths are listed below.

Corrupted .hmi Project File

A disk write error during save, a network file share timeout, or a power loss during save can corrupt the project container. The container is a binary file with internal cross-references. The corruption may not be visible in the project tree, but the compiler's name index is unreadable. The fix is to use Project → Save As to create a fresh project file. The new file is structurally clean because WinCC Flexible rewrites the container from the in-memory project representation. The old file should be archived and discarded after the new file is verified.

External Script References

VB scripts that reference objects by hard-coded `OBJECT_n` name can force the compiler to keep the duplicate name. The compiler must preserve the script's reference target. The fix is to update the scripts to use the new names after manual renumbering. Open each script in the script editor (Project → Scripts), find the `HmiRuntime.Screens("ScreenName").ScreenItems("OBJECT_2")` call, and replace `OBJECT_2` with the renamed object name.

Imported Graphics Library

A third-party graphics library may include objects with the same internal name as another library, or as the base project. The Rebuild All process does not rename objects in imported libraries; it only rebuilds the index for the current project. The fix is to contact the library vendor for a fixed version, or to use only one library that contains the required faceplates.

Multiple Project Copies Merged Manually

Merging two WinCC Flexible projects by copying screens between them is unsupported. The merged project must undergo Rebuild All, and the Rebuild may not resolve conflicts if the project structure is inconsistent (e.g., two screens with the same internal ID, two tag tables with the same tag name). The fix is to extract the affected screens, recreate them in a clean project, and re-link the tags, scripts, and animations.

Diagnostic Checklist

Use this checklist to systematically diagnose and resolve the warning in any WinCC Flexible 2005 (or later) project.

1. Confirm the project is in WinCC Flexible 2005 or a later 2005 SP.
2. Open the Results window (Ctrl+Shift+O).
3. Count the W16:31:33.11 warnings.
4. Run Project → Compiler → Rebuild All.
5. Recount the warnings. If zero, save and continue.
6. If warnings persist, double-click each warning, identify the screen and object.
7. Verify the screen uses a template. If yes, open the template and check object names.
8. Rename duplicate objects in the template or in the instance, applying the naming convention from the Best Practices table above.
9. Repeat the Rebuild All.
10. If warnings still persist, save the project to a new file (Project → Save As) and reopen.
11. Run Rebuild All on the new file.
12. If the issue remains, isolate the affected screen by deleting it from the project and rebuilding. If the warnings disappear, the deleted screen is the source. Re-create the screen from the template.
13. If the issue remains after screen isolation, inspect imported graphics libraries for internal name conflicts.
14. Document the resolution in the project change log. Include the warning count before and after the fix, the rebuild duration, and any manual renames performed.

Integration with STEP 7 and PLCSIM

Projects that integrate WinCC Flexible with STEP 7 (for S7-300 / S7-400 PLCs) or with the TIA Portal (for S7-1200 / S7-1500 PLCs) require additional consideration. The tag database in WinCC Flexible is linked to the STEP 7 symbol table. When a tag is renamed in STEP 7, the link in WinCC Flexible is broken, and the compiler reports a secondary warning. The Rebuild All process does not fix the tag link; the link must be re-established by opening the tag editor and re-pointing the WinCC tag to the renamed STEP 7 symbol.

For projects using PLCSIM (the S7-PLCSIM simulator) for offline testing, the Rebuild All must be run with the PLCSIM connection active. If PLCSIM is not running, the compiler reports a connection error (E16:31:42.10) and may abort the rebuild. The fix is to start PLCSIM, establish the connection, and re-run the Rebuild All.

Transfer Considerations

After a successful Rebuild All, the project is ready for transfer to the target HMI device. The transfer process does not depend on the rebuild state, but transferring a project that contains unresolved W16:31:33.11 warnings is not recommended because the warnings indicate an internal inconsistency that may surface as a runtime error on the panel (typically "Project data inconsistent" or a similar alarm).

Performance Impact of the Warning

The warning itself has no runtime performance impact. The build process takes longer when the warning count is high (the compiler must format and log each warning), but the runtime project file is the same size whether 0 or 400 warnings are present. The only performance impact is on the engineer's review time: a 400-warning build log is difficult to scan for real errors.

Resolving the warning does not reduce the project file size, does not change the runtime behavior, and does not affect the transfer time. The only benefit is a clean build log that makes future troubleshooting faster.

Summary

The W16:31:33.11 "No unique name for object" warning in WinCC Flexible 2005 is a compile-time artifact of stale object-name registry data. The standard, supported fix is Project → Compiler → Rebuild All, which regenerates the registry from project source. Manual object renumbering is possible but labor-intensive and not recommended for projects with more than 50 warnings. Long-term prevention requires disciplined naming conventions, template-based reuse, periodic Rebuild All cycles after major project changes, and the "Use instance name = Yes" property on template objects. The same procedure applies to WinCC Flexible 2007, 2008, and the TIA Portal generation of WinCC.

For project standards, naming conventions, and migration procedures, consult the Siemens Industry Online Support portal and the WinCC Flexible engineering manual at Siemens Industry Online Support and the SIMATIC HMI product page.