Resolving Greyed-Out DB Variables in TIA Portal V15 UDT/FB Source

Problem Description

In SIMATIC TIA Portal V15, an engineer opens a Data Block (DB) expecting to rename a tag, change a data type, or add a new variable. The DB editor opens, the row grid is visible, but the entire data view is rendered with a greyed-out background. No text fields are editable, no context menu items are active for "Rename", and any attempt to type is ignored. The engineer is locked out of the most basic structural edit on what appears to be a "normal" block.

This symptom is not a TIA Portal bug. It is the integrated development environment's deliberate behaviour for Data Blocks whose structural definition is owned by a parent object in the project. Once a DB has been derived from a User-Defined Type (called UDT in STEP 7 classic, and re-named PLC data type in TIA Portal) or from a Function Block (FB) static interface, the instance DB is no longer the "source of truth". The greyed-out appearance is a visual cue that the structure must be edited at its origin and then re-propagated.

Engineers familiar with STEP 7 V5.x will recognise the same lock-down behaviour: an instance DB that you "right-click → Open" in the S7-1500 CPU's program editor reveals the same greyed-out structural view, because the FB or UDT is the master and the DB is the slave.

Root Cause: Structure Ownership

Every DB in a SIMATIC S7-1200 / S7-1500 program can be created in one of three ways, and only one of those three allows the DB body itself to be edited as a free-form table:

The grey background is rendered by the TIA Portal editor when the block property "Assignment of the data block to a user-defined type" (in V15 and earlier: "Assignment of the data block to a data type") is set, or when the block property "Instance of the function block" is filled with the name of an FB. TIA Portal enforces a single-master rule: the UDT or FB owns the structure; every DB that references it inherits it.

This is a safety and consistency feature for S7-1500 controllers. It guarantees that a UDT-driven tag list (for example, a SCADA-communication struct) is identical in every instance, and that modifying an FB interface automatically updates every instance DB without manual copy-paste. The downside is that engineers who are not aware of the rule waste time trying to type into a disabled grid.

Identifying the Source Type

Before editing anything, identify which of the three creation methods was used. There are three reliable diagnostics, in order of speed:

Diagnostic 1: Block Properties

1. In the project tree, right-click the greyed DB and select Properties.
2. Switch to the Information / General section.
3. Look for either of the two fields below.

   Property Field	Meaning	Edit Origin
   Assignment to a PLC data type (V15+) or Assignment of the data block to a user-defined data type (V15 and earlier)	DB is a UDT instance	PLC data type (UDT) under PLC data types in the project tree
   Instance of the function block	DB is an FB instance (single or multi)	The referenced FB's static / input / output / in-out / temp interface

If both fields are empty, the DB is a free-form global DB - and the greyed-out behaviour means a different problem (typically the DB has its "Accessible from HMI / OPC UA" attribute mixed with "Block is know-how protected", or the project is open read-only from a network share).

Diagnostic 2: "Go to → Definition"

1. Open the greyed DB and place the cursor on the first variable row.
2. Right-click and select Go to → Definition (or press Ctrl+Shift+B in some TIA Portal versions).
3. TIA Portal jumps directly to the source: either the parent PLC data type editor or the parent FB's static / interface section.

This is the fastest path. It works for both UDT and FB-instance scenarios and bypasses any uncertainty about the block property mapping.

Diagnostic 3: Cross-Reference

1. Right-click the DB in the project tree and select Cross-reference (or Show usage).
2. TIA Portal lists all callers, the parent type, and every read / write access. A UDT-derived DB shows the parent PLC data type in the "Used by" column; an FB-instance DB shows the calling FB and the static-variable name it instantiates.

For engineers working under FW lock-down, this view is also the easiest way to confirm that no code or HMI tag will be orphaned by the upcoming rename.

Solution A: Editing a UDT-Derived DB

Once you have confirmed the DB is derived from a PLC data type (UDT), the fix is a four-step upstream edit:

1. In the project tree, expand PLC_x > PLC data types (or in older views: PLC_x > Program blocks > System blocks > PLC data types).
2. Double-click the source PLC data type - for example UDT_SCADA_COMM in the source case.
3. In the opened PLC data type editor, perform the rename, type change, or row addition. The editor is fully white / editable, exactly like a free-form global DB.
4. Compile the project (Project tree → right-click PLC → Compile → Software (rebuild all blocks)). TIA Portal will propagate the UDT change to every DB that references it and to every HMI / OPC UA tag that consumes it.

