Resolving Omron NS5-SQ V6.2 Real Number Entry Corruption on HMIs

An Omron NS5-SQ-2 V6.2 running a project built in NS Designer appears to corrupt decimal values entered from the touchscreen. The PC-based Test Tool in NS Designer shows the entry object behaving correctly, but the moment the same project is downloaded and operated on the physical NS, an entered value such as 998.7 is silently rewritten to something like 996.0. The numeric pattern — the value lands on a whole number with the fractional part dropped or rounded — is the signature of a memory aliasing fault, not a display driver bug. This article documents the root cause, the exact field fix, the supporting NS system-memory map, and a verification procedure so the same fault cannot reappear in future screen designs.

1. Problem Summary

The reported symptom has the following reproducible characteristics:

• A Number Input object is placed on an NS screen, configured for decimal real number entry.
• Its storage address is set to the NS internal word area, e.g. $W0 and $W1 (a 32-bit floating-point pair for a single-precision real).
• No host PLC is connected, and the PLC is not writing to that location — the value lives entirely inside the HMI's internal memory.
• In NS Designer → Test Tool, typing 998.7 stores 998.7 as expected.
• After Transfer to NS, typing 998.7 on the touch panel yields a different value, for instance 996.0.
• Other entered numbers are also altered; the alteration is not random but deterministic, depending on the current screen and the HMI's internal state.

2. Product and Software Context

The platform in question is the Omron NS5-SQ-2 with system version 6.2 of the NS-series runtime. The NS5-SQ is a 5.7-inch STN QVGA (320 × 240) monochrome HMI in the NS family, supported by NS Designer (CX-Designer, also branded as NS-Designer for the NS-series). System version 6.2 is the final common revision for the NS5/ST5/ST6 hardware generation before migration to the NB and later NA families.

Key references:

• Omron NS-series HMI product page
• NS5-SQ series catalog listing
• Omron Technical Support / MyOmron documentation portal
• NS-Designer Operation Manual (V08/V09) and NS-series Setup Manual — searched under "NS" and "NS Designer" on the Omron Industrial Automation site.

The runtime maintains an internal word area used for retentive data, system markers, and screen-state values. User projects commonly map Number/Word Input and Display objects to this area. The trap is that some of the addresses in the leading portion of the internal word area are pre-allocated to system functions, and writing to them from a screen object overwrites the system data — which is then re-overwritten on the next system tick.

3. NS Internal Memory Architecture

NS Designer exposes several host-side memory pools in the address dialog:

The system word area in the NS runtime is occupied at the lowest-numbered internal word addresses. The exact layout is model- and version-specific, but for NS5-SQ-2 system version 6.2 the canonical layout is:

Every cycle the NS runtime writes the active screen number into $SW0 (i.e., the same storage backing $W0 in the $W-area view). If a user Number Input object has its Storage Word Address set to $W0, the input writes a 32-bit real across $W0 and $W1, and the very next system tick overwrites the high word back to the current screen number — exactly producing the "decimal portion gets clobbered" symptom observed on the NS5-SQ V6.2.

4. Root Cause: System Memory Overlap at $W0

When the engineer selected $W0 as the storage address for a Number Input object, NS Designer did not flag a collision because the address dialog does not warn about the system marker overlap by default. The Test Tool simulates the HMI's data-flow locally but does not run the full screen-change cycle that writes $SW0; therefore the corruption never shows up in Test Tool, but it appears on the real HMI the moment any screen transition or popup event triggers a refresh of the system word area.

The fix is to move the user variable out of the system reserved area. There are two equivalent approaches:

1. Change the storage address of the Number Input object to a user-available internal word, e.g. $W100/$W101 (any address ≥ $W16 on V6.2, with conservative headroom to $W32 or higher recommended).
2. Use an explicit host-PLC tag (e.g. PLC1_D100/D101) when the variable must be shared with the controller, removing it from the HMI's internal memory entirely.

The original poster confirmed the fix by unchecking the System Setting box that was driving the runtime to write to $W0. In NS Designer, this corresponds to PT → System Settings → Screen Number (or System Memory in the project tree): the location where the NS reserves $SW0 for the screen number can be relocated, but on V6.2 the simpler and recommended path is to leave system markers at their default addresses and keep user data out of the first 16 words of the internal area.

5. Step-by-Step Resolution

Apply the following procedure to any project exhibiting the symptom. The procedure is version-safe for NS Designer V6.x and is valid for the NS5/ST5/ST6 hardware line.

5.1 Prerequisites

• NS Designer V6.2 project file (or a backup of the live project transferred from the NS).
• The current NS Designer project open on the engineering PC.
• USB or serial cable (or Ethernet for NS15/NS12 where equipped) to transfer to the HMI.
• Access to PT → System Settings → System Memory in NS Designer.

5.2 Procedure

1. Open the project and select PT → System Settings from the menu bar.
2. Switch to the System Memory tab (or the equivalent "Allocate System Memory Area" page in V6.2).
3. Confirm the System Memory Starting Address is set to the default $W0 (or note the current value if it has been changed). This is where the NS runtime stores $SW0–$SWn.
4. Close the System Settings dialog and return to the screen editor. Select the affected Number Input object.
5. In the property grid, change the Storage Word Address from $W0/$W1 to a user-safe address, for example $W100/$W101.
   If the project also uses $W1 for a 16-bit integer, choose a fresh pair. Real numbers require a 32-bit pair; do not split the high/low words between unrelated variables.
