Siwarex WP522 Zero Command Failing: Troubleshooting finishedError

Siwarex WP522 Zero Command Failing: Troubleshooting finishedError

The Siwarex WP522 ST is Siemens' two-channel weighing electronics module for SIMATIC S7-1500 and ET 200MP, designed primarily for non-automatic (static) scales. A recurring commissioning failure on WP522 systems is the zero command (CMD_CODE 1001) returning FinishedError while the trigger sequence runs to completion, leaving the scale un-zeroed and the gross weight reference unchanged. This article documents the failure mechanism, parameter dependencies inside the SiwarexDB user block, and the field-proven diagnostic workflow that resolves it.

Overview

The Siwarex WP522 integrates directly into the S7-1500 backplane through the Technology Module (TM) interface and exposes its full functional range as Data Records (DR) accessible via the supplied SiwarexDB function block. Zeroing is not an automatic background operation; it is an explicit command that the user program issues through the SiwarexDB command interface. When that command is rejected by the firmware, bit FinishedError becomes TRUE while InProgress and FinishedOK remain FALSE, and a 2-second error window opens in which DBW534 (s_IO_DATA.DATA_COMMAND_ERRORS_1) carries the reason code.

The Siemens manual Siwarex WP521 ST / WP522 ST Manual lists zeroing, taring, and scale calibration as the basic weighing functions. The TIA Portal product description confirms these basic functions include zeroing, taring, calibration with test weights or by calculation, plus Set to zero trace signal recording — see SIMATIC S7-1500 ET 200MP Manual Collection — Siwarex WP521/WP522 Properties.

Siwarex WP522 Command Interface Architecture

Every WP521/WP522 command is executed through the Siwarex user block interface. The channels (two per WP522) use identical fields with different prefixes (CH1_, CH2_). The relevant fields used during a zero operation are:

Exact DB offsets depend on the SiwarexDB instance the user inserted. Verify offsets against the SiwarexDB block header in your project. Channel 2 is offset by +20 bytes for the status/error group and +44 bytes for the process data.

Command Codes Recognized by WP522

The CMD_CODE field accepts the values listed below; values not enumerated here are reserved by Siemens and must never be written to the channel:

For zeroing the user writes 1001 to CMD_CODE, sets CMD_TRIGGER with a rising edge, and waits for either CMD_FINISHED_OK or CMD_FINISHED_ERROR. Failure surfaces as FinishedError with a reason inside DBW534 (DATA_COMMAND_ERRORS_1).

Symptom: CMD_CODE 1001 Returns finishedError Instead of Zero

The exact symptom reported is:

• SiwarexDB shows CMD2 finishedError for the zero command instead of finishedOK.
• The process output Gross (or equivalent process value) does not update to the new zero reference.
• No change is observed in DR30 (or any DR associated with the calibration reference).
• The transient state InProgress is observable briefly while the firmware checks feasibility, then collapses to FinishedError.

Because the SiwarexDB consumes the result code on its own handshake (a fixed 2 s window), the most actionable diagnostic is to read DBW534 = s_IO_DATA.DATA_COMMAND_ERRORS_1 within those two seconds, normally via a VAT/Operator Panel or break-point observation in the user program.

Root Cause: Command Rejection by Firmware

The Siwarex WP522 firmware rejects the zero command when one or more of the following pre-conditions fail:

1. Out-of-range deviation from current zero — the gross load is outside SEMI_AUTO_ZERO_LIMIT_NEGATIVE / SEMI_AUTO_ZERO_LIMIT_POSITIVE in DR3.
2. Excessive scale drift from the configured load limits — measured gross weight is greater than or equal to MAX_WEIGHT in DR3.
3. Scale is not stable — the stability detector (DR8) does not confirm a stable weight within the configured timeout.
4. Scale is not calibrated — first-time commissioning attempt before any calibration has been performed.
5. Hardware fault on the load-cell channel — sensor impedance drift, broken wire, or sense-line fault flagged through DATA_STATUS bits before the command was issued.
6. Command handshake error — bit CMD_TRIGGER was not cleared between two consecutive commands, leaving the interface locked.

If the gross weight being read before the command is already outside the configured zero range, the firmware will reject the zero command without ever driving InProgress high for more than a single firmware cycle. This is the most common cause of the symptom described.

