Resolving STEP 7 Error 03D1: No PLC Type Description Found

The Siemens STEP 7 compiler error 03D1 ("No PLC type description found for called or addressed block") is one of the most common blockers encountered when migrating legacy S5 control logic into a S7-300 or S7-400 project, or when recompiling a hand-edited STL/AWL source file inside SIMATIC Manager. The error is emitted by the STEP 7 compiler and reported through the consistency check, the "Compile" command, or the S5-S7 Converter toolchain. Because the message does not name the offending block directly, engineers often stall for hours while searching for a missing FC, FB, or system function. This technical reference walks through the exact root causes, the diagnostic workflow, and the verified field procedures that clear the error on STEP 7 V5.x and TIA Portal V13-V20 targets.

1. Error Code 03D1: Formal Definition

According to the official STEP 7 Error Codes reference (PDF, 01/2014), error 03D1 is defined as follows:

The error indicates that the STEP 7 compiler has parsed a call instruction (CALL, UC, CC, or an FB/FC multi-instance call) but cannot find a corresponding type description (block interface, parameter list, or instance DB) in the program resource database. The compiler emits this error for any of three underlying conditions: a missing target block, a missing instance DB for a called FB, or a call placed before the called block has been generated in the source file.

2. Affected Products, Firmware, and Tool Versions

The error is tool-side, not firmware-side. It is reported by the offline compiler and does not require a PLC connection to reproduce. This is important when triaging: you can resolve 03D1 entirely on the engineering station.

3. Root Cause Taxonomy

From the formal error definition and verified field experience, error 03D1 is produced by exactly four mutually exclusive (but often co-occurring) root causes. Use this taxonomy to triage in less than five minutes.

3.1 Cause A: Missing S5-S7 Converting Library Block

The S5-S7 Converting Blocks library (shipped with STEP 7 V5.x) provides the STL/FBD equivalents of every S5 standard function block (FB240-FB255 and the S5 timer/counter replacement functions). When the converter emits FCs/FBs that call into this library and the library is not inserted into the target S7 program, every call resolves to "no type description" and the compiler reports 03D1. The library path is S7Program → Blocks → Insert New Object → Function, then attach blocks from Libraries → Standard Library → S5-S7 Converting Blocks.

3.2 Cause B: Unsorted AWL Source (xr.ini missing)

When the converted AWL source file is reimported into SIMATIC Manager, the compiler must resolve every CALL before it evaluates the call's parameter list. If the AWL is unsorted, a CALL to FC 100 appearing in OB1 before the FUNCTION FC 100 : VOID declaration causes the compiler to abort with 03D1. The sort order is dictated by the xr.ini cross-reference file. If xr.ini is missing from the project, no sort is performed and the error appears even on a logically complete program.

3.3 Cause C: Wrong Block Order (OBs, FCs, DBs)

The S5-S7 Converter generates a default order that is not always re-emitted on every re-compile. A common field pattern is:

1. OB1 placed before the FCs that it calls
2. FCs placed before the FBs that they instantiate
3. DBs placed before the FBs that own them

Even with all blocks present and xr.ini valid, the compiler will report 03D1 for the first call that resolves against a not-yet-declared target.

3.4 Cause D: Siemens Protected Blocks Not Removed

Legacy S5 programs often contain protected FBs (e.g., FB200-FB255 from Siemens standard packages) that the S5-S7 Converter cannot translate. These are typically identified in the S5 source by header comments such as *** Siemens Protected Block ***. When present in the imported S7 program, calls to them produce 03D1 because no type description accompanies the protected object.

4. Diagnostic Workflow

Follow this sequence to isolate the cause before applying any fix. Each step is offline and idempotent.

1. Capture the full compiler log. In SIMATIC Manager, right-click the S7 Program node and choose Compile. In the Compile dialog, ensure Generate cross-reference is checked. Save the log to a text file; do not rely on the message window scroll-back.
2. Tag every 03D1 line. Note the source file (OB1, FC12, FB7) and the call target (CALL FC100, UC FB200) reported on each 03D1 line. Cross-reference the targets against the actual blocks present in the Blocks folder.
3. Verify the S5-S7 Converting Library presence. In the project tree, navigate to Libraries → Standard Library → S5-S7 Converting Blocks. Confirm the library is opened and that the function numbers reported in the 03D1 lines exist in the library.
4. Check the AWL source sort order. Open the STL source file (e.g., MyProgram.awl) in the source editor. Read the file top-to-bottom and verify the order: OBs first with all their declared FCs/FBs after, then FBs, then DBs.
5. Confirm xr.ini is present. The file is generated automatically when Generate cross-reference runs. If absent, the sort pass is skipped.
6. Scan for protected blocks. Open each FB and check the header. Protected Siemens FBs are typically FB200-FB255; remove them only if the application logic does not depend on them.

5. Resolution Procedure A: Insert Missing S5-S7 Converting Blocks

This is the most common fix. It applies to 60-70% of reported 03D1 errors based on aggregated field tickets.

5.1 Prerequisites

