Every variable lives in one of three scopes - Global, Active, or Local - which controls who can read it, how long it persists, and where it ends up in your exported PLC code.
| Aspect | Global | Active | Local |
|---|---|---|---|
| Visibility | Every Sequence in the project | The owning Sequence file only | The owning step only |
| Persistence (emulation) | Survives Sequence switches, reset by Reset Emulation | Survives within the file, cleared when emulation stops | Initialised on step entry, discarded on step exit |
| PLC mapping (typical) | Global variable list / DB | Sequence-scoped FB instance variable | Temporary or VAR_TEMP |
| Address space | Fixed I/O addresses, retain memory | Provider-chosen private memory | Stack / scratch |
| Common use | I/O signals, machine state, alarm bits | Sequence counters, internal flags | Step-specific timers, one-shot latches |
| Created via | Machine editor, Add Global Variable | Variable panel in Active mode | Step properties in the Sequence editor |
Global variables are visible to every Sequence in the project and to the Machine editor. They are the canonical place to define machine I/O, alarm flags, and any shared state.
main.machine and surfaced by the Machine editor.| Command | What it does |
|---|---|
| AutomationView: Set Global View | Switches the Variables panel to Global mode |
| AutomationView: List Input Variables | Filters to input-typed globals |
| AutomationView: List Output Variables | Filters to output-typed globals |
| AutomationView: Get Variable Value | Reads the current emulation value |
| AutomationView: Set Variable Value | Forces a value during emulation |
| AutomationView: Assign Addresses Automatically | Auto-assigns physical addresses |
| AutomationView: Validate All Addresses | Detects address conflicts |
Global values are retained for the lifetime of the emulation session and survive switching between Sequences. AutomationView: Reset Simulation (Ctrl+Shift+F5) brings them back to their declared initial values.
| Target | Maps to |
|---|---|
| CODESYS | Global variable list (GVL) |
| Siemens TIA | Tag table plus shared DB |
| Rockwell Studio 5000 | Controller-scoped tags |
| Fanuc | Robot system variables (R[], DI[], DO[]) |
| PLCopen XML | <globalVars> block |
Active variables belong to the currently open Sequence file. They are perfect for internal helpers - cycle counters, retry flags, recipe selectors - that should not pollute the global namespace.
.seq file alongside steps and transitions.| Command | What it does |
|---|---|
| AutomationView: Show Active File Variables | Switches the Variables panel to Active mode |
| AutomationView: List All Variables | Lists every variable across scopes in the picker |
| AutomationView: Delete Variable | Removes an unused variable from the project |
| AutomationView: Rename Variable | Project-wide safe rename |
Active values persist while the emulation runs and reset between runs. Switching to a different Sequence preserves the value as long as the file remains loaded.
| Target | Maps to |
|---|---|
| CODESYS | VAR block on the function block representing the Sequence |
| Siemens TIA | Instance DB members |
| Rockwell Studio 5000 | Program-scoped tags |
| PLCopen XML | <localVars> on the POU |
Local variables exist for the lifetime of a single step. They reset on step entry and disappear on step exit. Use them for ephemeral state that has no meaning outside the step.
Locals are initialised every time the step becomes active and discarded when the step deactivates. Forcing a value via Set Variable Value affects only the current activation.
| Target | Maps to |
|---|---|
| CODESYS | VAR_TEMP inside the action method |
| Siemens TIA | Temp block of the FB |
| Rockwell Studio 5000 | Routine-local tag (when supported) or program-scoped temporary |
| PLCopen XML | <localVars> on the action body |
If a target vendor cannot represent step-local variables natively, the translation provider promotes them to active scope and renames them with a step prefix - this is logged as a diagnostic.
AutomationView infers a variable's type from its first usage when no explicit type is set:
cycle_count == 5 infers INT.TON(timer_red, T#10s) declares timer_red as a TON instance.Set an explicit type from the Variables panel to lock the choice. Explicit types are required for any export when the inferred type would be ambiguous (mixed REAL/INT arithmetic, for example).
A local with the same name as an active or global variable shadows the outer variable inside its step. The Sequence editor warns about shadowing with a yellow underline. Resolve it by renaming one of the two.
You cannot reference a local variable from another step. The diagnostic reads Variable <name> is not in scope. Promote it to active scope using AutomationView: Rename Variable combined with the scope toggle.
A global and an active variable can resolve to the same physical address if both are bound to the same channel. Run AutomationView: Validate All Addresses before export to catch these.
Unused variables bloat exports. Use AutomationView: Delete Variable (or Clean Unused Variables from the panel header) to clear active or local variables with zero references.