Siemens STEP 7 SCL: Resolving Unrecognized Block Names

David Krause2 min read
S7-300SiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The error symbolic block name: 'xswap' is not recognized means the SCL compiler cannot resolve xswap to a numbered STEP 7 block. The declaration i0_xswap: xswap; uses xswap as a block type, but a source-level FUNCTION_BLOCK xswap declaration alone does not establish the required numbered-block symbol mapping.

Why STEP 7 Does Not Resolve xswap

In this STEP 7 workflow, a block requires a block number. A symbolic name is optional, even when symbol priority is enabled. Therefore, xswap must resolve through the symbol table to its assigned numbered function block before another function block can declare an instance of it.

Code element Compiler requirement
FUNCTION_BLOCK xswap Create or assign the corresponding numbered function block.
i0_xswap: xswap; Resolve xswap through the symbol table.
i0_xswap(...) Use the declared instance after its block type resolves.

Correct the Block and Symbol Definition

  1. Create or assign a numbered function block for the xswap implementation.
  2. Enter xswap as that block's symbolic name in the STEP 7 symbol table.
  3. Confirm that the SCL declaration uses the identical spelling: i0_xswap: xswap;.
  4. Compile again and verify that the compiler now resolves the symbolic block type.

The evidence does not provide the intended block number, so select an unused number that fits the project rather than assuming one.

Verify the Generated SCL Structure

The relevant dependency is visible in xgetrf:

VAR
    i0_xswap: xswap;
END_VAR

IF (jA - 1) <> 0 THEN
    ipiv[j] := j + jA;
    i0_xswap(x := A_0, ix0 := j + 1, iy0 := j + jA);
END_IF;

First verify that the declaration no longer reports xswap as unrecognized. Then review subsequent compiler messages independently. The supplied generated source also contains an unnamed FUNCTION_BLOCK and the text nbits between statements in inv; these are separate source defects and may produce additional errors after symbol resolution succeeds.

Separate Symbol Errors from Later Compile Errors

Do not treat a successful xswap lookup as proof that the entire generated source is valid. Resolve block symbols first, then work through the remaining diagnostics at their reported locations. Apply the same numbered-block and symbol-table check to the other symbolic block types used by the generated code, including xgetrf, eml_ipiv2perm, xtrsm, invNxN, inv, and nbits.

FAQ

Why does STEP 7 SCL say symbolic block name xswap is not recognized?

xswap does not resolve to a numbered block through the symbol table. Assign the implementation to a numbered function block and map the symbol xswap to it.

Is FUNCTION_BLOCK xswap enough to declare the block in STEP 7?

No. In the workflow described by the evidence, the block must have a number; the symbolic name is an optional mapping used by declarations such as i0_xswap: xswap;.

Why do errors remain after fixing the xswap symbol?

The generated source contains other apparent defects, including an unnamed FUNCTION_BLOCK and stray nbits text in inv. Recompile after fixing the symbol, then correct each remaining diagnostic separately.

Back to blog