Resolving Unrecognized PLC Tags After Import in TIA Portal

Problem Overview

When a Siemens TIA Portal project is translated from one working language to another (for example, German to English), engineers commonly export the PLC tag table, rename the Name column in Excel, delete the original German entries, and re-import the renamed English file. The expected behavior is that the new English names will replace the German names in the PLC tag database and propagate automatically into every code block (LAD, FBD, SCL, STL, GRAPH) that referenced them. In practice, the program goes into a state where the previously valid tag references are shown as unresolved (red squiggles in SCL, "???" placeholders in LAD/FBD contact networks, or compile error Unknown identifier). The PLC tag table itself displays the renamed tags, but the program editor still binds to the deleted symbol set.

The behavior is not a bug in the import routine. It is the consequence of how the TIA Portal tag database links program symbols to absolute addresses (%I, %Q, %M, %DB) and how the compiler resolves those links. Once a tag row with a given symbolic name is removed, all references to that name become orphans. Re-creating a row with the same address but a new name is treated by the compiler as a different symbol. The fix is to either preserve the original row and update only the symbolic name, or to use the import option that overwrites the existing row in place rather than adding new rows.

Technical Root Cause

TIA Portal stores PLC tags in a project-wide symbol table that is referenced by every code block through a unique symbolic ID, not by the displayed string. The internal table is a structured SQLite database (project cache) that links three pieces of information per tag:

• Symbolic name (the Name column shown in the editor)
• Absolute address (for example, %MW100, %I0.0, %DB1.DBX0.0)
• Data type and comment

When you delete a tag row, TIA Portal removes all three pieces and replaces the in-program references with a placeholder. When you then re-import a tag with the same address and a new name, the editor creates a new row with a new internal symbolic ID. The placeholder references in your code blocks still point to the deleted ID and will not auto-rebind to the new ID. This is by design: TIA Portal cannot safely assume that a tag at the same address is semantically the same tag, because addresses can be reused intentionally for different purposes across refactors.

The yellow duplicate markers you see when you re-import without deleting are a confirmation of this behavior. TIA Portal detected that the incoming row has the same Address as an existing row, but because the Name differs, it refuses to overwrite the existing row and instead creates a duplicate entry flagged with a warning icon.

Recommended Solution: Synchronize Tags by Address

The correct workflow for renaming tags in bulk while preserving program references is to use the Synchronize tags by address import option. This option tells the importer to match incoming rows to existing rows based on the absolute address and to overwrite only the fields you specify (name, comment, data type) while keeping the internal symbolic ID intact. The result is that the new name propagates automatically to every code block that references the tag.

Step-by-Step Procedure

Prerequisites

• TIA Portal V16 or later (V17/V18 recommended for the best tag import behavior). Earlier versions (V13/V14/V15) have a slightly different import dialog and may not show the Synchronize option in the same location.
• An open project in which you can compile without errors before starting the translation.
• A backup copy of the project (File → Archive → Project archive) before making any changes.
• Microsoft Excel or a compatible CSV editor for offline translation.

Step 1: Export the Current Tag Table

1. Open the PLC tag table in the project tree: PLC → PLC tags → Show all tags (or the default tag table if you only have one).
2. Right-click the tag table header and select Export → Export to Excel or use the toolbar icon Export to XLSX.
3. Save the file to a working directory outside the project folder.
4. Open the exported file and verify the columns present: Name, Path, Address, Data type, Comment, and any user-defined columns.

Step 2: Translate the Names in Excel

1. Add a new column to the exported file called Name_ENG (or similar) and copy the original names into it for reference.
2. Rename the Name column to the target language. Keep the Address, Data type, and Comment columns unchanged unless you also intend to translate comments.
3. Save the file in XLSX format. Do not change the column order or rename column headers other than the Name column itself.
4. Verify the file by opening it in TIA Portal's import preview before committing.

Step 3: Import with Synchronization

