Omron NS vs NA HMI: Migration, Mapping and Worked Tests

Omron NS and NA are different HMI engineering environments. A replacement project needs a verified communication path, a data interpretation plan and behavioural tests for the screens. Matching panel size or reproducing the old layout does not establish that an operator will read and change the correct controller values.

For an existing Omron NS installation, begin with the exact panel model, controller model and recoverable project files. For a new learning project, establish which HMI the course actually uses. This guide explains the distinction, corrects common migration assumptions and develops a fictional numeric-display exercise that you can use to evaluate your understanding before a supervised native practical.

NS versus NA: what changes in the engineering work?

Omron identifies CX-Designer as its NS-series HMI software. Older project records may mention NS-Designer; establish the installed engineering software and project compatibility rather than treating every historical tool name as interchangeable. NA engineering belongs in the Sysmac environment, with its own HMI configuration and variable mapping.

Decision	NS project investigation	NA replacement investigation
Engineering files	Recover the editable project and associated resources	Establish the target project and supported software version
Controller connection	Record the actual host, protocol and addresses	Verify the target driver and device configuration
Displayed values	Identify storage type, encoding and scaling	Map each value with its intended interpretation
Operator actions	Record what a press, release or confirmation does	Recreate and test the required behaviour
Acceptance evidence	Capture representative baseline observations	Compare the same cases and document intentional changes

The table is a project planning method, not a declaration that every NS function has a direct NA counterpart. Use the Omron controller selection guide when the controller is changing as well. Replacing both devices expands the scope: an HMI issue can otherwise become confused with a changed PLC program or interface.

Avoid choosing a panel solely because a course calls it modern. For a maintenance learner, the valuable practical may involve the existing NS toolchain. For someone preparing a new Sysmac project, native NA configuration may be more relevant. State the equipment and task that the learning needs to support.

There are manufacturer replacement guides

Omron publishes two useful references: V469, the NS-to-NA replacement guide, and V470, the procedure for creating replacement project data. Their existence makes a blanket claim that migration is simply an unsupported manual redraw misleading.

V470's stated procedure concerns CJ-series connections and a particular FINS migration context. It separates communication settings, common resources, screen creation and debugging. It also warns that NS CHANNEL values need an actual supported data type for NA. Its spreadsheet procedure preserves addresses as text so that bit-address information is not lost. Read the guide's scope before applying the procedure to a different controller or connection.

This documentation does not establish that an arbitrary project converts completely with one click. Ask the supplier which supported tools and services apply to your exact source and target. Obtain a list of unresolved functions and the required review work. A successful import can be an intermediate result while the operational behaviour remains unverified.

Do not budget a fixed number of engineering days from screen count alone. Two projects with ten screens may differ substantially in scripts, recipes, controller writes, languages and unsupported features. A more useful estimate follows an inventory and a small representative migration trial with recorded findings.

02

Build an inventory around meaning, not appearance

Start with one screen and list each object that reads or writes a controller value. For each object, record the source device, address or variable, direction, type, units and expected range. Include whether a displayed number is a live value, a stored setting or a calculated result. An attractive label cannot recover missing information about its source.

Then record behaviour that only appears during interaction. Does a button write while pressed, toggle a state or submit a request? Does leaving the page change anything? Is a numeric entry applied immediately or after confirmation? These are questions for observation and documentation, not assumptions to infer from a button's colour.

Keep text and language resources in the inventory. A word that fits on one display can truncate on another, and a changed unit label can make an otherwise correct numeric mapping misleading. Test the longest relevant strings and the states that reveal them. Include alarm messages and input validation messages, not only the normal running page.

Finally, record dependencies outside the visible object. A display may rely on a PLC calculation, an HMI subroutine or a shared internal value. The Sysmac variable guide helps frame ownership and scope questions. Preserve the dependency chain so that a replacement does not accidentally calculate a value twice or remove a required conversion.

HMI variables are not automatically the PLC's global memory

An integrated engineering project can simplify configuration, but the controller and HMI remain distinct devices with an interface between them. Write down which controller value is mapped to which HMI value and what the object uses. Similar names are useful for readability; they are not evidence that the correct connection exists.

For a read-only measurement, trace from the controller source to the displayed result. For an editable setting, trace the other direction as well, including validation and confirmation. Decide which device owns the accepted operating value. A local editing field and the controller's active setting may legitimately differ while an operator is preparing a change.