After the compile, reopen the greyed DB. The structure now reflects the new names, types, and offsets. The grey background remains - that is correct; the structure is still owned by the UDT.

Solution B: Editing an FB-Instance DB

If the DB is a single- or multi-instance of an FB, the structural edit must occur in the FB interface itself:

1. Locate the parent FB in the project tree. The DB's Properties → Information field "Instance of the function block" gives the FB's name (e.g., FB_MotorAxis).
2. Open the FB. Switch the lower editor pane to the Interface section (the section tabs are: Input, Output, InOut, Static, Temp, Constant).
3. For a pure name change, edit the Static section. For a type change of a tag that is wired out of the FB, edit Output or InOut as well.
4. Save and compile. TIA Portal will show a "Structural change after instance creation" warning under Tools → Project history in the Inspector window. Acknowledge the warning, then download the new FB and the refreshed instance DB to the CPU. The CPU goes into STOP if the FB header signature changes; for S7-1500 this STOP / RUN transition is unavoidable for structural changes that touch retentive tags.

Multi-instance DBs (an FB instantiated inside another FB's static section) follow the same rules but require the parent FB to be reloaded too, because the instance lives in the parent's static memory.

Converting a UDT/FB DB into a Free-Form DB (Last Resort)

There are limited scenarios where the engineer genuinely wants the DB to be a free-form block, not a slave of a parent type - for example, when inheriting legacy code where the UDT was deleted by mistake. The conversion is irreversible in TIA Portal V15 and is best avoided.

1. Open the DB, right-click, Properties → General.
2. Clear the "Assignment to a PLC data type" field (or the older "Assignment of the data block to a user-defined data type" field). If the field is greyed, the DB was created with the "based on UDT" wizard and cannot be unlinked in V15 - the workaround is to create a new free-form global DB and manually copy / paste the rows.
3. For an instance DB, the conversion path is: delete the instance DB, open the parent FB, and remove the multi-instance declaration; or change the call site from DB_Motor to a fresh FB_Motor instance.

After conversion, any code that referenced the old symbolic tag names will break, because the new free-form DB has different symbol names from the UDT. Mass re-wiring is usually required via "Rename" on the FB or UDT symbol.

Working Example: SCADA Communication DB

The original report uses a tag named UDT_SCADA_COMM in row 1 of the DB, followed by a STRUCT member. Concretely:

UDT_SCADA_COMM
STRUCT
   s_TagName  : STRING[32];r>   i_Value    : INT;
   r_Scale    : REAL;
   b_Active   : BOOL;
END_STRUCT;

To rename i_Value to i_ProcessValue:

1. Project tree → PLC_1 > PLC data types > UDT_SCADA_COMM. Open it.
2. Change the row name. The data type (INT) and the offset are unchanged.
3. Compile. TIA Portal updates the dependent DB, every HMI tag bound to "DB_SCADA".i_Value, and every OPC UA node mapped to that symbol.
4. Download the software to the CPU. The new symbol is active on the next scan.

If any HMI tag still references the old i_Value, TIA Portal raises an unresolved-symbol warning in the compile log under Info → Compile. The HMI must be recompiled and downloaded separately.

Step-by-Step Verification

After the upstream edit and compile, run the following verification sequence to confirm the change has propagated correctly:

1. Reopen the DB. Confirm the variable name now matches the new PLC data type or FB static section.
2. Open an Online → Go online session against the S7-1500 CPU. Force the value of the renamed tag via the watch table. The value must change in the live block. If the symbol still shows as undefined, the program has not been reloaded to the target - repeat the download.
3. Cross-reference the old symbol across the project. Right-click the project root → Cross-reference of project. The old name should produce zero hits; the new name should match the expected number of references.
4. Rebuild the HMI / SCADA project. In TIA Portal V15 this is Devices & Networks → HMI_1 → Compile → Software (rebuild all). The HMI tags should now resolve to the new symbol name without warnings.
5. For an OPC UA server, open the S7-1500 OPC UA configuration and verify the node set shows the new symbol path. Re-publish the server endpoint if it exposes the namespace to third-party clients.

Common Pitfalls and Field Notes

TIA Portal Version Compatibility

The greyed-out UDT / FB instance behaviour is consistent across the major TIA Portal releases that share the V15 codebase family:

For S7-1200 controllers the same rules apply from firmware V4.2 onward. For S7-300 / S7-400 controllers using the legacy STEP 7 V5.x editor, the UDT and instance-DB behaviour is identical in principle but the menu paths differ.

Useful Diagnostic Shortcuts