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 — a muted VS Code Settings link opens it. 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 exactly four 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 four categories above. 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.
• 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.
• 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, outline, folding, 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.
• No symbol navigation yet. Go to Definition (F12) is not available; use TIA Portal's own navigation to jump between FB/Function definitions.
• No symbol rename yet. F2 inside .scl files is not available. Use TIA Portal's rename for any rename that must update every call site.

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, hardware ID and the EPLAN add-on 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.