Required DR3 Parameters for Successful Zeroing

DR3 carries the load-side limits that constrain every zero and tare operation. Before retrying CMD_CODE 1001, verify these values:

The two SEMI_AUTO_ZERO_LIMIT_* parameters define the offset band around the previously stored zero point within which the firmware will accept a new zero. If the hopper carries residual product, the empty-vessel weight can already exceed this window and CMD_CODE 1001 will be rejected.

Field Engineering Rule

A rule of thumb used in commissioning is:

|SEMI_AUTO_ZERO_LIMIT_POSITIVE| ≥ MAX_WEIGHT × 0.02 d

where d is the resolution the application requires (digit). For a 1000 kg / 0.1 kg scale, this yields a positive limit no smaller than 2.0 kg. Setting these limits too low is the single most common commissioning error on WP522 cells.

Zero-Tracking Configuration in DR7

DR7 hosts the zero-tracking (automatic zero correction) feature. If zero tracking is enabled with an aggressive band, the firmware silently drifts the zero point while the scale is empty, which can interact with the semi-automatic limits in DR3. Verify the following DR7 entries before a zero command:

Setting ZERO_TRACKING back to 0 before the first user-driven zero command prevents the firmware from overriding the user's zero with its own auto-zeroing correction.

Stability Detection Requirements (DR8)

The WP522 performs zeroing only on a stable weight reading. The stability detector reads two values in DR8:

If the load cell is exposed to mechanical vibration (filler line close to a hopper, conveyor-coupled equipment) the stability detector can spend its full time window re-sampling. Increase STABILITY_RANGE by one digit step at a time and decrease STABILITY_TIME in 0.1 s increments until the zero command returns FinishedOK with a stable empty vessel.

DBW534 Error Code Interpretation (DATA_COMMAND_ERRORS_1)

DBW534 is a 16-bit status word that the firmware populates with the reason for the most recent command rejection. Typical bit definitions are:

Bit assignments are documented for the WP521/WP522 ST firmware; if your project uses an older SiwarexDB revision (V2.0 or earlier), compare the bit definitions in the block's symbol comments. Capture DBW534 within 2 seconds of FinishedError going TRUE — afterward, the firmware overwrites it.

Recommended Capture Logic in STL

A "WP522_DB".CMD_FINISHED_ERROR;     // channel 1 example
FP "edgeFinishedError";
JCN NOER;
L "WP522_DB".DATA_COMMAND_ERRORS_1; // DBW534
T "capturedErrorCode";                 // MW200 for analysis
NOER: NOP 0;

This stores the rejection code into a separate marker word for later inspection. Without a positive edge on FinishedError the value rolls over after the 2 s window.

Diagnostic Workflow Using Siwatool

Siwatool V07 is Siemens' service tool for offline analysis and parametrization of WP521/WP522 modules. It can be coupled to the running system (RS-232 service interface on the WP module, then via the backplane bus) and shows the live Data Records, current process values, and command history.

1. Connect Siwatool V07 to the WP522 service port.
2. Open Service → Online, select the channel.
3. Read DR3, DR7, and DR8 to display the current parameter set.
4. Switch to Diagnosis view and read Gross / Net / Tare live.
5. Use Commands → Zero scale from Siwatool. If Siwatool returns OK, the firmware, hardware, and calibration are all valid and the user program handshake is at fault. If Siwatool itself reports an error, the problem is environmental and the same DBW534 bit will appear.

The Siwatool path is valuable because it bypasses your PLC code and therefore any application-side handshake bug. Always run this test before changing PLC logic; it localizes the fault to the module firmware or to the application code.

Step-by-Step Zeroing Procedure (Application Side)

The full sequence is:

1. Ensure the scale is empty, level, and the load cell is mechanically decoupled from vibration sources.
2. In the SiwarexDB, verify CMD_TRIGGER = 0 and CMD_FINISHED_OK = 0 for the target channel.
3. Write 1001 to CMD_CODE.
4. Set CMD_TRIGGER to 1 for exactly one PLC cycle.
5. Reset CMD_TRIGGER to 0. The firmware drives CMD_IN_PROGRESS TRUE.
6. Poll CMD_FINISHED_OK and CMD_FINISHED_ERROR. If FinishedOK goes TRUE within the watchdog window (default ~5 s), the new zero is captured.
7. If FinishedError goes TRUE, capture DATA_COMMAND_ERRORS_1 from DBW534 within 2 s.
8. Acknowledge the result in your PLC by resetting internal status flags; the SiwarexDB typically clears CMD_IN_PROGRESS automatically once both finished flags have been read.