In a training exercise, expose these intermediate values on a diagnostic page. Showing requested and accepted settings separately makes it easier to diagnose a rejected write. It also helps distinguish a communication problem from an application rule that correctly refuses an invalid request. Do not hide every intermediate state behind a single green indicator.

The communication troubleshooting guide develops a useful sequence for separating configuration, transport and application behaviour. Apply that reasoning to the actual documented driver. Do not assume that changing from NS to NA makes every address, network parameter or controller interface unnecessary.

Worked example: preserve a signed temperature display

The following is a fictional data interpretation exercise. It is not an Omron native project, a recommended machine configuration or a measured migration result. Its purpose is to make a common acceptance problem testable: the new screen can show a plausible number while interpreting the stored bits incorrectly.

Assume a controller interface supplies one unsigned 16-bit word containing a signed two's-complement temperature in tenths of a degree Celsius. The exercise accepts a present, good-quality whole-number word from 0 through 65,535. The permitted engineering range is minus 40.0 through plus 125.0 degrees Celsius, inclusive.

Interpret words below 32,768 as non-negative signed counts. For words at or above 32,768, subtract 65,536 to obtain the signed count. Divide that count by ten for the temperature. Check the engineering range after decoding. This order matters: a valid storage word can still describe an unacceptable engineering value.

The screen has three result categories. Accepted means the data is available, structurally valid and within the declared temperature range. OutOfRange means a valid word decodes outside that range. Unavailable covers missing data, bad quality or a value outside the declared storage contract. These labels belong to this exercise; they are not claimed NA object defaults.

03

Calculate representative values before configuring the display

Stored word	Signed count	Temperature	Expected category
0	0	0.0°C	Accepted
250	250	25.0°C	Accepted
1,250	1,250	125.0°C	Accepted
1,251	1,251	125.1°C	OutOfRange
65,136	−400	−40.0°C	Accepted
65,135	−401	−40.1°C	OutOfRange
65,535	−1	−0.1°C	Accepted
32,768	−32,768	−3,276.8°C	OutOfRange

For the word 65,136, the signed conversion gives 65,136 minus 65,536, which is minus 400. Dividing by ten produces minus 40.0. Treating the same word as an ordinary positive integer instead gives 6,513.6 degrees after scaling. The error comes from interpretation, even though the word arrived successfully.

A wrong scale factor is a different defect. The word 250 should display 25.0. Dividing by one hundred produces 2.5, while multiplying by ten produces 2,500. A good acceptance set includes a positive value that exposes scaling and a negative value that exposes signedness. Zero alone catches neither defect.

The data conversion reference explains why storage, encoding and engineering units should be documented separately. In a real NS replacement, establish the actual old representation from the project and controller interface. Do not assume that every word uses this fictional signed-tenths convention.

Quality and invalid inputs are part of the display contract

Give the model the word 250 with bad quality. The result is Unavailable, not an accepted 25.0-degree reading. Give it no word at all and the result remains Unavailable. A displayed historical value may be useful in a separately labelled history view, but it must not silently stand in for a current accepted observation.

Now test minus one, 65,536 and 12.5 as supplied storage values. All violate the unsigned whole-word input contract and therefore produce Unavailable. They must not be silently wrapped, truncated or rounded into valid words. Such coercion would invent a meaning that this interface has not authorised.

Next change the upper engineering limit to 100.0 degrees while retaining the same encoding. The word 1,250 then becomes OutOfRange. Nothing about the stored bits or signed decoding changed; the acceptance requirement changed. This is a useful way to distinguish conversion code from application validation during review.

Extend the acceptance test to operator writes

Reading a temperature does not prove that editing a setting is correct. For a separate fictional setting, suppose the operator may request whole degrees from 10 through 80. A proposed value of 35 can be accepted, while 9, 81 and 35.5 must be rejected under that contract. The controller's accepted value should remain visible when a request is rejected.

Do not infer write success from a button animation. Record the requested value, the acceptance result and the value subsequently read from the authoritative source. A button can animate locally while the controller rejects or never receives the request. The visible feedback should help the learner distinguish those outcomes.

Include navigation in the test. Prepare a value, leave the page and return before submitting it. Decide explicitly whether the draft should persist or be discarded. Either policy can be reasonable for a teaching exercise if it is clear and tested. An accidental change caused by page entry is a different behaviour and needs investigation.

