Resolving CFC Compiler Error: DB Address Not in Symbol Table

Problem Description

When compiling a Continuous Function Chart (CFC) in SIMATIC STEP 7 (Classic V5.x with the optional CFC package) or in TIA Portal (V15.0 and higher, with the CFC option installed), the compiler aborts with an error of the form:

The error appears in the Inspector window under Info > Compile, attached to a specific sheet, block, or pin inside the CFC chart. The referenced data block is a multi-instance DB instantiated from a User-Defined Data Type (UDT), and the address is being written on a CFC pin in absolute notation (DBx.DBD0, DBx.DBB0, etc.).

The message is misleading: the absolute address does exist at runtime, the DB does exist in the S7 program, and the UDT does exist in the project. The actual problem is that the CFC compiler cannot bind the absolute address to a global symbol, and that binding is mandatory at compile time because CFC compiles into SCL/STL through the symbol table. The compiler refuses to add the symbol implicitly.

Environment and Affected Versions

The error text, the underlying root cause, and the fix are identical across classic STEP 7 and TIA Portal. Only the navigation paths and the symbol-table terminology differ (Classic calls it the Symbol Table, TIA Portal calls it PLC tags).

Root Cause Analysis

CFC is a graphical, signal-flow oriented language. The chart itself stores no data; the editor generates SCL or STL source at compile time. The generated code must reference every input, output, and in/out by symbolic name because the runtime optimizer, the cross-reference tool, and the download all depend on the global symbol table to resolve where data lives in the process image, work memory, or load memory.

The compiler walks the chart in two distinct passes:

1. Pass 1 — Symbol resolution: every address written on a pin is mapped to the global symbol table. If the absolute address is not present, or if it is present but is non-unique (two symbols pointing to one address, or one symbol pointing to two addresses), compilation aborts and the offending pin is highlighted in the error list.
2. Pass 2 — Type checking: the data type on the source pin must be assignment-compatible with the data type on the destination pin. UDT members are compared structurally. A UDT in one chart and a UDT with the same name but a different version in another chart will fail Pass 2 even if Pass 1 succeeded.

When you instantiate a UDT inside a DB, the editor creates the instance with the correct absolute memory layout, but the global symbol table is updated only when you explicitly declare the DB symbol. The CFC compiler will not silently register a symbol based on absolute address syntax, even if the address is valid at runtime. This is by design: silent symbol creation would mask programming errors and corrupt the cross-reference list.

How CFC Resolves Addresses

CFC interconnections can be expressed in three different ways. Each requires a different level of symbol-table support.

When the chart is compiled, the editor replaces the string on the pin with the fully qualified name from the symbol table. If the entry cannot be resolved, the pin remains in an "unbound" state and the compiler reports it. The pin remains visible in the chart; only the compile process aborts.

Why UDT-Based Data Blocks Trigger the Error

UDTs are most often used as the basis for interface DBs — recipe DBs, process-value DBs, unit-parameter DBs. Two distinct bugs lead to the same error message:

1. The instance DB itself is missing from the symbol table. You created DB100 by dragging a UDT onto the program-blocks folder, but you did not open the PLC tag table and add a row with Name = Recipe_DB and Address = DB100. Without that row the absolute address DB100.DBD0 is unknown to the compiler, even though the DB and the data are present at runtime.
2. The DB is in the symbol table, but the CFC pin is typed as a sub-element address that conflicts with a tag. For example, you wrote DB100.DBB0 on the pin, but the symbol "Recipe_DB" points to DB200, or a different PLC tag already maps to DB100.DBB0. The compiler refuses the ambiguous binding and reports the address as "not unique".

A third, less common variant: the UDT was renamed or recompiled with new offsets, but the instance DB has not been recompiled. The runtime memory layout is now stale, and the compiler raises the same error because the offset of the UDT member no longer matches the offset the chart expects.

Solution 1 — Declare the Data Block in the Symbol Table

This is the canonical fix. Add the DB as a global symbol and recompile.

STEP 7 V5.x

1. Open S7 Program > Symbols.
2. Append a new row: Symbol = Recipe_DB, Address = DB 100, Data type = DB 100, Comment = optional.
3. Save and close the symbol table (Table > Save).
4. Open the CFC chart, right-click and choose Chart > Compile > Charts as program.
5. Inspect Info > Compile; the previous error must no longer appear.

TIA Portal V16 / V17 / V18 / V19 / V20

