Siemens Siwarex WP341: Resolving Internal Consistency Error 604:864 and FB Renumbering Failures in TIA Portal

The Siemens Siwarex WP341 weigh-feeding module is delivered with a pre-compiled, Know-How protected Function Block that simplifies integration into STEP 7 (TIA Portal) projects. When an integrator attempts to renumber the FB to avoid a conflict with the safety program of a CPU 1515F-2 PN, or simply tries to copy the example project into a live machine, TIA Portal frequently reports "An internal consistency error has occurred. Please compile the program in this CPU again. The following blocks could not be compiled: WP341 [FBxxxx]" with diagnostic buffer entry 604:864. The error blocks commissioning, prevents download, and locks the user out of the HMI/Scale faceplate. This guide explains the exact root cause, the constraints of the Know-How protection, and the documented Siemens recovery path for S7-1500, S7-1500F, ET 200SP and TM SIWAREX WP341 HF stations running TIA Portal V16, V17, V18 and later.

1. Problem Description and Symptoms

Field engineers commissioning a TM SIWAREX WP341 HF (article number 7MH4900-2AA01) on a SIMATIC S7-1515F-2 PN (article 6ES7515-2FM02-0AB0) frequently encounter the same sequence of events:

1. The example project WP341_READY_FOR_USE is downloaded from Siemens Product Support.
2. The default FB number (FB1 for the weigh block, FB1000 for some HF versions) collides with an FB already in use by the safety program, by a third-party library, or by a previously integrated Siwarex module (WP321, WP351 HF).
3. The engineer renumbers the block to an available slot, for example FB3100, hoping to keep the safety FB at FB1.
4. On the next Compile > Software (rebuild all) pass, the compiler silently renumbers the block to the next free slot or, when renumbering is performed manually, refuses the operation with the diagnostic buffer event shown below.

1.1 Observed Diagnostic Buffer Entry

The CPU diagnostic buffer records the event with error code 604:864. The full text reads:

An internal consistency error has occurred. Please compile the program in this CPU again. The following blocks could not be compiled: WP341 [FB1000]

The block number in square brackets varies between installations (FB1, FB1000, FB3100, FB351, etc.) depending on the slot chosen by the engineer. The behaviour is identical regardless of the absolute number: the block is generated in the offline tree but the download/compile cycle terminates with a fatal consistency check.

1.2 Affected Hardware and Firmware

The same error pattern has been reported on WP321 commissioning (article 7MH4900-3AA01) and on the high-frequency WP351 HF module. The behaviour is platform-agnostic and is rooted in the way Siemens ships the FB library.

2. Root Cause: Know-How Protection and Block Numbering Constraints

Siemens ships the Siwarex WP341/WP351 example project with the weigh-function block stored in the Library tab. The block carries a Know-How protection attribute that encrypts the implementation section, the static data and the parameter interface, leaving only the public interface visible to the user. Know-How protection binds tightly to the following metadata:

• Block number (FBN) assigned at library creation time.
• Block checksum calculated against the protected contents.
• Block interface signature (IN/OUT/STAT/TEMP signatures).
• Timestamp and path stored in the project tree.

When the engineer renumbers the FB in the project tree (for example from FB1 to FB1000), TIA Portal updates the symbolic reference, but the internal pointer used to load the encrypted body still points at the original FBN. The compiler detects the mismatch and raises the 604:864 event. Renumbering the safety FB first, rebuilding hardware, then rebuilding software does not solve the problem, because the protected block itself is the source of the inconsistency, not the consumer.

2.1 Why the Auto-Renumbering Path Also Fails

If the engineer leaves the FB in its default slot and lets TIA Portal auto-renumber, the compiler will assign the next free number (commonly FB2 next to a safety FB at FB1). The download then succeeds in the offline tree but the runtime integrity check during GO-to-RUN transitions still fails on the first warm restart. The diagnostic buffer fills with 604:864 entries, and the CPU enters STOP with the same message shown in the HMI alarm view. The root cause is identical: the protected block's runtime loader expects a specific FBN, and the project tree no longer matches.

2.2 Why Recompiling Does Not Help

A common field attempt is to delete the block, re-import the library, and rebuild the software. This clears the offline tree but does not re-encrypt the block under a new FBN; the library file is read-only and the FBN is baked into the protected payload. The only sanctioned way to obtain a different FBN is to receive a freshly compiled library from Siemens Siwarex Support in which the block has been assigned a new number before protection is applied.

3. Prerequisites for Recovery

Before contacting Siemens or attempting the recovery path, gather the following items to shorten the support cycle:

