Settings

AnyAutomation Studio opens a branded Settings editor as an editor pane in the center by default. It gathers the most-used options into a compact category view: a list of categories with their own icons on the left, the matching sections and fields on the right.

Opening

Every entry point opens the same single, pinned Settings editor (invoking it a second time reveals the existing one rather than opening another):

• Gear icon (bottom of the Activity Bar) → Settings.
• Menu bar: File → Preferences → Settings.
• Keyboard: Ctrl+, (Cmd+, on macOS).
• Command Palette (Ctrl+Shift+P): Settings.

Changes are saved automatically — no Save or Cancel button. Any field whose value differs from its default shows a colored accent bar on the left edge and, on the row, a one-click reset control that returns it to the default.

Reaching the native VS Code settings editor

The native VS Code settings editor is no longer the default target, but it stays reachable at all times: below the category list — set off by a thin divider — two muted links, Open Agent Customization and VS Code Settings, are shown; the latter opens the native editor. The Command Palette also still offers Open Settings (UI). Both editors stay in sync because they read and write the same settings.

Categories

The category list holds seven entries, each with its own icon; clicking one swaps the content panel on the right.

Every field shows its description right in the editor; for dropdowns, each choice also surfaces its own explanation on hover.

Check for Updates (under General → Startup)

Open Settings → General and find the Startup section. The Check for updates dropdown controls how AnyAutomation Studio looks for new versions:

The Check Now button next to the dropdown checks immediately. If updates are not available in your current installation — for example when running a copy that was not set up through one of the installers — a notification tells you so.

What happens once an update has been found — the badge on the gear icon and Restart to Update — is described under Installation.

Importing Settings from VS Code (under General → Migration)

If you are coming from Visual Studio Code, you can bring your existing setup across in one click. Open Settings → General, find the Migration section, and click Import next to Import Settings from VS Code.

What is brought over:

• Settings — your editor and workbench preferences.
• Keyboard shortcuts — your custom keybindings.
• Snippets — your code snippets.
• Extensions — the extensions you have installed (those still available are reinstalled here).

The import is safe and additive:

• Your existing choices are kept. Any value you have already changed in AnyAutomation Studio stays as it is — the import never overwrites it. Only options you have not set yourself are filled in from VS Code.
• Nothing is removed. Keyboard shortcuts and snippets you already have are left untouched; only new ones are added.
• Some extensions may be skipped. An extension that is no longer available is reported in the summary and simply skipped — the rest still come over.

While the import runs you see a short progress message. When it finishes, a summary tells you how many settings, shortcuts, snippets, and extensions were imported (and lists any extensions that were skipped). Click Reload Window in that message to finish applying everything. If no VS Code installation is found, a notice tells you so and nothing is changed.

Folder Name Customization (under Files & Folders → Folder Names)

The "Create Source folder" checkbox controls whether exports include a Source wrapper:

This also affects the project tree structure and import path detection.

File Explorer — Watcher Excludes

The File Explorer tree skips folders that match a Watcher Excludes list when scanning the open working folder. Defaults: .git, .vs, .idea, bin, obj, node_modules, .claude, .worktrees.

This list is not part of the branded Settings editor — adjust it in the native VS Code settings editor (open the VS Code Settings link, then search for watcher excludes). Editing the list lets you:

• Hide additional folders — add one folder name per line (e.g. dist, coverage, .next).
• Reduce file-watcher noise — heavy build output (bin/obj) can flood the operating-system file-change buffer; keeping these in the exclude list prevents wasted scan work on every build.
• Restore the default list — clear the text box; the defaults apply on the next refresh.

Changes take effect when the working folder is reopened or refreshed. See File Explorer for the rest of the file-tree behaviour.

Editor behaviours (configured in the native VS Code settings editor)

The branded Settings editor covers the categories above; its Editor category holds a Block Editor section with the Show Block interface like in TIA and Open UDTs as .udt toggles. The remaining code-editor behaviours — bracket colouring, indent guides, the right-click menu, the C# and SCL language helpers — are not part of the branded editor; they are toggled in the native VS Code settings editor (open the VS Code Settings link, then search for the toggle name). The most useful ones:

