Sysmac Studio Variables: Scope, Types and Array Tests

Sysmac Studio variables need more than a readable name. A useful declaration identifies the value's type, owner, scope, initial state and relationship to external data. Those decisions affect whether a program uses the intended value, whether a calculation is meaningful and whether a restart produces the behaviour specified for the application.

For Omron NJ and NX learning, start with a small variable model that you can explain and test. This guide separates native terminology from a fictional array-and-record exercise. It also corrects a common misconception: symbolic programming does not mean that Sysmac has no supported way to associate variables with particular memory addresses.

Understand the native variable categories first

Omron's NJ/NX CPU software manual, W501, describes user-defined, semi-user-defined and system-defined variables. Section 6-3 distinguishes local, global and external variables. Identically named internal variables in different POUs have separate storage.

For applicable address-based interfaces, its AT examples include %D100 and %W0.00. Check the type and attribute restrictions. Variable attributes also distinguish initial values, retention and network publication. These settings serve different purposes; verify the requirements for your controller and document revision.

The Omron controller selection guide helps place these declarations within the actual CPU's resource limits. Keep program capacity, retained variable capacity and non-retained variable capacity separate. A clear declaration model is a starting point for checking memory, not a substitute for the native project's reported allocation.

Use a variable dictionary to make meaning explicit

Before entering a large table, write a short dictionary for the values that the exercise needs. Include a name, a type, units, valid range and the routine responsible for changing it. Also state whether the value represents a request, an accepted setting, an observation or a calculated result. These distinctions make later troubleshooting much easier.

For example, RequestedSpeed and AcceptedSpeed can legitimately differ while validation is pending. MeasuredTemperature and TemperatureValid also represent different information: the number alone does not establish that it is usable. A single vague variable called Value hides these distinctions and encourages other routines to make assumptions about its meaning.

Dictionary field	Question it answers
Name	Which value are we discussing?
Type	Which kind of data is represented?
Units	What does a numerical magnitude mean?
Range	Which values are accepted by the exercise?
Writer	Which part of the program may change it?
Readers	Which calculations or displays depend on it?
Initial state	What is known before the first observation?
Restart policy	What should be preserved or re-established?

This dictionary is your design record, not an extra native language that must be imported into Sysmac. Keep it small enough to maintain. If a field is unknown, record that uncertainty and resolve it before another routine depends on the value. A guessed unit is more dangerous to reasoning than an openly unresolved one.

Global scope is access, not ownership

A shared variable can be convenient when several routines need the same accepted result. That does not mean every routine should write it. Decide which routine owns the result and expose inputs or requests through a defined interface. Otherwise, the last executed write can determine the value without that priority being obvious from the declaration.

For a learning project, start with one writer for each accepted state. If two routines appear to need control, write their competing requirements down. You may need a central decision that combines their requests, rather than two assignments that overwrite one another. The function-versus-function-block guide helps structure related interface questions.

Scope also affects observation. When two programs contain an internal variable with the same name, make sure the watch or trace identifies the intended one. A learner can otherwise conclude that the program has stopped updating when the tool is actually showing a different value. Include the owning POU in your diagnostic notes.

Omron's FAQ04630 on tracing internal variables specifies a program-qualified form such as Program1.Start_SW1, while a global variable uses its name alone. Use that documented distinction when setting up the trace. A successful expression entry should still be checked against a deliberate change in the intended source.

02

Choose a type from the data contract

Use a Boolean for a true-or-false condition when that is the actual domain. Use an integer count for a quantity that must be whole. Use a suitable numeric representation for measured values and state the scale or units. A type choice should make invalid interpretation less likely; it should not merely silence an editor error.

The distinction between a bit pattern and a signed quantity is especially useful for learners. A word received from another device may carry flags, an encoded value or part of a larger structure. Decide how it is interpreted before doing arithmetic. The data conversion guide develops this distinction with explicit examples.

Range validation remains necessary even when the type is valid. An integer can represent a negative sample count, but a count of accepted observations cannot be negative in the exercise below. Similarly, a valid numeric representation does not prove that a sensor observation has acceptable quality. Preserve both the value and its acceptance information.

Avoid inventing native storage sizes for arrays or structures from general assumptions about another programming language. If actual memory use matters, inspect the relevant manual and native project information. The exercise below specifies logical fields and values; it makes no claim about their compiled byte layout or their suitability for a particular communication payload.