1. Right-click the same tag table in TIA Portal and select Import → Import from Excel.
2. Browse to the translated XLSX file and select it.
3. In the import dialog, set the Import mode to Synchronize tags by address (sometimes shown as Update existing tags based on address depending on the TIA Portal version).
4. Map the columns from the spreadsheet to the TIA Portal tag table fields. The default mapping should auto-detect Name, Address, and Data type if the headers are unchanged.
5. Click Preview to see which rows will be updated, added, or flagged. Rows that match an existing address should appear under Update, not Add new.
6. Confirm the import. TIA Portal will overwrite the symbolic names in place and the program blocks will retain their references.

Step 4: Recompile and Verify

1. Right-click the PLC and select Compile → Software (rebuild all blocks).
2. Open a few SCL blocks that you know referenced the renamed tags. The symbol names should now show the English version with no red squiggles.
3. Open a LAD/FBD network that referenced a renamed bit. The contact/coil label should show the new English name with the correct address in parentheses.
4. Check the Cross-references (right-click on any tag → Cross-reference information) to confirm that the new name is used consistently across the project.

Alternative Method: Update Tag Names In-Place

If you have only a small number of tags to rename, you can update names directly in the TIA Portal tag table without exporting:

1. Open the tag table.
2. Click on the Name cell of the tag to rename.
3. Type the new name and press Enter. The new name propagates immediately to all program blocks that reference the tag.
4. Save and compile.

This method is safe for individual renames but does not scale to hundreds of tags. It also does not give you a paper trail of the translation, which is often a regulatory requirement (for example, FDA 21 CFR Part 11 or ISO 13849 documentation).

Project Language Considerations

TIA Portal maintains a separate setting called the Project language under Project → Properties → Project information → Project language. This setting controls the language used for the user interface, system diagnostics, and the language in which comments and tag names are displayed when no language-specific override exists.

If your project language is set to German but your tag names are now English, you will see inconsistent behavior in the HMI, web server, and diagnostic buffers. To align everything:

1. Open Project → Properties.
2. Select the Project language tab.
3. Add English to the list of active project languages and set it as the reference language if you want it as the default.
4. Save the project. TIA Portal will offer to translate the project text. Confirm the prompt.
5. Re-import the translated tag table to populate the English comments and tag names in the new project language.

Why Deleting Tags Breaks References

To understand the failure mode, it helps to look at how the SCL compiler resolves a symbol reference. Consider this SCL snippet in a function block:

IF "Motor_Start" THEN
    "Motor_Speed" := 50;
END_IF;

At compile time, the SCL compiler looks up the symbolic name "Motor_Start" in the PLC tag table, retrieves the associated absolute address (for example, %I0.0), and generates machine code that reads from that address. If the symbol "Motor_Start" has been removed from the tag table and a new tag with the same address but a different symbolic name has been added, the compiler cannot resolve "Motor_Start" at all. It does not attempt to fall back to the address or to look for a fuzzy match. The reference becomes a hard error: Identifier 'Motor_Start' is not declared.

When you use Synchronize tags by address, the import routine does the following for each row in the spreadsheet:

1. Look up the incoming Address in the current tag table.
2. If found, update the existing row's Name, Comment, and any other specified fields, but keep the internal symbolic ID constant.
3. If not found, create a new row (adds the tag).

Because the internal symbolic ID is preserved, every code block that previously referenced the old name will now resolve to the new name without any change to the compiled code (the absolute address is unchanged). The user-visible change is the symbolic name shown in the editor.

Common Errors and Edge Cases

Error: Tag Name Contains Reserved Word

Some English words are reserved in SCL/STL: TRUE, FALSE, AND, OR, NOT, XOR, MOD, IF, THEN, ELSE, ELSIF, END_IF, WHILE, DO, END_WHILE, FOR, TO, BY, END_FOR, CASE, OF, END_CASE, RETURN, EXIT, CONTINUE, GOTO, LABEL. If your translated name collides with one of these, the import will either reject the name or accept it but generate a compile error. Wrap reserved words in single or double quotes in SCL, or choose a different name in the spreadsheet.

Error: Tag Name Has Duplicate Entry

