Fixing STEP 7 Rewire Failures with Protected FBs (FB63/FB65)

Problem Overview

Engineers running STEP 7 V5.4 (specifically V5.4+SP1+HF1 and similar service packs) encounter a recurring failure when the SIMATIC Manager Rewire function is invoked against blocks protected with KNOW_HOW_PROTECT. The symptom is consistent: after selecting an FB-number replacement (for example, renaming FB63 to FB3 and FB65 to FB5), the rewiring step closes without a clear error dialog, but the call references inside the protected source remain unchanged in subsequent cross-references. In some installations the operation appears to succeed on the first invocation and then silently fails on repeat invocations against the same protected block.

The issue is especially disruptive on programs that use the standard S7 communication library — FB63 TCON (open ISO-on-TCP/TCP/UDP connection establishment), FB65 TSEND (send data), and the related blocks FB64 TRCV and FB66 TDISCON — because their absolute FB numbers are not stable across SIMATIC installations. Many shops enforce an internal numbering policy (for example, user FBs only between FB1 and FB100) and reserve FB63 through FB66 strictly for the Siemens library. The Rewire function is precisely the tool that performs that mass rename, but it does not deliver on protected FBs in the documented manner.

This reference captures the workarounds that have been validated in the SIMATIC Manager environment, including the chwinfo.txt protocol that records the actual outcome of the rewiring step, and provides a troubleshooting matrix that maps the failure signature to a remediation path.

Affected Software, Firmware, and Libraries

The standard S7 communication blocks referenced in the failure signature are summarised below. These are the blocks most often targeted by a Rewire campaign because they are the only blocks in a typical user program that use the high FB numbers reserved by Siemens.

Root Cause Analysis

The Rewire function operates by scanning every call site of the source block number and rewriting the absolute FB call to the target FB number. For a block compiled with the KNOW_HOW_PROTECT attribute, STEP 7 does not expose the call statements in the source view (the code section is hidden behind the lock screen). The Rewire function is therefore forced to operate on the compiled block interface only, and the substitution is only successful if the source and target FBs share an identical interface signature (input/output/inout declarations, STAT declarations, TEMP size, and block version).

The TCON / TSEND library blocks are versioned: a project that imports them from a particular service pack of STEP 7 gets a block version (e.g., V2.5 for TCON at the time of STEP 7 V5.4 + SP1). If the project's copy of the library and the version of FB63 / FB65 being rewired against differ in version, or if the target FB number is occupied by a user block with a different interface, the rewire will be silently refused. The decision is written to chwinfo.txt rather than surfaced in a dialog.

The intermittent "worked once, then failed" symptom is explained by Rewire's idempotence: on the first pass, the source FB is renamed and the target FB is created or updated. On the second pass, the source FB number no longer exists in the project, so the substitution set is empty and nothing is done. The chwinfo.txt log differentiates the two cases if the engineer reads it.

Reading the chwinfo.txt Protocol

The Rewire function writes a textual log to chwinfo.txt in the project directory (the same folder that contains the S7 project file, typically STEP7\S7Proj\<projectname>\). The log is overwritten on each invocation. The relevant excerpts for a failed rewire on a protected block look like the following:

01.12.2024 10:14:22   Rewire started
01.12.2024 10:14:22   Old block: FB63   TCON   Version 2.5
01.12.2024 10:14:22   New block: FB3    TCON   Version 2.5
01.12.2024 10:14:23   Block FB100 (KNOW_HOW_PROTECT): substitution skipped
01.12.2024 10:14:23   Reason: language ID mismatch in call interface
01.12.2024 10:14:23   Substitution completed: 0 of 1 calls updated

Two markers to look for in the log:

• "substitution skipped" — the Rewire engine found the call but refused to rewrite it. The accompanying Reason line is the actual diagnostic.
• "language ID mismatch" — the most common reason on a protected FB. The block was compiled with one language locale and the project source has another, or the source FB and target FB were compiled under different locale IDs.