Worked example: select accepted samples from a record array

This is a fictional data-processing exercise, not a native Sysmac project or a plant measurement system. It demonstrates why a structure can keep a value and its quality together, why array bounds matter and why a calculated result needs a validity indicator. The results are mathematical checks of the stated contract.

Define an array with four records, indexed from zero through three. Each record has a Value field and a Good field. Value must be a whole number from zero through 100 inclusive. Good is a Boolean supplied with that record. A record is accepted only when Good is true and Value satisfies the declared numeric domain.

The calculation scans all four records once. It sums accepted values and counts accepted records. If the count is at least two, MeanValid is true and Mean is the sum divided by the count using a representation that preserves a fractional result. If fewer than two records are accepted, MeanValid is false and the mean is unavailable.

The output is recomputed from the current four-record snapshot on every evaluation. It is not a moving average, a retained historical mean or an automatic repair of bad measurements. A previous accepted result must not silently remain presented as the current valid mean when the next snapshot contains too few accepted records.

Make the record fields travel together

Consider the records (10, true), (20, true), (90, false) and (40, true), where each pair contains Value and Good. The accepted sum is 10 + 20 + 40 = 70, and the accepted count is three. The mean is 70/3, approximately 23.3333, with MeanValid true.

A wrong implementation that ignores Good averages all four values and produces 40. Another wrong implementation sums only accepted values but divides by the array length, producing 17.5. Both can look plausible on a display. The difference appears when the expected accepted count is part of the test record.

A structure is useful here because it groups the fields describing one observation. That does not automatically guarantee that external communication updates them atomically. In a real application, the interface must establish how a coherent snapshot is obtained. This exercise assumes that its four input records are already a coherent snapshot for one evaluation.

03

Test zero, boundaries and insufficient accepted data

Four input records	Accepted count	Accepted sum	Result
(10,T), (20,T), (90,F), (40,T)	3	70	Valid, 70/3
(0,T), (100,T), (20,F), (30,F)	2	100	Valid, 50
(0,T), (0,T), (20,F), (30,F)	2	0	Valid, 0
(10,T), (20,F), (30,F), (40,F)	1	10	Unavailable
(10,F), (20,F), (30,F), (40,F)	0	0	Unavailable
(−1,T), (101,T), (30,T), (50,T)	2	80	Valid, 40
(12.5,T), (20,T), (40,T), (80,F)	2	60	Valid, 30

T and F in the table mean true and false. In the second row, zero and 100 are accepted because the range is inclusive. In the third row, a valid mean of zero must remain distinguishable from an unavailable result. Using zero as a universal error value would destroy that distinction.

The row containing minus one and 101 shows why Good alone is insufficient. Both records violate the numeric domain even though their quality fields are true. The final row shows that 12.5 is rejected under the whole-number contract. Do not truncate it to twelve and silently change the input's meaning.

For the first row, preserve the exact ratio 70/3 when reasoning about the result. A displayed decimal can be rounded for readability, but the rounding policy should be stated if an acceptance test compares formatted text. Comparing an internal numeric result and comparing a string such as 23.33 are different tests.

Recompute temporary state for each evaluation

Begin each calculation with a fresh sum of zero and count of zero. Process the current records, then produce validity and the mean. This prevents temporary accumulation from leaking between evaluations. A local variable name alone does not prove that an implementation resets it at the required point; examine the actual assignments and lifecycle.

Run the first table row, then immediately run the row with only one accepted record. The second result must be unavailable with count one and sum ten. A defective implementation that keeps the old sum and count can produce an apparently valid result based partly on the previous snapshot. Testing only a single evaluation would miss that problem.

Now run the row with no accepted records. The implementation must avoid dividing by zero. It should produce MeanValid false without inventing a mean. Decide how the unavailable value is represented in the native interface, and require every consumer to respect that indicator. An HMI should not display a stale number as though it were freshly accepted.

The Omron NS and NA HMI guide explains related mapping and display questions. If you expose this exercise through a screen, show the accepted count during debugging. That extra observation makes it much easier to distinguish a wrong divisor from an incorrect record-acceptance rule.

04

Array bounds and selection changes deserve their own tests

The declared indices are zero, one, two and three. A loop that starts at one skips the first record; a loop that attempts index four exceeds the declared range. Do not guess the native runtime's response to an out-of-range access. Prevent the invalid access in the design and consult the target's documentation when analysing actual behaviour.