Symbolic names must be unique within a PLC's tag scope. If you rename two tags to the same English name (for example, two tags both called Status in different contexts), the import will create a conflict. Resolve this by adding a prefix or suffix to disambiguate (for example, Motor_Status and Pump_Status).

Error: Data Type Changed Unexpectedly

If you accidentally modify the Data type column during translation, the import with Synchronize will overwrite the data type and may break code blocks that assumed the original type (for example, an INT cast to a BOOL via BOOL_TO_INT). Always leave the Data type and Address columns unchanged during a name-only translation.

Error: Tag Marked with Yellow Warning After Import

Yellow warnings on a tag row after import usually indicate one of the following:

Edge Case: Multi-Language Tag Display

When a project supports more than one language, PLC tags can have language-specific display names. The Name field is a single symbolic identifier; the Comment field can be multilingual. If you want the HMI to show the tag name in English, German, and Chinese depending on the operator's language, you must set the project language to multi-language mode and provide translated Comment values. The symbolic Name itself remains a single identifier per tag.

Edge Case: Tags in Multiple PLCs

If your project has more than one PLC (for example, a SIMATIC S7-1500 CPU and a SIMATIC ET 200SP CPU), each PLC has its own tag table. Renaming tags in one PLC's table does not affect the other. You must export/translate/import separately for each PLC. Cross-PLC references in SCL are made by fully qualified names like "PLC_2"."Motor_Start".

Tag Import Workflow Comparison

Verification Checklist

After completing the import and recompile, run through this checklist to confirm that the rename succeeded without orphan references:

1. Open the PLC tag table. Every row should have a unique name and address. No yellow warning icons should be present.
2. Open the Cross-references view (Show all tags → right-click → Cross-reference). Filter by a sample of renamed tags. Each tag should show the expected number of usages across OB, FB, FC, DB, and HMI tag tables.
3. Compile the PLC software. The compile log should show no errors and no warnings about unresolved symbols.
4. Open a sample SCL block that referenced a renamed tag. Hover over the symbolic name. The tooltip should show the new English name, the absolute address, and the data type.
5. Open a sample LAD network. The contact/coil labels should show the new English name with the address in parentheses.
6. Download the project to the PLC (or simulate) and verify the runtime behavior matches the pre-translation behavior. Functional equivalence is the ultimate test.
7. Update the HMI tag references. If the HMI was using the old German names, regenerate the HMI tags from the PLC tag table to refresh them.

Related Issues and Workarounds

Project Won't Compile After Translation

If the project compiles with errors after the import, open the Compile window and look for the Unresolved symbols section. Each unresolved symbol lists the block and the line where it is used. You can click on the error to jump to the offending line. Typical causes are typos in the translated name or names that conflict with SCL reserved words.

HMI Tags Out of Sync

The HMI in TIA Portal maintains its own tag list that points to the PLC tags. After renaming PLC tags, the HMI tags must be regenerated. Right-click the HMI tag table and select Compile → Software (rebuild all blocks). Then drag the renamed PLC tags into the HMI connection to refresh the references. Alternatively, use the Update HMI tags function if your TIA Portal version supports it (V17+).

Watch Tables and Force Tables Reference Old Names

Watch tables and force tables are project-level objects that store their own copy of the tag name. After renaming, open each watch table and force table, find the old name, and replace it with the new one. The cross-reference view will list which watch tables reference each tag.

Documentation and Printouts

If you generate project documentation in TIA Portal (Project → Documentation → Generate), the printed PDFs will show the current (renamed) tag names. The previous printouts are not updated. Keep a record of the translation date in the project properties' Project history field for audit purposes.

Prevention for Future Translations

To avoid this problem in future projects:

1. Start the project in English from day one. Use a single source language for all symbolic names.
2. Use the Comment field for translations, not the Name field. Comments can be multilingual; names cannot.
3. If you must change the working language mid-project, follow the Synchronize by address workflow above, not delete-and-replace.
4. Enable Project history in the project properties and record every translation as a project event.
5. Set up source control (for example, Git with the TIA Portal Project Server) so you can diff tag tables between revisions and roll back if a translation goes wrong.

FAQ