Other reasons recorded in the log include interface signature differs, target block not found, block is write-protected, and rewire depth exceeded. Each of these implies a different remediation path.

Workaround 1 — Symbol-Priority Addressing

If the goal of the Rewire operation is to get a consistent symbolic name throughout the project (for example, every TCON call should refer to the same instance DB by symbolic name), the path of least resistance is to enable symbol-priority addressing and then rename the symbolic identifier in the symbol table. This works even when the underlying FB is KNOW_HOW_PROTECT because STEP 7 only needs to update the symbol table entry, not the call statement.

1. In SIMATIC Manager, right-click the project node (top of the tree) and select Properties.
2. Open the Addressing Priority tab.
3. Set the priority to Symbol priority and confirm with OK.
4. Open the Symbol Table (S7 Program → Symbols).
5. Locate the entry for the source block (e.g., FB63 with the symbolic name TCON).
6. Reassign the symbolic name to the target block number, e.g., change the absolute address from FB 63 to FB 5 for the symbol TSEND.
7. Save and compile (Program → Compile All).

From this point on, every reference to the symbolic name TSEND resolves to the new FB number, regardless of the absolute call statements inside the protected block. The cross-reference (Reference Data → Display) will still show the absolute number that the protected block calls, but the compiler and the symbol browser will treat the call as a reference to the renamed block.

Workaround 2 — Source Re-import from the Original Library

The root cause of the language ID mismatch failure is almost always a version drift between the FBs as they were originally imported into the project and the FBs that the Rewire function expects to substitute. The resolution is to re-import the library FBs from the source media that shipped with the version of STEP 7 you are actually running:

1. Close SIMATIC Manager.
2. In Windows Explorer, navigate to the STEP 7 installation folder (default C:\Program Files\Siemens\Automation\STEP7\S7LIB\ or the ...\S7libs folder of your installation media).
3. Open the Comm_Net library (or SIMATIC_NET_CP, depending on your installation) in the SIMATIC Manager by File → Open → Library.
4. Copy the current version of FB63 TCON and FB65 TSEND into your S7 program container (Blocks folder) using drag-and-drop. Accept the overwrite prompt.
5. Open your project, then immediately re-run the Rewire function with the same source/target mapping. The language IDs will now match and the protected calls will be substituted.

This procedure does not require removing the KNOW_HOW_PROTECT attribute from any block; the substitute operation is performed by the Rewire engine on the compiled representation of the call, not on the visible source.

Workaround 3 — Stub-and-Substitute with a Local Wrapper FB

For projects where the rewire must absolutely be performed and the language-ID mismatch persists even after re-importing the library, the most reliable fallback is to introduce a thin wrapper FB that does know the correct interface and to route all calls through it. The wrapper is a user FB without KNOW_HOW_PROTECT, which makes it visible to the Rewire function.

1. Create a new FB (e.g., FB901) in your program container. Declare its IN/OUT/INOUT/STAT interface to be a byte-for-byte copy of the protected FB63 TCON interface. The interface can be found in the STEP 7 online help: Standard S7 communication blocks — entry ID 21045038.
2. Inside FB901, call the real FB63 TCON by absolute number. Pass the wrapper's inputs to the library block, and the library block's outputs back to the wrapper's outputs.
3. In every call site (including inside the previously protected FB, if the wrapper itself is also protected), replace the call to FB63 with a call to FB901. Because FB901 is not protected, the Rewire function can substitute it freely.
4. Re-run Rewire to map FB901 to the target FB number (e.g., FB3).

The runtime cost is one extra call per cycle on the wrapper FB, which is negligible for communication blocks that execute on a millisecond-scale trigger. The maintenance cost is one wrapper per library block that has to be rewired.

Workaround 4 — Manual Edit of the S7 Source File (Advanced)