Choose test data that exposes a skipped element. In the valid-zero row, removing the first zero leaves only one accepted record, making the result unavailable. In the first row, skipping index zero changes the sum to 60 and count to two, producing 30. Distinct values make the defect observable without relying on a crash.

Change the acceptance requirement from at least two records to at least three. The first row remains valid, while the two-record cases become unavailable. This is a requirement change, not an array-size change. Keep the threshold separate from the storage layout so the reason for the changed result stays clear.

Then change the numeric upper limit from 100 to 99. In the row containing accepted zero and 100, only zero remains accepted, so the result becomes unavailable. Other rows may remain unchanged. This targeted change tests that validation actually uses the declared limit instead of a hard-coded assumption elsewhere in the program.

Use native diagnostics to answer a specific question

Omron's Sysmac Studio specification documents watch views, cross references and data tracing. Cross references identify where program elements are used, while traces record selected values over time. Choose the tool according to the question rather than collecting screenshots without a hypothesis.

If the mean is wrong, inspect the current records, accepted count and sum. If the value unexpectedly changes later, inspect its writers and the execution sequence. If the wrong program instance is being observed, correct the qualified reference. These are different investigations even though each begins with a surprising number on the screen.

Make the native practical reproducible. Record the CPU model, unit version, software version, project revision and input snapshot. State whether a result was calculated on paper, checked in a local model, observed in the native simulator or measured on a controller. Those distinctions help another learner reproduce the evidence without assuming access you did not have.

A watch value changed manually is also different from a field observation. When practising with a supervised training system, record the source of each input. The watchdog and force discipline guide helps frame controlled diagnostic work and the need to restore the intended state after a test.

Initial values and retention need explicit restart tests

For this fictional calculation, the sum, count and validity are recomputed from the current snapshot. There is no requirement to preserve an old valid mean as a current result after restart. If you add a historical display later, give it a separate meaning and timestamp rather than changing the current-result contract silently.

A retained configuration setting can have a different policy. Suppose a teaching threshold is deliberately preserved between sessions. Specify what happens when it is missing, invalid or from an incompatible configuration revision. Preserving bytes is not the same as establishing that the stored setting is acceptable for the current exercise.

Test the actual restart events relevant to the native project with the instructor. Record the observed values before and after each event, and compare them with the applicable manual and configuration. Do not reduce every event to a generic cold-versus-warm slogan or assume that every download preserves the same state.

For course selection, ask whether variable lifecycle is included in the practical assessment. The South African PLC course requirements guide helps identify preparation needs. A useful lesson should let you explain why a value has its present state, not only where its declaration appears in the editor.

05

Questions about Sysmac Studio variables

Are Sysmac variables always completely independent of addresses?

No. Symbolic variables are central to the environment, but W501 documents AT specifications for applicable address-based interfaces. Use the supported syntax and restrictions for the exact controller. Do not assume that a legacy address can be pasted into arbitrary code without a declaration or mapping decision.

Can two programs use an internal variable with the same name?

The manual describes separate internal variables in different POUs. Their matching names do not make them shared storage. When tracing a program's internal value, use the documented program-qualified reference and verify it with a deliberate change in that program's test data.

Why does the average exercise need MeanValid?

Zero is a legitimate mean when two accepted records contain zero. It therefore cannot also communicate every unavailable case without ambiguity. MeanValid tells a consumer whether the current result is usable. The declared contract requires at least two accepted records and avoids division when that condition fails.

Does putting value and quality in a structure make communication atomic?

No such guarantee is made here. The exercise assumes a coherent input snapshot. An actual communication interface must establish its own consistency behaviour. A structure groups related fields logically; it does not, by itself, prove when another device updates or observes those fields.

Where can I practise the reasoning before a native course?

This site is commercially connected with PLC Simulation Software. Its Structured Text learning resources and PLC data-type resources offer related general preparation. Check current supported features; these links do not establish native Sysmac project compatibility or execution of this particular exercise.

Finish with a variable model another learner can inspect

Keep the dictionary, input snapshots and expected results together. Include a normal case, a boundary, an unavailable result and a deliberately wrong implementation. Explain which observation exposes each defect. That turns a table of names into evidence that you understand the data and its use.

Return to the Omron training hub to choose a native learning route, or use the PLC program testing resources for further general practice. Let the next task follow from a specific unanswered question about scope, interpretation or lifecycle.

06