Troubleshooting M221 Signed Integer Comparison Errors

The online monitor shows %MW0 = -6, yet a comparison against zero remains TRUE. Start by separating a simulator defect from a controller-runtime result. The reported mismatch reproduces in the Machine Expert Basic V1.4 simulator, does not reproduce in the V1.3 simulator, and has not been established on a physical M221 running firmware 1.14.1.

Commissioning Decision Path

1. Read the execution target. Record whether the project is running in the V1.4 simulator, the V1.3 simulator, or a physical M221. If it is V1.4 simulation, continue with the conversion test. If it is V1.3 simulation, investigate project typing and writes because that simulator did not show the reported fault. If it is a controller, record its firmware and run the isolated hardware test below.
2. Read the operand at the comparison. Monitor %MW0 immediately before the comparison executes. Do not move on until the displayed value is stable at -6 and no force, animation table, communication client, or other network writes to that address.
3. Read the Boolean result. Evaluate the expression using the project’s original operand and zero. For %MW0 >= 0, a signed value of -6 must produce FALSE. A TRUE result with a stable negative operand identifies a signed-interpretation failure rather than normal comparison logic.
4. Run an explicit conversion. Replace only the diagnostic expression with DWORD(%MW0) >= 0. In the reported V1.4 simulator case, this expression returned the correct result. If the result changes from TRUE to FALSE, continue to the corrective procedure. If it does not change, recheck the monitored value, declaration, write sources, and executed network.

Runtime Target Separation

A simulator and a physical PLC are separate execution engines. Matching project logic does not prove matching type promotion, conversion, or comparison behavior. Treat a simulation-only failure as a development-tool defect until the same expression fails on the controller. Conversely, never approve production logic solely because a workaround behaves correctly in simulation.

Operand Type and Sign Check

A memory word stores a bit pattern; the instruction interpreting that pattern determines whether the high-order bit represents a sign or magnitude. The suspected V1.4 simulator path promotes the word for a wider comparison without propagating its sign. The negative word is then handled like a UINT, so its bit pattern represents a nonnegative magnitude and >= 0 evaluates TRUE.

The online display and comparison engine can therefore disagree without the stored bits changing. The monitor formats %MW0 as -6, while the comparison evaluates the promoted operand as unsigned. This explains why watching the value alone is insufficient; the diagnostic must include both the raw operand and the Boolean result.

1. Open the variable declaration or symbol definition associated with %MW0 and record its declared data type.
2. Inspect both comparison operands. A literal zero can participate in implicit type promotion, so confirm the type selected for the full expression rather than relying on the monitor’s display format.
3. Search all writes to %MW0. The failure also reproduced in a project containing only the test network, which rules out address overlap for that isolated case, but the full application still requires a write-source check.
4. Remove forces and external writes, then repeat the comparison. A changing word is a data-path problem; a stable -6 with TRUE from >= 0 is a comparison-path problem.

Explicit Conversion Test

Use the reported working expression as a controlled diagnostic:

DWORD(%MW0) >= 0

Change no other network element during this test. If the explicit conversion makes -6 evaluate FALSE, it bypasses the faulty implicit-promotion path in the affected simulator. Keep the conversion at the comparison boundary so reviewers can see where representation changes.

Do not generalize one successful zero comparison to all arithmetic. Conversion changes the operand representation presented to subsequent operators. Retest every operation that depends on signed ordering, including comparisons between two variables and any limit logic using negative thresholds. Use the project’s declared types and tool documentation to decide the intended representation; do not infer it from one displayed value.

Corrective Procedure

1. Create a minimal project containing one assignment or controlled write to %MW0, the original comparison, and a visible Boolean result.
2. Run it in the V1.4 simulator with %MW0 = -6. Confirm that the original comparison %MW0 >= 0 remains TRUE before changing the expression.
3. Apply DWORD(%MW0) >= 0. Confirm that the result becomes FALSE for -6.
4. Run the unchanged minimal project in the V1.3 simulator when that version is available. A correct V1.3 result combined with an incorrect V1.4 result isolates the regression to the newer simulator path.
5. Download the same logic to the physical M221. Record the controller firmware, including whether it is 1.14.1, and observe the original and converted expressions separately.
6. If only the V1.4 simulator fails, retain the workaround only after application-level testing and report the reproducible project through an official Schneider Electric support channel. Include the software version, controller firmware, original expression, converted expression, and value/result matrix.

Verification Matrix

Execute the matrix on every target used for commissioning: V1.4 simulation, any comparison V1.3 simulation, and the physical M221. Watch the operand and result in the same scan context. Do not accept a fix when only the negative case passes; a forced FALSE output could conceal a broken comparison unless zero and a positive value also return TRUE.

Frequently Asked Questions