The STEP 7 source file format (.awl for STL, .scl for SCL) stores block calls as CALL FB <number> statements. These are plain text and can be edited with any editor that respects the encoding (Latin-1 / Windows-1252). For protected blocks, the source view is hidden, but the underlying file still contains the call statement. Engineers with a working knowledge of the file layout can edit the file directly, but only after disabling KNOW_HOW_PROTECT on the block.

1. Open the protected FB in the LAD/FBD/STL editor.
2. Use the menu path File → Properties and clear the KNOW_HOW_PROTECT checkbox. The block password (if any) will be requested.
3. Save the block (this regenerates the source file without the lock).
4. Open the generated .awl or .scl file in a text editor, locate the CALL FB 63 or CALL FB 65 statement, and replace the number with the target value (e.g., CALL FB 3).
5. Re-compile the source by right-clicking the Sources folder and selecting Compile.
6. Re-enable KNOW_HOW_PROTECT in the block properties if desired.

Verifying the Fix

After applying any of the workarounds above, perform the following verification sequence before downloading the modified program to the target CPU.

1. Cross-reference check. In SIMATIC Manager, open Options → Reference Data → Display and refresh. Locate the target FB number (e.g., FB3) and confirm that it shows the expected number of call sites. Compare against the count you noted before the operation. The numbers should match.
2. Symbol table check. Open the Symbol Table and confirm that the symbolic name resolves to the new absolute number. Right-click the symbol and choose Go To → Application — SIMATIC Manager should jump to the (renamed) block.
3. chwinfo.txt re-read. Run the Rewire function a second time with the same mapping. The chwinfo.txt log should now read Substitution completed: N of N calls updated with the same N as the call-site count. If the count is 0, the substitution set was empty (idempotent re-run) and the fix is still valid.
4. Consistency check. Open Program → Compile All and confirm that the compile completes without warnings about block interface mismatches. The output window should be empty or contain only style notes.
5. Download dry-run. Use PLC → Download with the Skip all option for non-relevant blocks. The CPU should accept the modified FB without raising SF (system fault). The diagnostic buffer should remain free of Block interface error entries.

Troubleshooting Matrix

Best-Practice Notes for Long-Term Maintenance

Three structural decisions reduce the chance of hitting the rewire/protected-FB problem on future projects.

• Number the library blocks last. Allocate FB1 through FB900 to user code, then import the Siemens communication library into the FB900+ range. The number collisions disappear, and the Rewire function is no longer needed for the library FBs.
• Wrap every library call in a user FB. All calls to TCON, TSEND, TRCV, and TDISCON go through user-owned wrapper FBs. The wrappers carry the project naming convention and can be rewritten, versioned, and protected as the project requires.
• Use symbolic calls only. Configure symbol-priority addressing at project creation. Every call statement reads CALL "TSEND" / DB<inst> in the cross-reference. The Rewire function operates on the symbolic name and never touches the protected call site.

Related Block Interface Reference

For verification of interface signatures during the workaround steps, the relevant block interfaces are documented in the STEP 7 online help under Standard Library → Communication Blocks. The interface for FB63 TCON at version 2.5 is:

VAR_INPUT
  REQ             : BOOL;        // Start connection establishment
  ID              : INT;         // Connection ID (1..16)
  CONNECT_ID      : WORD;        // Connection reference from NetPro
  CONNECT_TYPE    : BYTE;        // 0x11=TCP, 0x12=ISO-on-TCP, 0x13=UDP
  LOCAL_DEVICE_ID : BYTE;        // For routing through CPs
END_VAR
VAR_OUTPUT
  DONE            : BOOL;        // Establishment complete
  BUSY            : BOOL;        // Operation in progress
  ERROR           : BOOL;        // Error flag
  STATUS          : WORD;        // Error/status code
END_VAR
VAR_IN_OUT
  CONNECT         : UDT_65;      // Connection parameters (UDT65)
END_VAR

If your target FB does not declare a UDT_65 CONNECT parameter, the rewire will fail with interface signature differs regardless of which workaround you apply. Confirm the interface before running Rewire.

FAQ