Ladder Equivalent of the Zero Trigger

|       startOneShot            oneShotMemory     CMD_FINISHED_OK
|----[/]----[/]--------------------(S)---------|---|/]-----------------( )--|
|                                                           zeroComplete  |
|              CMD_CODE = 1001 (const)                                ( )|
|-----------------------------------------------------------------------|
|              CMD_TRIGGER                                            ( )|
|-----------------------------------------------------------------------|

The startOneShot flag should be generated only on a user request and cleared either by the operator or after FinishedOK / FinishedError returns TRUE. Use one-shot logic — leaving CMD_TRIGGER high across two consecutive commands will lock the command interface.

ST Equivalent

// WP522_DB — example handle for channel 1
IF bZeroRequest AND NOT WP522_DB.CMD_TRIGGER THEN
   WP522_DB.CMD_CODE := 1001; // zero scale
   WP522_DB.CMD_TRIGGER := TRUE;
   bZeroRequest := FALSE;
END_IF;

IF WP522_DB.CMD_TRIGGER AND (WP522_DB.CMD_FINISHED_OK OR WP522_DB.CMD_FINISHED_ERROR) THEN
   WP522_DB.CMD_TRIGGER := FALSE; // handshake reset
END_IF;

IF WP522_DB.CMD_FINISHED_ERROR THEN
   wCapturedErr := WP522_DB.DATA_COMMAND_ERRORS_1; // DBW534
END_IF;

Verification Procedure

After a successful zero command, validate three independent signals:

1. SiwarexDB status bits — CMD_FINISHED_OK = TRUE and CMD_FINISHED_ERROR = FALSE.
2. Process weight — read the cyclic Gross process value from the SiwarexDB. It should read between −0.5 d and +0.5 d (zero ± one digit) with the vessel empty.
3. Siwatool cross-check — the live gross weight on Siwatool should match the SiwarexDB cyclic value to the digit.

Apply a known calibration weight (typically 50 % or 100 % of NOMINAL_LOAD) and confirm the gross reading matches the weight to within the configured tolerance. Acceptance tolerance is normally ±0.1 % of NOMINAL_LOAD for non-automatic scales.

Field-Validated Engineering Notes

• Some SiwarexDB versions report InProgress for only one firmware cycle when the command is rejected immediately (out-of-range). If you never observe InProgress TRUE, the rejection reason is in DR3 limits — not in stability or calibration.
• Always capture DBW534 with a positive-edge detector on FinishedError; without it the value can roll over and your diagnostic pointer will read garbage.
• When scaling up from a WP521 (single channel) to a WP522 (two channel), remember that the second channel offset differs by approximately +20 bytes. A common mistake is reading channel 1's error into channel 2's status word, which appears as a "non-functional" zero command.
• If a manual zeroing sequence fails after replacing the load cell or re-cabling the junction box, recalibrate via CMD_CODE 1003 / 1004 before issuing CMD_CODE 1001.
• Always discharge the empty vessel vibration — mechanically isolate the load cell from conveyor / mixer / fan mountings before sending the zero command.

Prevention and Best Practices

1. Define SEMI_AUTO_ZERO_LIMIT_POSITIVE / SEMI_AUTO_ZERO_LIMIT_NEGATIVE during commissioning and store the values in the project backup.
2. Disable DR7 ZERO_TRACKING during the first user-driven zero; enable only after the empty-vessel reading has stabilized within the DR3 limits.
3. Capture DBW534 on a positive edge of FinishedError and surface the bit pattern on your HMI alarm screen to accelerate root cause analysis.
4. Confirm in TIA Portal that the SiwarexDB block instance is configured for the correct number of channels (1 for WP521, 2 for WP522).
5. Document calibration (CMD_CODE 1003 / 1004) and zero (CMD_CODE 1001) sequences in the O&M manual so that operators can re-run them after maintenance.

FAQ