1. The exact CPU article number and firmware version (read from the CPU's online > diagnostics > module information).
2. The exact TM SIWAREX WP341 / WP351 HF article number and firmware version (read from HW Config or from the module's web server).
3. The TIA Portal version and the installed TIA Portal service pack (e.g. TIA V18 Update 3).
4. The desired target FBN (for example FB3100) and confirmation that it does not collide with safety blocks or with other Siwarex instances on the same CPU.
5. The current TIA Portal project, archived as a .zap18 file. If the archive exceeds the email attachment limit, ask the support contact for an upload link (Siemens Industry Online Support can be used for projects up to 100 MB; otherwise Siemens SFTP).
6. Siemens support reference: [email protected] for the EMEA region and the equivalent regional alias for APAC/AMER. Provide the request in English or German.

4. Step-by-Step Recovery Procedure

The recovery is a two-stage process: first isolate the project so that the rest of the station can be commissioned, then request a custom-compiled library from Siemens to obtain the desired FBN.

4.1 Stage 1: Stabilise the Existing Project

1. Open the affected TIA Portal project.
2. Switch the safety FB that collides with the default WP341 FB1 to a free number (for example FB999). Save the safety program.
3. Do not manually renumber the WP341 FB. Leave it at its default slot (FB1 in the example project, FB1000 in the WP351 HF project).
4. Compile the project. The compile will succeed because the default FBN is intact.
5. Perform a download to the CPU. Use the option Download to target device > Extended download and tick All blocks consistent.
6. Once the download is complete, switch the CPU to RUN and verify that the WP341 faceplate in the HMI returns valid weight values.

4.2 Stage 2: Request a Custom-Compiled Library from Siemens

Siemens confirms that the FB number can be changed, but only by Siwarex Support. Send the following to [email protected]:

1. The .zap archive.
2. The desired FB number (any free number in the 1–65535 range; the WP341 example project uses FB1 by default, the WP351 HF example uses FB1000).
3. The TIA Portal version and the CPU firmware version.
4. A short description of the station (e.g. "Belt scale on line 3, 4 load cells, HF variant, 1000 Hz sampling").

Siwarex Support returns a re-compiled library in which the block is regenerated under the requested FBN and re-protected. The new library is delivered as a .zip containing a .tal file (TIA Library) and an updated WP341_READY_FOR_USE_Vxx_yyy.zzz example project.

4.3 Stage 3: Integrate the Custom Library

1. Extract the .zip and double-click the .tal file. TIA Portal opens the library in a separate window.
2. In the project, right-click the Libraries tab and select Update library against the master data of the new library.
3. Delete the old WP341 block from the program blocks container.
4. Drag the new copy from the library into the program blocks container. Confirm the prompt to overwrite the existing instance DB.
5. Recompile the project (Software > Compile).
6. Download to the CPU. The 604:864 event should not recur.

5. Verification

After the custom library is integrated, perform the following checks to confirm the fix is stable:

1. Open Online & diagnostics > Diagnostic buffer on the CPU. There should be no further 604:864 events related to the WP341 FB.
2. Set the CPU to STOP and back to RUN. The CPU should enter RUN without any consistency error.
3. Open the WP341 faceplate on the HMI. The status field should read READY or RUN depending on the configured operating mode (per the TM SIWAREX WP341 HF Operating Instructions).
4. Apply a calibration weight and trigger a calibration. The weight display should track the physical mass within the configured tolerance (typically 0.05 % for the HF variant).
5. Cycle power on the ET 200SP station or S7-1500 line. Reconfirm the RUN state and the weight display.

6. FBN Selection: Best Practice

When choosing the new FBN, apply the following guidelines to avoid future collisions:

• Reserve the lower FBN range (1–100) for safety blocks; Siwarex blocks can be placed above 1000 to keep a clear visual separation in the project tree.
• For multi-module stations (e.g. a WP341 plus a WP351 on the same CPU), use distinct ranges, e.g. WP341 at FB1100 and WP351 at FB3100.
• Document the chosen FBN in the project header comment of the safety program and in the station documentation so that future maintenance engineers do not re-introduce a conflict.

7. Differences Between WP321, WP341 and WP351 HF

The same 604:864 error has been observed on all three modules, and the same recovery procedure applies. The only difference is the default FBN assigned to the protected block in the example project, which is why some users report the error with FB1, others with FB301 or FB1000.

8. Configuration Parameters and Error Code Reference

8.1 Diagnostic Buffer Event 604:864

8.2 Key Scale Parameters (read from the WP341 data record)

9. Cross-Platform and Edge-Case Notes

• On ET 200SP CPU 1510SP-1 PN stations, the WP341 module is plugged into a free slot of the BaseUnit. The default FBN is unchanged, and the 604:864 event behaves identically.
• If a WinCC Comfort/Professional faceplate is in use, deleting and re-inserting the WP341 FB invalidates the HMI tags bound to the instance DB. Re-link the tags after the new library is integrated.
• Projects migrated from TIA V16 to V18 using the standard TIA migration tool sometimes carry the protected block with the original FBN but a V18-specific block checksum. If the 604:864 event appears immediately after a migration, repeat the request for a custom library and specify both the source and target TIA version.
• Stations running a mixed S7-1500 / S7-1200 topology should consolidate the Siwarex block on the S7-1500 CPU; S7-1200 does not support the WP341 HF firmware variant.

10. Preventive Maintenance Recommendations

1. Store the master copy of the WP341 library in a separate, version-controlled location outside the active TIA Portal project. The library is read-only and should be re-imported at the start of any new machine project.
2. Maintain a station log that records the FBN assigned to every Siwarex block, the safety FBNs, and the date of the last custom-library update from Siemens.
3. Subscribe to the Siemens Siwarex firmware RSS feed to be notified when the WP341 HF firmware is updated. A new firmware release sometimes requires a re-issue of the example project to clear latent checksum mismatches.
4. Run a full software-rebuild at the end of every commissioning to validate that the protected blocks have not been silently re-numbered by the compiler.

11. Frequently Asked Questions