• STEP 7 V5.x installed with S5-S7 Converting Blocks license present
• Read/write access to the S7 project file (no read-only attribute on .s7p)
• The exact FC/FB number from the 03D1 compiler line

5.2 Step-by-Step

1. Open the S7 project in SIMATIC Manager.
2. In the project tree, expand S7 Program → Blocks.
3. Right-click Blocks and select Insert New Object → Function (or Function Block for FB targets). Name the new object to match the number reported in the 03D1 line, e.g., FC 100.
4. Open the new block by double-clicking it. The LAD/FBD/STL editor opens. Switch to STL view (View → STL).
5. In the editor's left pane, open the Libraries catalog. Navigate to Standard Library → S5-S7 Converting Blocks.
6. Locate the function with the same number (FC100 in the example). Drag it into the open block, or use Edit → Insert → Block from Library.
7. Save (Ctrl+S) and close the editor. The system function now appears in the project's Blocks folder.
8. Re-run Compile on the S7 Program node. The 03D1 line for the previously missing call should disappear.

6. Resolution Procedure B: Sort the AWL Source and Regenerate xr.ini

This procedure handles 03D1 caused by out-of-order STL source. The technique is the same one used by the S5-S7 Converter internally.

6.1 Sort Order Rules

The S5-S7 Converter and the SIMATIC Manager source compiler expect blocks in the following order in the AWL file:

1. OBs without CALL instructions first (typically OB100, OB101 - startup blocks)
2. FCs in any internal order, but each FC declared before any FC or FB that calls it
3. FBs in any internal order, but each FB declared before any FC or FB that calls it
4. Instance DBs for the FBs above
5. Shared DBs last

6.2 Step-by-Step

1. Open the STL source file (File → Open → STL Source).
2. Use Edit → Find to locate each FUNCTION, FUNCTION_BLOCK, ORGANIZATION_BLOCK, and DATA_BLOCK header. Note the order they appear in.
3. Identify the FCs/FBs that are called before they are declared. The 03D1 line points to the call site; the missing declaration is the target.
4. Cut the misordered block declarations and paste them in the correct sequence. A typical fix is to move all OB blocks (OB1, OB100, OB101) to be after all FC declarations and before DB declarations.
5. Save the source file. SIMATIC Manager will regenerate xr.ini automatically on the next compile if the Generate cross-reference checkbox is on.
6. Recompile. Confirm 03D1 is resolved.

6.3 Verifying xr.ini

To confirm xr.ini is being read:

1. Navigate to the project's working folder (the same directory that holds MyProgram.awl).
2. Confirm xr.ini exists and has a non-zero size. If absent, run Options → Cross-Reference in SIMATIC Manager to force generation.
3. If the file is present but stale (timestamp older than the last edit), delete it and recompile. The compiler will regenerate a fresh file.

7. Resolution Procedure C: Reorder Blocks via Cut-and-Paste

When the 03D1 error is emitted in the Blocks folder view (not the AWL source), the fix is to reorder the blocks in the project tree. This is functionally equivalent to Procedure B but acts on compiled objects rather than the STL source.

1. In SIMATIC Manager, switch to the Blocks view (right-click S7 Program → Object Properties → ensure Block View tab is active).
2. Sort the display by block number (right-click column header).
3. Identify FCs/FBs called from OBs that appear later in the numbered sequence. The compiler resolves calls in numeric order only when sorted; otherwise it uses xr.ini.
4. Use Options → Block Consistency Check with the Sort blocks option enabled. This re-orders the in-memory representation and forces a re-compile pass.
5. Recompile. The 03D1 line should clear.

8. Resolution Procedure D: Remove Siemens Protected Blocks

If the S5 program contains standard Siemens FBs that were licensed separately (e.g., FB250 for PID control, FB200 for analog processing), the protected versions must be removed from the conversion because they cannot be decompiled.

1. Open the original S5 program (or the S5-S7 Converter output report).
2. Identify FBs in the range FB200-FB255. These are Siemens standard blocks.
3. For each Siemens protected FB called by user code, decide:

• If the application still requires the function: Re-insert the corresponding S7 version from the S7 standard library (e.g., PID control via PID_CP or CONT_C in the Standard Library). This breaks the call signature and requires parameter re-mapping.
• If the function is no longer needed: Delete the call instruction and any code that depends on its outputs.

4. Recompile. The 03D1 line corresponding to the removed call should clear.

9. Verification Procedure

After applying any of the four resolution procedures, run the following verification sequence to confirm 03D1 is fully cleared and no new errors were introduced.

1. Full compile. Right-click S7 Program → Compile → All. Confirm zero errors in the output window. Warnings about cross-references are acceptable.
2. Block consistency check. Options → Check Block Consistency. This performs a deeper analysis including interface matching between callers and callees. Zero errors expected.
3. Download dry run. With no physical PLC connected, select the target CPU and choose PLC → Download. Cancel the operation when prompted to select interface; the dry run confirms the project is internally consistent.
4. Cross-reference audit. Options → Cross-Reference → Display. Open the Used By view for every FC/FB that was previously called. Confirm the caller list matches the expected program structure.
5. Run a targeted compile on the migrated STL. If the S5 program was originally STL, recompile the generated S7 STL with optimization off (Options → Compiler → Optimization: Off). This surfaces any call-ordering issues that the optimized compiler may have hidden.

