Variables editor

The variables editor is the table at the top of every POU body. It lists each variable declared for that POU and lets you edit, add, remove, and reorder them. A toggle in the top-right corner switches between table mode (the default) and code mode (raw VAR ... END_VAR text).

Columns

A class filter above the table (All / Local / Input / Output / InOut / External / Temp) hides rows of the other classes. View-only, the hidden variables stay declared.

Class

In IEC 61131-3, class describes a variable's role in its POU's interface. It answers "who can read or write this from outside the POU?", not "is this a physical pin?". The six classes:

The first three (Input, Output, In Out) describe a POU's calling interface, they only mean something for functions and function blocks that other code calls. A Program is the entry point of execution, not something you call, so its interface variables aren't useful in the same way.

Local, External, and Temp are for variables a POU uses internally (or shares globally), independent of any caller. Physical I/O mapping is independent of class, it's done through the Location column, which is covered next.

Location, physical I/O mapping

The Location column binds the variable to a specific bit, byte, word, or register of the PLC's I/O image. It's independent of class, most variables that map to physical I/O are simply Local-class with a Location set.

Address format

code
%I X 0.0
 │ │ │
 │ │ └── address (byte and bit for X; byte for B; word index for W/D/L)
 │ └──── size: X bit, B byte, W word, D double word, L long word
 └────── area: I input image, Q output image, M memory

Bit addresses use byte.bit notation: %IX0.0, %IX0.7, %IX1.0 (rolls over to the next byte). See Modbus addressing for how these IEC addresses end up on the wire when an external client reads them.

Examples

code
Name           Class  Type  Location
start_btn      Local  BOOL  %IX0.0
e_stop         Local  BOOL  %IX0.1
motor          Local  BOOL  %QX0.0
alarm_lamp     Local  BOOL  %QX0.1
process_temp   Local  REAL  %MD2

Each row is a normal Local variable that happens to be bound to a physical address (or, in the last case, a memory slot the Modbus server would expose).

Aliases, when the Location is set for you

Variables that come from a producer, a Modbus master remote device, an EtherCAT slave channel, a board pin-map on the desktop editor, have their Location written into the row by the alias registry, not by you. You see the resolved address in the table and reference the variable by name like any other. If the producer moves the underlying address, the row updates automatically on the next save.

If the producer goes away (you delete the remote device or the EtherCAT channel), the variable becomes orphaned. The editor marks the row with an amber warning glyph; the hover tooltip explains how to fix it (re-bind or remove).

Toolbar, adding, removing, reordering

Four icons in the top-right of the table:

Renaming a variable: double-click the Name cell, type, press Enter. The editor finds every reference in the bodies (textual and graphical) and updates them. For graphical-body references it opens a Rename Impact dialog listing every match before applying.

Changing class: click the Class cell and pick from the dropdown. If you switch to External, the Location is cleared (externals inherit from their global). If you switch from Local to any other class on a Function-Block variable, the Location is cleared (only Local carries an address).

Type picker

Click the Type cell. The dropdown groups available types:

• Base types: IEC scalars: BOOL, BYTE, WORD, DWORD, LWORD, SINT, INT, DINT, LINT, USINT, UINT, UDINT, ULINT, REAL, LREAL, TIME, DATE, TIME_OF_DAY, DATE_AND_TIME, STRING, WSTRING.
• User data types: types you've defined in the project's Data Types section.
• Library types: types exposed by enabled libraries. Most commonly function block instance types (TON, CTU, RS, etc.), declaring a variable as TON gives you a TON instance you can call from the body.
• Array: opens a sub-dialog to define an inline array (ARRAY[0..9, 0..3] OF INT). For arrays you reuse, define them in Data Types instead.

Table mode vs code mode

The toggle in the top-right of the toolbar switches between the two views. Both show the same variables; they're two ways of editing the same data.

Table mode is the spreadsheet-like default. Faster for individual edits, with typed inputs per column.

Code mode shows the raw IEC declarations in a Monaco editor, grouped by class as VAR_INPUT / VAR / VAR_OUTPUT / VAR_EXTERNAL / VAR_TEMP blocks.

Code mode is the fastest path when you want to:

• Paste a chunk of declarations from another project.
• Bulk-rename with multi-cursor edits.
• Audit exactly what was declared without scrolling a long table.

When you switch back to table mode, the editor parses the text. Syntax errors prevent the switch and surface as red squiggles with hover messages.

Function-specific fields

A function POU has two extra fields above the variable table:

• Return type: the type of the value the function returns. Required (every IEC function returns something).
• POU description: free text describing what the function does. Shows up in the function picker and IntelliSense tooltips.

Function blocks and programs don't have these fields.

Globals

Project-wide variables live in the Resource editor (the Resource entry in the project tree). The Resource has a Globals section that looks and behaves identically to the per-POU table, but the class is fixed to Global. POU-level variables can then declare class External and reference a global by name.

See Global Variables for the full Resource walkthrough.

What's next

• Custom Data Types: define arrays, enumerations, and structures.
• Modbus addressing: how %IX/%QX/%MW map to wire-protocol addresses.
• Debugger: what the Debug checkbox actually does.