These exercises do not specify a complete command protocol or a safety function. They provide small, observable requirements for learning HMI data flow. If a real system requires acknowledgements, transaction identifiers or interlocks, those belong in the actual interface design and its supervised verification.

04

Check scripts, alarms and recipes individually

V469 describes differences between NS macros and NA subroutines, including the use of a supported Visual Basic environment on NA. It also distinguishes variable mapping, data types and functions that need alternative treatment. This is a reason to review each used function against the manual, not to assume that changing a file extension preserves its execution behaviour.

For your own inventory, write the trigger and intended effect next to each script. A routine triggered when a page opens can behave differently from one triggered periodically. Test a repeated trigger and an interrupted interaction. Record which state survives and which is recomputed. A successful build does not answer these behavioural questions.

For alarms, test occurrence, acknowledgement, return to normal and a second occurrence. Verify the message, source condition and displayed history separately. A migrated alarm list can look complete while pointing at the wrong condition. Use distinct test values or conditions so that each mapping can be identified without ambiguity.

For recipes, compare the intended parameter set with the values actually accepted by the controller. Include one invalid field and determine the specified response. Do not assume the transfer is atomic, or that an unchanged display proves no partial change occurred. Obtain the native feature's documented behaviour and test the application around it.

NS has simulation support; simulation still has limits

The CX-Designer user manual documents simulated PT testing and integrated simulation with a virtual PLC through CX-Simulator. Therefore, an assertion that NS testing always requires a physical panel is incorrect. The historical NS-series data sheet also describes integrated screen and ladder simulation. Confirm the versions and supported combination for the project you intend to practise.

Use simulation to check the behaviours it can represent, and label the resulting evidence accurately. It does not by itself demonstrate physical touch response, the installed network, field wiring or the timing of a deployed machine. A classroom exercise can be valuable without making those wider claims.

Prepare a comparison sheet with the same cases for the old environment and the replacement environment. Record expected behaviour before running either version. If both versions reproduce the same old defect, agreement alone does not establish correctness. Separate requirements that should be preserved from defects that the replacement is meant to correct.

For a South African training buyer, Omron's TC55 Sysmac NA HMI outline identifies native NJ/NA practical equipment, variable mapping and simulation among its topics, with TC051 preparation indicated. Ask about the actual delivery date, access and assessment; the outline is not a confirmed local booking.

05

Questions about Omron NS replacement and NA training

Can I replace an NS panel by copying its screenshots?

Screenshots help preserve layout and wording, but they do not contain the complete communication configuration or object behaviour. Recover the project and document the interface. Use images as a visual reference alongside a mapping inventory and acceptance cases, then record any functions that require redesign.

Does a Sysmac project mean the HMI automatically uses every PLC variable?

No. Verify the configured device relationship and mapping for the values the HMI needs. Record direction, type and units. A shared engineering environment can assist the workflow, but matching names and a successful build do not prove that an object is connected to the intended live source.

Is NS-to-NA migration always a completely manual rebuild?

Omron provides detailed replacement documentation. Determine which supported workflow and assistance apply to your exact project rather than making an absolute claim about all migrations. Plan to review unresolved functions and test the resulting behaviour even when tools help move project data.

Which values make a good numeric-display test?

Use a normal positive value, zero, a negative value when permitted, both engineering boundaries and values just outside them. Add missing or bad-quality data. In the signed-tenths example, 250 exposes scaling while 65,136 exposes signed interpretation; the boundary pair 1,250 and 1,251 checks inclusive acceptance.

Can general browser simulation replace the native HMI practical?

It can support transferable reasoning about values, conditions and operator feedback. This site is commercially connected with PLC Simulation Software; its HMI simulation resources provide a related preparation route. Check current supported features. They do not establish NS project conversion or native NA runtime compatibility.

Leave the course with evidence of a working interface

A useful portfolio item includes the source-to-display map, declared units, expected cases and observed results. Add an explanation of at least one incorrect mapping and the test that exposed it. Label paper calculations, general simulation and native panel observations separately so another person can understand what you actually demonstrated.

The PLC program testing resources offer further general practice. For the wider learning route, return to the Omron PLC training hub. Choose the next exercise from an unresolved interface question rather than assuming that a visually finished screen means the engineering is complete.

06