10. Related STEP 7 Compiler Errors

Error 03D1 rarely appears alone. Use the table below to map companion errors to their root causes.

For the complete catalog of STEP 7 compiler error codes, refer to the STEP 7 Error Codes reference (PDF, 01/2014) published on the Siemens Industry Online Support portal. For TIA Portal V20, runtime error messages for S7-300/400 instructions are documented at the TIA Portal V20 instruction error reference.

11. S5-S7 Converting Library: Function Number Map

The S5-S7 Converting Blocks library provides replacements for the most common S5 standard functions. Use this map to quickly identify the library block you need to insert.

Library FBs are non-protected and ship with full STL source in the S5-S7 Converting Blocks library. This allows direct inspection of the conversion logic to confirm parameter mapping is preserved.

12. Prevention Checklist

To avoid re-encountering 03D1 on future S5-S7 conversions or hand-edited STL sources, apply the following items at project setup and after every bulk source edit.

• Always open the S5-S7 Converting Blocks library in the S7 project before importing AWL sources.
• Run Options → Cross-Reference after every source edit to refresh xr.ini.
• Keep a version-controlled copy of xr.ini in the project source repository. The file is human-readable and can be diffed.
• Document block order in the project README. Any merge that reorders AWL blocks should be flagged in the code review.
• Use the S5-S7 Converter's "Convert with consistency check" option. This runs Procedure B automatically before emitting the STL output.
• Pre-strip Siemens protected blocks from the S5 program before running the converter. The converter's log will list the protected blocks it encountered; address them before the first compile.
• Standardize on a single block-numbering scheme (e.g., FC100-FC199 for utility, FC200-FC299 for process, FC300-FC399 for diagnostics). This makes OBs easier to order and call sites easier to audit.

13. Edge Cases and Field-Proven Caveats

13.1 03D1 in TIA Portal After STEP 7 V5.x Migration

When migrating a STEP 7 V5.x project to TIA Portal V16+ via the migration tool, 03D1 can appear on the first consistency check if the migrated AWL source carries a stale xr.ini from the V5.x project. The TIA Portal migration tool does not regenerate xr.ini by default. Manually delete the xr.ini from the TIA project folder and re-run Compile → All.

13.2 03D1 in Multi-Project Setups

In a multi-project with shared libraries, a 03D1 error can be emitted for a block in a partner project that has not yet been compiled. Compile the partner project first, then the master.

13.3 03D1 with Symbolic-only Calls

If the AWL source uses symbolic calls (CALL "Motor_Control") instead of absolute calls (CALL FC 100), the compiler resolves the symbol against the symbol table. A 03D1 error in this mode typically indicates the symbol is defined but the target block is not in the program resources. Confirm the block is present in the Blocks folder and that the symbol table entry maps to a real block number.

13.4 03D1 After STL-to-SCL Conversion

If the project is later re-edited in SCL and re-compiled, 03D1 can reappear if the SCL compiler generates a different block-number ordering than the STL compiler. Use the Compile → Software (rebuild all blocks) command to force a consistent ordering pass.

14. Related Diagnostics for Adjacent Toolchains

While error 03D1 is specific to STEP 7 / TIA Portal, similar "type description not found" errors appear in other PLC ecosystems. Understanding the conceptual mapping helps when working in mixed-vendor environments.

The Beckhoff 1300 error has a similar root cause pattern (missing type or POU) and is resolved by the same family of techniques: source reordering, library insertion, and cross-reference regeneration. The Allen-Bradley PLC-49x family is a different category - it reports runtime errors from the connected PLC rather than compile-time errors - but the diagnostic workflow (identify the type, locate the resource, repair the reference) is the same engineering pattern.

15. Quick-Reference Diagnostic Matrix

16. Summary of Field-Proven Resolution Steps

1. Capture the full compiler log. Tag every 03D1 line and the FC/FB number it points to.
2. Open the S5-S7 Converting Blocks library and confirm the missing target exists in the library.
3. If the target is in the library, insert it into the project Blocks folder. Recompile.
4. If 03D1 persists, sort the AWL source so FCs/FBs appear before their callers, and OBs come after the FCs/FBs they call but before the DBs.
5. Regenerate xr.ini via Options → Cross-Reference.
6. If 03D1 still persists, scan for Siemens protected blocks (FB200-FB255) and either remove the calls or replace with the S7 equivalent from the standard library.
7. Recompile, run block consistency check, perform download dry run, and audit the cross-reference list to confirm clean state.

With these procedures applied, error 03D1 should clear on the first re-compile in the majority of cases. If the error remains after Procedure A through D, the underlying issue is a corrupted project database; rebuild the project from source and re-apply the migration.