6. If multiple Number Input objects were placed in the system area, audit Address Settings for all Input, Output, and Word Lamp components. Any object mapped to $W0–$W15 must be moved.
7. Recompile the project: Project → Compile → Check All. NS Designer will issue a warning for any object that overlaps the system area only if the strict checking option is enabled; enable Tools → Options → Check → System Memory Overlap to catch this automatically in future projects.
8. Save the project (Ctrl+S).
9. Transfer the project to the NS: PT → Transfer → To PT, then follow the dialog to send the program, screen data, and ladder (if any).
10. Cycle power on the NS to ensure all internal memory is re-initialized from the freshly transferred project.

6. Number Input Object Configuration Reference

The following parameter table summarizes the dialog settings that matter for decimal real number entry. Treat this as a commissioning checklist for any new Number Input object added to an NS project.

6.1 Recommended Allocation Strategy

• Reserve the first 32 internal words ($W0–$W31) for system use only. This is well above the documented system reserve of 16 words and provides a safety margin against future NS firmware revisions that may extend the system area.
• Group real-number variables on even-word boundaries to ensure correct byte ordering when the value is consumed by a macro or a host PLC.
• Avoid the host-PLC area for purely-HMI-internal values unless the controller is expected to consume them; this prevents unnecessary comm-cycle churn.
• Document the layout in a project comment header so that any engineer adding a new screen knows which ranges are taken.

7. Verification

After the fix is applied, verify the behavior on the actual HMI using the following checks. Do not rely on the NS Designer Test Tool as proof of correctness — it does not exercise the runtime's system-memory write path.

1. Power-cycle the NS after the transfer is complete. This guarantees the internal SRAM is re-initialized from the new project.
2. Navigate to the screen that contains the corrected Number Input object.
3. Enter 998.7 and press OK. Read back the value with a Number Display object pointing to the same address. The display must show 998.7 (or its float-nearest equivalent, 998.6999…).
4. Trigger several screen changes (use the Change Screen button to jump to another screen and back) and re-read the variable. The value must remain 998.7 after each transition. This is the critical test that would have failed before the fix.
5. Open and close a popup screen. Re-read the variable. The value must still be 998.7. Popup events also write $SW0–$SW5 and would clobber the high word of a misaligned real.
6. Run a macro that reads the value and writes it to a known host address. Confirm the host value matches the HMI value to the LSB.
7. Save the working project as a baseline; the symptom will not reappear unless a future screen change re-uses the system area.

8. Common Secondary Symptoms and Their Cures

Other value-corruption patterns reported on the NS family map cleanly onto the same memory-aliasing root cause. Use the matrix below to triage any related issue without re-deriving the cause.

9. Project Hygiene and Future-Proofing

To prevent this class of fault on future projects, configure the NS Designer development environment and follow a project-level memory-allocation convention.

1. Enable strict address checking. In NS Designer, go to Tools → Options → Check and enable the option that flags writes to the system area. This produces a compile-time warning rather than a runtime mystery.
2. Export the address table. Project → Address Table → Export to CSV (or the equivalent in V6.2). Review this CSV in any peer review; it is the only way to detect overlapping allocations between a screen object, a macro, and a host tag.
3. Reserve a memory band per function. Document a convention such as $W32–$W63 = operator-entered values, $W64–$W127 = derived values, $W128–$W255 = alarm/event buffer. Stick to the convention across the project.
4. Use symbolic names in the address table rather than raw $W offsets, so the screen designer never needs to know the underlying address and the boundary check can be enforced by tooling.
5. Validate on hardware, not just in Test Tool. Add a step to the project's commissioning checklist: enter a real number, change screen, re-read.
6. Lock the system-memory base address. Do not move it from $W0; leave system markers at the default so that documentation and field troubleshooting reference the same offsets.

10. Compatibility, Migration, and Field Notes

The NS5-SQ-2 V6.2 platform is the last generation of the classic NS family. The same memory map and the same fix apply to:

• NS5-SQ (5.7" STN, monochrome, function-key + touchscreen variants)
• NS5-TQ (5.7" TFT color)
• NS8, NS10, NS12, NS15 with system version 6.x

On later platforms (NB-series, NA-series), the equivalent internal memory is exposed as $W on NB and as tag-based variables on NA. The same principle applies — avoid the system-reserved address range documented in the runtime help — but the offset and the function name will differ. Always consult the System Settings → System Memory page of the new platform's IDE before placing new variables.

When migrating an NS project to NB/NA, perform a memory-allocation audit as part of the conversion. Address offsets are not guaranteed to map across platforms, but the system area will be re-reserved and any collisions will need to be re-resolved at the new offsets.

11. Quick Reference Checklist

• Symptom: real number entered on NS panel becomes a different whole number.
• Test Tool: passes. Hardware: fails.
• First suspect: $W0–$W15 overlap with system markers.
• Fix: move the Number Input storage address to ≥ $W32 (32-bit pair on even boundary).
• Verify: enter a real value, change screen, re-read, open and close a popup, re-read.
• Prevent: enable compile-time overlap check, document a memory band convention, export the address table for review.
• Document: NS-Designer Operation Manual and Setup Manual sections on System Memory and Number Input for the exact offsets of your firmware version.