• Code-editor right-click menu — right-clicking inside a code editor exposes AI assistance, edit, navigation, Git and clipboard actions; the same actions also have keyboard shortcuts. See Context Menus for the full list.
• C# language features — an Enable C# language features toggle attaches a bundled language server to .cs files opened from the File Explorer, adding inline error squiggles, the Problems panel, hover docs, F12 go-to-definition, Find References, completion, quick-fixes (Ctrl+.), rename (F2), formatting, an Outline view, breadcrumbs, global symbol search (Ctrl+T), reference-count lines, inlay hints, and background-task progress in the status bar. It is off by default (the server can use 1–10 GB of memory while indexing) and the change takes effect on the next launch. A Load solution automatically toggle and an Explicit solution path field let the server load a .sln/.csproj so cross-file diagnostics work; auto-load is off by default because it can run analyzer code shipped with the project. SCL, AWL, UDT and other Siemens block formats are unaffected.
• Visual polish — toggles for nested-bracket colouring, indent guides, highlight matching identifiers, auto-close brackets and quotes, and font ligatures, plus an editor font family field (comma-separated; the first installed font wins). Inlay hints and the server-initiated-edit confirmation mode are configured here too. These apply live without restart.
• Change-detection exclusions — a glob list (one pattern per line, e.g. **/node_modules/**, **/bin/**) that excludes paths from file-change watching to keep large repositories responsive; invalid patterns are skipped with a warning.

The footer of each editor tab also shows a language selection dropdown next to the line/character counters, grouped into TIA Portal Languages (SCL, used for .db/.udt too, and AWL) and Other Languages (C#, Python, TypeScript, JSON, XML, Markdown, …, plus Plain Text). The language is auto-detected from the file extension; overriding it applies to the current tab only and is not persisted.

SCL Editor Intelligence

When you open an .scl file from the File Explorer or from a TIA project tab, the editor attaches a dedicated SCL language server that adds workspace-aware editing aids on top of the built-in syntax highlighting:

• Completion — As you type, the suggestion list offers SCL keywords (FUNCTION_BLOCK, BEGIN, END_IF, VAR_INPUT, etc.) and the names of every Function Block, Function, Data Block, and UDT discovered in the open workspace and in the currently open TIA Portal project. Suggestions update automatically as files are added, removed, or renamed, and as blocks are added to or removed from the open project.
• Hover — Resting the pointer over an identifier shows a tooltip with the symbol's category (FB, FC, DB, UDT), its signature, and the first comment line above its declaration when available.
• Semantic highlighting — Identifiers are colored by what they actually are: input/output parameters, local variables, constants, structure or data-block members, and references to other blocks and data types each get their own color, so a parameter reads differently from a local and from a called block at a glance. The coloring follows your active color theme.
• Document outline — The Outline view next to Problems and References lists every Function Block, Function, and Data Block in the current file as a tree: each top-level entry expands to its VAR-blocks (VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT, VAR, VAR_TEMP, VAR CONSTANT) and from there to the individual members. Double-click a row to jump the editor to that symbol.
• Go to Definition, References, and Rename — Press F12 (or right-click → Go to Definition) on an identifier to jump to where a local variable or member is declared; on the name of a called Function Block, Function, Data Block, or UDT it opens that block's source instead. Shift+F12 (Go to References) lists every place a local symbol is used in the current block. F2 (Rename Symbol) renames a local variable, temporary, or constant everywhere it is used in the block. Interface parameters (VAR_INPUT / VAR_OUTPUT / VAR_IN_OUT) and the block name itself cannot be renamed this way yet — renaming them would affect other blocks, which is not available in this release.
• Highlight occurrences — Put the cursor on a name and every other use of it in the current block is highlighted, so you can see at a glance where a variable or block is used.
• Quick fixes — For a missing semicolon, a missing keyword such as THEN or DO, or a block or statement left without its closing keyword (END_IF, END_WHILE, and the like), a lightbulb offers a one-click fix that inserts the missing text.
• Format Document — Right-click → Format Document (or Shift+Alt+F) tidies the whole block: it re-indents to the block structure (each VAR block, the BEGIN body, and every IF / FOR / WHILE / CASE one level deeper, using your editor's tab width), uppercases SCL keywords, puts a single space around operators, and collapses runs of extra blank lines to one. It changes only formatting — your identifiers, comments, strings, and code are left untouched — so it is safe to run; a block that is already tidy is left unchanged. You can also format just the selected lines (Format Selection), or have each line tidied as you finish it by turning on Format On Type in settings.
• Folding — Region markers (REGION / END_REGION) and IF / ELSIF / ELSE / END_IF blocks collapse from the gutter. The folding state is per-tab and resets when the file is reopened.
• Syntax problems — As you type, the editor flags basic syntax problems: an unexpected character, a string or comment left unclosed, a block missing its closing keyword (for example a Function Block without END_FUNCTION_BLOCK), or a region without a matching end. Each problem appears as a red marker under the affected text — hover it for the message — and as a row in the Problems panel; click the row to jump straight to the spot. The markers update while you edit and clear when you close the file.
• Declaration problems — The editor also flags two declaration mistakes while you edit: a name declared more than once in the same scope (a duplicate variable in a VAR block, a duplicate member in a DB or UDT, or two blocks with the same name), and a local variable reference — written with a leading #, such as #speed — that matches no variable declared in the block. These appear as markers and Problems rows just like syntax problems. References to global tags, library blocks (such as TON), and other program blocks are intentionally not checked here, so a valid cross-block or tag reference is never flagged.
• Type warnings — When you assign an obviously incompatible literal directly to a local variable — for example a text or time literal to a numeric variable, or a decimal to an integer — the editor shows a warning in the Problems panel. Only this simple, unambiguous case is checked; values produced by expressions, calls, or other variables, and assignments where SCL performs an implicit conversion, are left to TIA Portal.

Where these aids apply

Live problem checking, completion, and hover apply to SCL blocks you open from the project tree (Function Blocks, Functions, and Organization Blocks) as well as to standalone .scl files you open from the File Explorer — not only to files saved inside a project. Opening a block from the project tree and editing it shows problems and suggestions exactly as a saved file does; saving the block still writes it back to TIA Portal, never to a file on disk.

Enabling or disabling SCL intelligence

The SCL language server is enabled by default. To turn it off, open the VS Code Settings link and search for the SCL language server toggle, then clear it. The change takes effect the next time an SCL file is opened — already-open tabs keep the previous behaviour until they are closed and reopened. With the toggle off, SCL files keep their syntax highlighting and the editor's built-in keyword completion, but workspace-aware completion, hover, semantic highlighting, outline, occurrence highlighting, quick fixes, formatting, folding, navigation (Go to Definition / References / Rename), and problem markers are not available.

Multi-project behaviour

Each open TIA Portal project tab gets its own isolated set of SCL symbols. Completion in an .scl file from project A never lists Function Blocks defined in project B, even when both projects are open side-by-side. The list includes the block and data-type names from the open TIA project itself — open a project from the start page and the completion list starts offering its top-level FBs, FCs, DBs, and UDTs (including safety-program variants) the moment the project finishes loading. Closing a project tab releases its symbols immediately; reopening the project rebuilds the symbol index from the project tree.

Current limitations

The SCL language server is focused on navigation and editing aids; it does not replace TIA Portal's compiler:

• No full type checking yet. Beyond the simple literal type warning described above, the editor does not perform full expression-level type checking, and does not flag undeclared references to global tags, library blocks, or other program blocks, inline. Use TIA Portal → Compile for authoritative diagnostics before downloading to a PLC.
• Local rename only. F2 renames a local variable, temporary, or constant within its block. Interface parameters and block names are not renamed this way yet — use TIA Portal's rename for changes that must update other blocks.
• Formatting scope. Formatting covers indentation, keyword casing, operator spacing, and collapsing extra blank lines, and runs on the whole block (Format Document), the highlighted lines (Format Selection), or each line as you finish it (Format On Type, off until you enable it). It does not pad brackets or colons or align declarations.

Appearance (Modern UI)

Studio opens with the refreshed look by default: the side bars and the bottom panel appear as floating cards with rounded corners and small gaps, and the editor tabs, view headers and the command center use the same refreshed styling as the Agents window. If you prefer the classic layout with the parts flush against each other, open the native settings editor (VS Code Settings link or Open Settings (UI) in the Command Palette), search for Modern UI and uncheck Workbench › Experimental: Modern UI. The change applies immediately, no restart needed; checking it again brings the refreshed look back. The separate Modern UI Uppercase View Headers switch stays off unless you turn it on.

Finding a specific setting

The branded editor is organised by category — click a category in the left list to reveal its sections and fields, each with its own description. To search for an individual setting by name or keyword (including settings not surfaced here), open the VS Code Settings link and use that editor's search box; for example, @tag:tiaPortal lists the TIA Portal keys.

License

License activation, trial status and hardware ID are still managed in their own focused window — accessed from the startup prompt, the Trial banner, or the Manage License entry-point.

Log Files

When Debug Logging is enabled, detailed logs are created:

• Location: configurable under Files & Folders → Log File Directory.
• Each session writes its own text file, named with the date and time.