1. Open the project tree and expand the target PLC.
2. Select PLC tags > Show all tags (or open the Default tag table).
3. Append a row: Name = Recipe_DB, Data type = DB, point the row at the existing instance DB (the dialog offers the block name and number).
   Alternative: drag the instance DB from Program blocks directly into the tag table; the editor creates the row automatically.
4. Open the CFC chart, right-click and choose Compile > Charts as program.
5. Open the Inspector window > Info > Compile and confirm the error is gone.

Solution 2 — Use Symbolic Addressing in the CFC

Avoid absolute notation entirely. Open the chart, double-click the pin, and use the Browse button to select "Recipe_DB".Heating.Setpoint. The compiler binds the path to the UDT element directly. The DB must still be in the symbol table, but the chart no longer carries the absolute address on the pin.

Symbolic addressing is preferred in new projects because:

• Renumbering the DB does not break the chart.
• The compiler performs full type checking on UDT member access.
• Cross-chart references are easier to maintain and document.
• The cross-reference list shows every chart that uses the UDT member, which is essential for impact analysis.

Solution 3 — Expose the UDT Through an FB Parameter

The most maintainable pattern for shared UDT instances is to keep the UDT as the type contract of an FB, and to pass the UDT instance in/out as a single structured pin. The CFC chart then operates on the whole UDT through that pin, and the compiler does not descend into individual UDT members on the sheet.

1. Declare a UDT (e.g. UDT_Heating) containing all structured data:
   TYPE UDT_Heating
STRUCT
  Setpoint : REAL;
  ActualValue : REAL;
  Enable : BOOL;
END_STRUCT
END_TYPE
2. Declare a multi-instance DB (DB_Heating_Instance) of UDT_Heating. Declare its symbol in the PLC tag table (Heating_DB).
3. Add an FB (e.g. FB_Heating) with an in/out parameter of type UDT_Heating:
   VAR_IN_OUT
  io_Data : UDT_Heating;
END_VAR
4. Call FB_Heating in CFC and connect Heating_DB to the structured pin io_Data.

This pattern eliminates the "not in symbol table" failure mode for member access, because the chart carries only the UDT instance, not its individual members. The FB owns the type contract and can be reused across multiple charts. Re-compilation after a UDT change is a single click on the instance DB.

Verification Procedure

1. Open Info > Compile. Confirm the original error is no longer listed.
2. Open the cross-reference list (Go to > Cross-reference in Classic, Project tree > Cross-references in TIA Portal). Filter for the DB. The CFC chart entries should appear with status compiled rather than unbound.
3. Download the program to the CPU or to PLCSIM. Place a watchpoint on DB100.DBD0 and on the CFC pin. Both should update identically in online mode.
4. Force a chart recompile: Chart > Compile > Charts as program (regenerate). Some installations suppress the "Charts as program" step if the source has not changed; force it once to confirm the binding holds after a clean rebuild.
5. If the chart is part of a CFC library or a master data library, repeat the verification after re-importing the library to confirm the symbol binding survives library updates.

Prevention and Best Practices

• Declare every instance DB in the symbol table immediately after creation. A naming convention (e.g. iDB_Heating for instance DBs, gDB_AlarmLog for global DBs) makes missing entries visible during project review.
• Avoid absolute addresses in CFC pins. Use the UDT member path or the structured FB parameter instead. Absolute addresses are acceptable during commissioning but should be migrated to symbolic form before project release.
• One UDT, one source of truth. If a UDT is modified, propagate the change to all instance DBs before recompiling CFC. Stale UDT versions can also produce "not unique" errors when the offset layout diverges from what the chart expects.
• Compile charts in the correct order. In STEP 7 V5.x, the chart compilation order is determined by the chart-folder priority. In TIA Portal, the order is top-down in the project tree. Wrong order can produce cascading errors that mask the root cause.
• Use the cross-reference list before deleting or renumbering any DB referenced in a CFC. The chart does not warn before breaking; only the next compile reveals the damage.
• Reserve a separate PLC tag table for CFC signal names (e.g. CFC_Signals) to keep them isolated from the I/O tag table. This prevents accidental address overlap with peripheral I/O and makes the symbol-table review easier.
• Run a project-wide consistency check (Project > Compile > All in TIA Portal, or PLC > Compile and Download Objects in Classic) after any DB or UDT modification. A clean compile of every block before chart regeneration eliminates the cascading-error problem.

Related Errors and Edge Cases

Frequently Asked Questions