Forge — Block Type Library

Forge is your reusable Block Type Library: you capture existing blocks from a PLC project, collect and organize them in one place, and later deploy the whole library into any connected PLC — the library's folder structure is recreated as the group structure inside the PLC. Along the way, Forge redraws existing projects as project graphs that you can browse, validate, edit, and deploy back into a PLC.

Open the Forge view container from the Activity Bar. The Block Type Library appears in the Side Bar as a tree of folders and types.

Prerequisite: Forge is part of the paid editions. Without a license the Forge commands stay disabled — see Licensing.

Connect to Forge

Open the Command Palette (Ctrl+Shift+P) and run "Connect to Forge" — or click Connect in the Forge view container.
Once connected, the Status Bar shows Forge: Connected and the library loads.

To disconnect, run "Disconnect from Forge".

Capture blocks into the library

You fill the library straight from an open TIA project (see Project Explorer). Both Forge and the TIA project must be connected.

Right-click a PLC, a group, or a single block in the Project Explorer.
Select "Capture to Forge Library".
Confirm how many items to capture.
Forge creates a reusable type for each item and mirrors the project's group structure as folders in the library.

The captured types sit under a folder named after the project (for example MixingPlant). This keeps types from different projects cleanly apart — you can tell at a glance what came from where, and capturing a second project no longer mixes its blocks with the first.

Capture covers blocks, data types, and tag tables — including those inside Software Units.

When it finishes, a notification reports how many types were newly created and how many were updated. Items that cannot be captured are listed with their name and reason; identical duplicates are skipped automatically and not counted as failures.

Organize the library

All operations are reached by right-clicking in the Block Type Library:

New Block Type — adds a new, self-maintained type.
Edit / Duplicate / Delete Block Type — on a type.
Folder / Subfolder — structure the library to any depth.
Rename — on a type or a folder.
Move to … — assigns a type to a different folder; a picker lists every existing folder.

Each entry in the list shows a short, neutral type tag after the block name — SCL, DB, UDT, or XML — so you can see at a glance what kind of type it is. The Plugins list shows the code generator as TIA SCL.

You can reorder entries by dragging. The folder structure you build here determines the group structure inside the PLC later.

The AI chat helps with writing your own type templates: ask the Forge Engineer agent — it knows the templating language and assists with creating, reviewing, and fixing your templates.

Install the ready-made example

So you don't have to start from scratch, Forge ships a ready-made example: a complete block-type library together with a matching example project graph you can study at your leisure.

Click Install Example (MixingPlant) in the title bar of the Block Type Library, or run the same command from the Command Palette (Ctrl+Shift+P).
A short notification reports how many types were added (and how many were already present), and whether the example graph was added.

You can run the command again any time: it never overwrites your own types or graphs. Items that are already present are skipped, and only what's still missing is added.

After installing, the library shows a single Mixing Plant Demo folder holding the complete example — the faithful plant blocks alongside the reusable example types; the example graph appears in the Project Graphs list.

Open any type to see how it is built: the templates are heavily commented and explain, step by step, how the generation works and when each piece is used. You can then generate code from them and deploy it to TIA the same way as your own types.

Storage & Git versioning

Both the Block Type Library and your Project Graphs can live in folders you control, so you can keep them under version control alongside the rest of your work. You set this up in AnyAutomation Settings → Forge.

Choose where the library is stored

Your reusable block types are kept in a Library Folder. By default Forge uses its own location, but you can point the library at any folder you like — for example one you already keep in a Git repository, so the whole library travels with your version history.

In AnyAutomation Settings → Forge, set the Library Folder to the folder you want to use. Use Browse… to pick one, or leave the field empty to keep the default location.
The folder icon on the field opens that folder on disk (the default location when the field is empty), so you can review and version what is stored there with Studio's built-in version control.

Store Project Graphs inside the project

Project Graphs are saved as text files. Because they are plain text, you can version them with Git, and changes show up in your diffs like any other file. The Project Tree is part of the graph, so it is versioned together with it. Your graphs are always saved and reload the next time you start.

On disk, each Project Graph is a folder holding a forge.yaml file — a graphs folder contains one such subfolder per graph. The settings describe this shape too, so you know what to look for when picking a folder.

In AnyAutomation Settings → Forge, the Project Graphs section controls where the graphs live:

Project Graphs Folder — use Browse… to pick a fixed folder for your graphs. Point it, for example, at a folder you already manage in a Git repository. The folder icon on the field opens that folder on disk.
Leave the field empty to store the graphs inside the open project — in a subfolder (.forge by default) right next to the project, which you can change under Project Subfolder. When no project is open, Forge uses a default location so your graphs are kept anyway.

Changing either setting takes effect right away: the Project Graphs list switches to the newly chosen folder and shows its graphs without reopening the view.

Load a graph from a file and reload the list

The Project Graphs list has two more title-bar buttons (shown once you are connected to Forge):

Load Project Graph from File (folder icon) — opens a file picker so you can load a graph that was not picked up automatically or lives outside the configured folder. Select the graph's forge.yaml file; the graph then appears in the list and opens right away, and a copy is saved into your current graphs folder.
Reload Project Graphs (refresh icon) — re-reads the graphs folder from disk, for example after graph files changed outside Studio.

Put a folder under version control

To start versioning a folder, use the Initialize Git Repository button in the title bar of the Forge view itself — the Block Type Library view for your block types, and the Project Graphs view for your graphs (both shown once you are connected to Forge):

Click Initialize Git Repository and Studio creates a Git repository directly in that folder, then confirms it with a short message.
From there you can review, stage, and commit your block types or project graphs with Studio's built-in version control like any other folder. To reach the folder on disk, use the folder icon on its path field in the settings above.

Edit a block type

Double-click a type in the Block Type Library and it opens as a tab: the type's fields on the left, one template tab per output target on the right. The Save button in the toolbar saves the whole type — fields and all templates together.

Unsaved edits are safe: the tab marks them with the usual dot, switching to another tab and back keeps everything — fields and template text alike — and closing the tab asks first whether to save or discard, like any other file.

Open a template in a text editor

A template can also be edited in a regular editor tab — handy for placing it side by side with other files:

click "Open Template in Text Editor" in the toolbar of the block-type tab, or
right-click the type in the Block Type Library and choose "Open Template in Text Editor" — if the type has several templates, a list first asks which one to open.

The text tab and the block-type tab always show the same content — what you type in one appears in the other immediately. Ctrl+S in the text tab saves just that template; the Save button in the block-type tab still saves everything.

A brand-new block type must be saved once before its templates can be opened this way — the same applies to a freshly added output target until the next save.

The chat sees your template

While the block-type tab (or one of its template text tabs) is active, the chat assistant automatically has that template as context — it appears above the chat input. Ask about the template right away: the assistant knows its content and the available template helpers — without you pasting anything.

Reverse-engineer a project

Forge can redraw an existing PLC program as a project graph in one step, capturing all its contents as coupled library types at the same time — the foundation for deploying the program back out of the graph later.

Connect Forge and the TIA project first — only then does the matching entry appear in the right-click menu. Then right-click a PLC in the Project Explorer.
Select "Reverse-Engineer Project to Coupled Library" and confirm — library types with a matching name are overwritten.
A progress indicator follows the run; at the end the new graph opens as a tab, and a notification summarizes how many types were captured and how many objects and connections were drawn. The graph and its project tree are named after the project, and the captured library types sit under a same-named folder named after the project — keeping them separate from types of other projects.

Items that cannot be captured are named in the notification with their name and reason — they still appear on the graph, but stay without a coupled library type. When one object references the same other object several times, the graph shows a single connection instead of a bundle of parallel lines.

View the project graph

When Forge reads in an existing project, you can browse it as a dependency browser. Open a graph from the Project Graphs list in the Forge view container — double-click a graph and it opens as a tab. Even very large projects with thousands of blocks open instantly.

The tab is split into two areas: a tree of every block on the left, and the dependencies of the selected block on the right.

Pick a block in the tree

The tree on the left lists every block in the project, grouped by folder and category — the same structure as in the project. Each row carries an icon for the block kind and a small coupling indicator that shows at a glance how connected the block is. Click a block to see its dependencies on the right.

A search box lets you type a block name: the tree opens the folders on the way to the match and jumps straight there, so you can find any block without scrolling.

See what uses a block — and what it uses

For the selected block, two lists appear on the right:

Used by — every block that uses this one (for example an organization block that calls it).
Uses — every block this one uses itself (called blocks, referenced data types, and so on).

Each entry shows the block name and the kind of relationship as a colored tag. The filter buttons at the top hide a relationship kind or show them all again. A coupling indicator in the header sums up how connected the block is. If the block uses nothing, or is used nowhere, that is stated explicitly.

Click an entry to jump straight to that block — it is selected in the tree and its dependencies appear on the right. This lets you walk through the project step by step.

Switch between list and neighborhood

A switcher flips the right side between two views:

List — the two columns Used by / Uses (described above).
Neighborhood — a small picture showing the selected block in the centre with its direct neighbors around it. Click a neighbor to centre the view on it and keep moving. Scroll to zoom around the cursor, drag with the middle mouse button to pan, and double-click an empty spot to fit the graph back into view. Use the Depth stepper in the top-left corner to show more or fewer levels around the block, so you can trace what it uses (and what uses it) several steps out at once instead of clicking through block by block. If a level shows only some of the blocks, a +N more marker reveals the next batch of blocks each time you click it, and Show fewer folds them back; the table always lists every block. Right-click any block (the centre one or a neighbor) for Open Project Objects, Connect, Remove Edge, Delete Node, and Build Selected.

Whichever view you last chose is remembered for that graph.

Remove several graphs from the list

In the Project Graphs list you can also select several graphs at once: Ctrl+click adds or removes an individual entry, Shift+click selects a range, and Ctrl+A selects all. Then press Delete (while the list has focus), or right-click the selection and choose "Delete N Project Graphs" — a single confirmation covers the whole selection. To remove a single graph, use the trash button that appears when you hover over its row.

Rename a graph

Right-click a graph in the Project Graphs list and choose "Rename Project Graph" — or click the pencil in the Project Tree title bar. Type the new name and it appears everywhere: in the list, in the Project Tree, and in an already-open tab. (The project graph and the project tree are the same graph, so renaming takes effect in both.)

Edit the graph

You change nodes and connections from the toolbar buttons: Add Node, Connect, Remove Node, Remove Edge, and Refresh. Connect and Remove Node become active once you have selected a block; Remove Edge offers the selected block's connections to choose from. After every change the view refreshes; if a change can't be applied, a message explains why and nothing changes.

When you remove a node that is the only user of other objects — for example a block whose data types nothing else references — the confirmation dialog lists those objects by name and offers a pre-ticked checkbox "Also remove N objects only this node references". Leave it ticked to clean them up together with the node, or untick it to remove just the node. Objects that any other node still uses are never listed and never removed.

Generate code for selected objects only

You don't have to generate the whole project at once — you can generate code for just the objects you pick.

In the tree, select the blocks you want: hold Ctrl/Cmd and click several of them, or hold Shift and select a contiguous range.
Choose Build Selected Nodes — from the Build Selected button in the toolbar, or from the Command Palette.

Only the selected objects are (re)generated; everything else you generated earlier stays as it is. The rest of the project is still checked in the background so cross-references resolve correctly, and the build only stops if something is wrong with one of the objects you selected.

When you are done picking objects, build the whole project instead with Build Project Graph (Command Palette) at any time.

Code generators and output targets

Forge turns each object into source through a code generator. The generators available to you are listed in the Plugins view of the Forge view container; the built-in generator for Siemens SCL appears as TIA SCL. Each row names the generator with its version. The list is informational — you do not pick a target here. Reload Plugins refreshes the list after you add or change generators.

Choosing what to generate

You choose the output target every time you build — neither in the Settings nor in the Plugins list. As soon as you run "Build Project Graph" or "Build Selected Nodes", a picker asks which targets to generate for; every available target is pre-selected. Confirm the selection and the source is produced per target. TIA SCL is the built-in target for Siemens SCL.

Which generator serves an individual object depends on its Library Type — or, when none is set, its Sub-Type. You set both in the Inspect and edit an object section.

Choose which generated files to import

After a build, the generated files appear in the Build Output view, each with a checkbox (and a checkbox per group that ticks or clears all of its files at once).

Tick the files you want and choose Import Selected to TIA Portal to import only those into the connected PLC. This action stays disabled until you have at least one importable file ticked.
Choose Import All to TIA Portal to import every generated block, regardless of the checkboxes.

Both follow the usual rules: Forge and the TIA project must be connected, you pick the target PLC when the project has several, same-named blocks are overwritten only after you confirm, and a notification reports how many blocks were imported.

Browse objects in the Project Tree

The Project Tree view in the Forge Side Bar shows a project graph's objects as a folder tree — the same folder structure as in the project. When a folder level holds several kinds of objects, the tree additionally groups them by category (function blocks, data blocks, data types, and so on).

When several graphs exist, a dropdown at the top of the view picks which graph is shown — each entry carries the graph's name plus its creation date.
The trash button in the view's title bar deletes the shown graph (after confirmation).
Click an object to inspect its details; double-click (or Enter) opens the graph as a tab and jumps straight to the object.
Right-click an object for "Reveal in Graph", "Open Project Objects" (opens the table pre-filtered to the object's folder), and "Delete Node" (confirmed). Right-click a folder for "Open Project Objects in Folder".

The tree updates live as the graph changes.

Edit objects in the table

"Open Project Objects" (Command Palette, or the Project Tree's context menu) opens a graph's objects as a table in an editor tab — the place to review properties and edit them across many objects at once.

Filter: toggles per object kind, a sub-type dropdown, a folder prefix box, a search across symbol and description, and a "Without edges" toggle for objects with no connections. A sort dropdown with an ascending/descending toggle orders the rows.
Columns: Symbol, Kind, Sub-Type, Folder, Description, and Edges. When the table shows objects of a single sub-type only, it adds one column per property.
Live values: when you are online with a controller, turn on Monitor at the top right — the Live column then shows each tag's current value and keeps it updated while Monitor is on. Structured objects and arrays show a dash (—), since they have no single value. To follow just one tag without monitoring everything, click the eye on its row to watch that single value; click it again to stop.
Inline editing: click a cell (symbol, description, or a property) and change the value in place — it is saved immediately. If the object was changed elsewhere in the meantime, the table reloads the latest values instead of overwriting them.
"Set Column…": select several rows and set one property to the same value for all of them. The operation runs with a progress indicator and can be cancelled; if a conflict occurs, it stops and reports how many objects were set — the rest are left unchanged.

If the project graph is deleted while its table is open, the tab shows a note saying so and can simply be closed — no error message appears.

Inspect and edit an object

Select an object (in the Project Tree, the table, or on the map) and the Inspector in the Forge view container shows all of its fields — grouped into Profiles, Node, Properties, and Data Points. Most fields are editable right here, and every change is saved immediately. If the same object was changed elsewhere in the meantime, the Inspector asks whether to reload the latest values instead of overwriting your edit blindly.

Profiles — profile and variant for the graph

The setting at the very top applies to the whole graph, not the single object: a Profile from the list ("— None —" removes the assignment) and an optional Variant. This feeds the profile's defaults into every object — described in full under Profiles — layering default values.

Node — symbol, kind, description, sub-type, and library type

Symbol — the object's name as it appears in the tree, on the map, and in references. Freely editable.
Kind — the object's base category. Possible values: Equipment, Cell / Station, Resource, Workpiece, I/O Point, Hardware, and Composite. This field is read-only. Reverse-engineered blocks are always Composite — so a block captured from a project always shows the same value; the other kinds are assigned only when you model a system yourself.
Description — a free comment. Freely editable.
Sub-Type — the concrete block category the object represents. Type it directly, or click the picker symbol and choose from the Block Kinds (OB, FB, InstanceDB, FC, DB, UDT, TO, Tag), the Failsafe kinds (FOB, FFB, FFC, FDB), or enter your own identifier via Custom….
Library Type — links the object to a reusable type in the Block Type Library; the source is generated from that type. Type it, or pick from your library or the built-in types via the picker symbol; "None" removes the link. When a Library Type is set, it takes precedence over the Sub-Type at generation time; with none set, the Sub-Type applies. When the type you pick relies on a shared data type, Forge adds that data type into the graph for you — it appears as its own node with a connecting line, so the dependency is visible and travels with the graph when you deploy. Setting the same type again does not create duplicates.
Version — a read-only revision number that rises with every change. It prevents a change made elsewhere from being overwritten by accident.

Properties

The Properties section shows the object's properties, one per row:

Declared properties of the sub-type or library type appear as matching fields — number, switch, dropdown, or text — some marked required (*) or with a unit. You can clear their value but cannot remove the row.
Free-form properties can be edited freely and removed with the trash icon. Reverse-engineered objects bring such free-form entries, for example the block number, the project folder path, a flag for failsafe blocks, and the original TIA name.

Data Points

The Data Points section lists an object's named data points with their data type (and, where present, unit and value). The list is read-only. For reverse-engineered or freshly added objects it is usually empty — data points appear only when an object was loaded or authored with them.

Profiles — layering default values

A profile is a named set of default values that applies across a project graph. Instead of setting the same value on many objects one by one, you set it once in the profile — it then flows into the Effective Value column of the project objects and into the generated code. Values can be layered by Type, Role and Variant: a more specific value overrides a more general one.

Manage profiles

The Profiles view in the Forge view container lists every profile. Right-click an entry — or use the view's buttons:

New Profile — you give it an identifier and a display name. Identifiers may contain only letters, digits, and underscores.
Rename Profile / Duplicate Profile / Delete Profile — on a profile (delete asks first).

A double-click opens the profile in a tab.

Edit a profile

The profile editor is resolution-centric: you pick a target at the top, and below it you see, for each property, the value that results and where it comes from.

Pick the target: set Type to the block type whose defaults you want to set — or enter a Role — and optionally a Variant. Type and Role are mutually exclusive; the editor tells you so (for example "Clear Role to target a Type").
The table has three columns: Property, Effective Value and Source Layer.
- Inherited rows are dimmed; the source layer names where the value comes from — the built-in type default, the profile's Base, or a more general layer.
- Rows you set yourself show Owned in the source layer.
Set a value: double-click a cell in Effective Value and type — the row becomes Owned (your own value for exactly this target) and shows the typed value immediately.
Reset: the revert icon at the end of an Owned row clears your override; the row falls back to the inherited value.
Save: Save (or Ctrl+S) stores the profile; unsaved changes are marked with the usual dot on the tab. If you save a profile that has no values of its own yet, Studio confirms the save and reminds you that nothing is stored until you pick a Type and edit an Effective Value — picking a Type on its own stores nothing.

With Type set to "—", the table shows the profile's base values (empty at first for a new profile). Pick a Type to see and set its properties. The editor remembers the last Type, Role and Variant you chose for each profile and brings it back the next time you open the profile, so your own values are in view straight away.

One profile covers many targets. You are not limited to a single Type: switch the Type (or Role / Variant) at the top and set values again — each target you edit is kept in the same profile. So one profile can carry, for example, base defaults plus separate values for mixerT and agitator side by side. When the profile is applied, an object takes the values from the layers that match it, and a more specific layer wins over a more general one — Type over Base, and a Type+Variant combination over Type alone. An object of a Type you never set simply gets the base (or built-in) values.

Values as expressions

A value doesn't have to be a fixed constant — you can enter an expression instead, evaluated per object at generation time. Write it with a leading =, for example ={{ node.symbol }} fault or ={{ node.props.openTime + 2 }}. An expression can read the object's name (node.symbol), its role (node.role), its type (node.type), and the object's already-set constant properties (node.props.<name>).

To make a value start with a literal =, prefix it with = (=Start produces the text =Start).
In the editor the expression appears exactly as you typed it; it is evaluated only at generation time, per object.
If an expression cannot be evaluated, the build reports an error for that object and generates nothing — a faulty value is never silently used.

Apply a profile to a graph

Which profile and variant apply to a project graph is chosen in that graph's Inspector, in the Profiles section: pick a Profile from the list ("— None —" removes the assignment) and optionally a Variant. The chosen profile's defaults then appear in the Effective Value column of the project objects and flow into the generated code.

Preview generated source live

With a project object selected (in the Project Tree, the table, or on the map), "Preview Generated Source" (Command Palette) opens that object's generated source — read-only, right beside your work. The first time, Forge asks which code-generation targets to preview; the choice is remembered per graph. If the object has no generated source, a brief note appears in the Status Bar.

To make the preview follow your selection automatically, enable the Preview: Auto Open option in the Forge section of the Settings — the preview then refreshes by itself as you click through objects.

Validate the project graph

"Validate Project Graph" (Command Palette) scans a graph for anomalies — for instance a connection that comparable objects have but this one lacks, an empty required property, or an unusual numeric value. A notification summarizes warnings and notices, and the findings appear in the Diagnostics view under Anomaly Checks. Clicking a finding jumps straight to the affected object on the map. The check is read-only — it never changes the graph.

AI assistance

The chat assistant knows your project graphs: it can read objects and their properties, validate the graph, and — on your instruction — add, change, or remove objects and connections. Every change to the graph asks for your confirmation first, and you can let one through once, for the session, or for good if you would rather not be asked again.

The assistant also handles the machine catalog and CMS loop: ask it to declare a graph as a machine template, export the machine catalog to a file or push it to your Machine Catalog CMS, list the configurations published there, materialize a configuration (from a file or straight from the CMS, including sending the as-built manifest back), or push a machine's as-built manifest again after a deploy. Every step that changes something or talks to the CMS asks for your confirmation first, unless you allowed that step for the session or for good, and the strict validation is the same as with the commands: an invalid configuration materializes nothing.

Deploy the library to a PLC

One command materializes the whole library as blocks in a connected PLC.

Make sure Forge is connected and the TIA project has a PLC (connect the project via "Connect to Openness Manager").
Click Deploy (cloud icon) in the title bar of the Block Type Library — or run "Deploy Library to TIA Portal" from the Command Palette.
If the project has several PLCs, pick the target PLC from the list.
If blocks with the same names already exist, a confirmation appears with the number of blocks to be overwritten — confirm with "Deploy and Overwrite" or cancel.
A progress notification follows the deploy; at the end a notification reports how many blocks were imported into the PLC. The project is then compiled and saved.

The blocks land in the same group structure as in the library — nested folders are created as nested groups in the PLC. Deploying again reuses the existing groups and overwrites the blocks.

Supported content: program blocks (FB/FC/OB, global and instance DBs), PLC data types (UDTs), and PLC tag tables. Types in unsupported categories are skipped before the deploy and counted in the final notification; statement-list (STL) blocks are likewise skipped up front and named in the final notification with their reason. Contents from Software Units are also skipped up front and named in the final notification with their name and reason — deploying into Software Units is not yet supported.

Deploy a project graph

A project graph can be deployed straight into a connected PLC, too — with everything it holds: blocks, data types, and tag tables. The data types a block's interface relies on are deployed together with the block, so its interface resolves in TIA Portal instead of showing a missing data type.

Open the graph as a tab and click Deploy (rocket icon) in its title bar (visible while the TIA project is connected) — or click the rocket in the title bar of the Project Graphs list: the open graph is deployed; with none open, the only stored graph is used, and with several you pick one from a list. Alternatively run "Deploy Graph to TIA Portal" from the Command Palette.
If the project has several PLCs, pick the target PLC from the list.
If blocks with the same names already exist, confirm the overwrite with "Deploy and Overwrite".
At the end a notification reports how many blocks were imported into the PLC. If a block fails, the message names it with its name and reason — everything else is still imported. Items skipped up front — such as STL blocks, or tag tables from Software Units — are also listed in the message with their name and reason.

Machine configurator: from template to finished machine

The machine configurator turns a project graph into a reusable machine template with selectable options — and stamps out any number of concrete machine variants from it, fully wired, addressed, and ready to deploy to a PLC.

The flow in short: you define a template once (which devices, which options), receive a configuration file with the chosen options per order, materialize it into a concrete project graph, and deploy that to the PLC. An as-built manifest then documents machine-readably what was built.

Define a machine template

Open the project graph that should serve as the template — typically a reverse-engineered reference project.
Bind the device nodes to their device types: select a node and fill in the Device Binding section in the Inspector — there you set which captured device type backs the node and how many instances it should produce: a fixed count or driven by an option. Names are set here too: a pattern for the instance names and a pattern for each instance's block names (so dbPress becomes dbPress_Press_1, dbPress_Press_2, … per press).
In the title menu (…) of the graph tab, choose "Edit Machine Template Options" (also available from the Command Palette). A JSON editor opens with the template options.
Describe the template's identifier and display name plus its options — yes/no options, quantities with minimum and maximum, or choice lists — and optionally rules between options ("requires" / "excludes").
Save via "Save Machine Template Options" in the title menu of the JSON tab. Invalid input is rejected and nothing is saved.

Once a graph is a machine template, it can no longer be built or deployed directly — it is an abstract blueprint. A notice asks you to materialize a configuration first instead.

Export the machine catalog

"Export Machine Catalog" (via the cloud icon in the title bar of the Project Graphs list, or the Command Palette) writes a catalog file with every machine template in the project — options, rules, and a summary of the devices, but none of your template internals. An external selection system (say, a CMS or your sales tool) can build a selection UI from it and produce ready-made configuration files.

Materialize a configuration

Run "Materialize Machine Configuration" (via the cloud icon in the title bar of the Project Graphs list, or the Command Palette) and pick the configuration file.
Forge validates the file strictly: unknown options, violated bounds, or broken rules abort, and nothing is created. If the template changed since the configuration was made, a prompt asks whether to materialize anyway.
If a machine materialized from the same configuration already exists, Studio asks whether to replace it — units that no longer appear in the new configuration are named.
At the end a new, concrete project graph appears in the Project Graphs list: the shared type blocks (say, the press's function block) exactly once under their original names, plus per-instance data blocks named by your pattern, fully wired, with non-overlapping S7 addresses. The as-built manifest is written automatically next to the configuration file, and a notification reports how many instances were created.

Deploy the materialized machine

Deploy the materialized machine like any project graph (see above). The PLC ends up looking the way you would build it by hand: one type block per device type under its original name in the normal group structure, next to the instance data blocks of every configured instance with their unique names — three configured presses yield one fbPress and three instance DBs.

The as-built manifest

The manifest describes machine-readably what was built: all instances with their block names, addresses, and data points including connections — the foundation for downstream systems, say a SCADA binding itself to the PLC. It is written automatically on materialization; "Export As-Built Manifest" (title menu of the graph tab, visible only on materialized machines, or Command Palette) regenerates it at any time — for example after a deploy.

Working with a Machine Catalog CMS (optional)

Instead of passing catalog, configuration, and manifest files around by hand, Studio can run the whole loop directly against a Machine Catalog CMS — your company's central catalog store where sales or order handling configure machines. Your administrator provides the address and an access token. The catalog and CMS commands are gathered behind the cloud icon in the title bar of the Project Graphs list — one click opens the menu.

Set up: Enter the base address in Settings under Forge Machine Catalog CMS and store the token with the "Set Machine Catalog CMS Token" command — it is kept securely and never shown again. "Clear Machine Catalog CMS Token" removes it. While the address or token is missing, every CMS command tells you plainly what is still needed.

Push the catalog: "Push Machine Catalog to CMS" (cloud icon of the Project Graphs list, or Command Palette) uploads every machine template in the project together with its device-type summaries; the final notification reports the counts. Pushing again updates the entries without creating duplicates.

Materialize straight from the CMS: "Materialize Configuration from CMS" (also behind the cloud icon) lists the machine configurations published in the CMS (name, template, and last update) for you to pick. After the pick, the same strict validation and the same flow run as with the file-based way — including every prompt. The as-built manifest is written to the forge-manifests folder in your workspace and reported back to the CMS automatically, documenting the order as built. If a configuration from the CMS contains data that does not match the expected format, Studio aborts without creating anything.

Send the manifest again: "Push As-Built Manifest to CMS" (cloud icon of the Project Graphs list, title menu of the graph tab on materialized machines, or Command Palette) sends the manifest at any time — for example after a deploy. Studio finds the matching CMS configuration by name; with several candidates you pick from a list. With the setting "Automatically push the as-built manifest back to the Machine Catalog CMS after a materialized graph is deployed successfully" this happens by itself after every successful deploy.

Export a SCADA configuration from a selection

For downstream systems (say, a SCADA) Forge turns a canvas selection into a machine-readable SCADA configuration: the data points of your SCADA interface blocks with data type, start value, and comment, plus the variables of the selected tag tables with address and comment.

Mark the interfaces: right-click a data-block node in the graph → "Mark as SCADA Interface". Mark as many as you need; the Inspector shows the mark, running the command again removes it. The mark is stored with the graph.
Make a selection: select the nodes you want in the graph (the same multi-select as selective building) — the marked data blocks and the variables that belong with them.
"Export SCADA Configuration" (right-click the selection, or Command Palette): give it a name, pick a location — done, the file is <name>.scada.json. Nested structures appear as dotted paths (Drive.Setpoint).
"Push SCADA Configuration to CMS" stores the same configuration in the Machine Catalog CMS instead (address + token set up as above). Pushing again updates the entry without duplicates; your SCADA toolchain can fetch the configurations from there.

If something cannot be read — say, a block source is missing and no matching TIA project is connected — the export aborts with a clear message and no half-finished file is written. Variable addresses and comments come from the connected TIA project; without a connection the message names the affected table.

Export straight from the project tree

You don't need a Forge graph for a SCADA configuration. In the project tree, right-click a data block, a PLC data type (UDT), a tag table, or a folder and choose "Export as JSON" — you get the same <name>.scada.json. Checked items come along, a folder takes every matching block under it. Tag tables now also bring their constants and the variables' comments; PLC data types land in the file with their full member structure, default values, comments and external accessibility.

Generate from a CPU's OPC UA nodes

The richest configuration comes from the CPU's own OPC UA address space. Export it from the CPU context menu ("Export OPC UA Nodes"), then right-click the resulting file and choose "Generate SCADA from OPC UA Nodes". The result carries the real addresses your SCADA connects to, the tree structure, each signal's data type, and whether it is read-only or writable — exactly what the server actually exposes.

Generate a web dashboard

From a SCADA configuration Studio can build a runnable web dashboard. Set your dashboard server's address in Settings (Forge section), then run "Generate FUXA Project" on a .scada.json (or straight from the OPC UA nodes step): Studio builds displays and controls for every signal and sends them to the server, or writes them to a file for manual import. Writable signals appear as input fields, read-only ones as displays. Sending replaces the entire project on the server and asks you to confirm first. For a structured dashboard with several screens and a navigation sidebar, plan the screens on the SCADA page first (see below).

A short video walks through the whole flow, from a TIA Portal project to a running FUXA dashboard with live values over OPC UA: Generate a FUXA Web SCADA from a Siemens TIA Portal Project.

The SCADA page

Instead of running the steps one command at a time, open the SCADA page (Command Palette → "Open SCADA Page") to do everything in one place, from top to bottom:

Connection: enter your dashboard server's address, set or clear its access token, then Test Connection to read back the project that is on the server right now — its name and how many devices, views and signals it holds.
Deployment (optional): if you run your dashboard server with Docker, deploy a ready FUXA instance right here — on your own machine or a remote host — and start, stop, or restart it. The page waits for it to answer and fills in the address for you.
Node set: load a CPU's OPC UA nodes, either by exporting them from a connected CPU or by opening a node set file you exported earlier.
Tree and selection: browse the loaded nodes as a checkbox tree and tick exactly the signals you want on the dashboard; a running count shows how many blocks, signals and writable points you have picked.
Screens (optional): turn the signals you picked into a structured dashboard of several screens (an overview with one tile per plant module, then one screen per module) and edit that plan before you generate. See "Plan a multi-screen dashboard" below.
Generate: enter the OPC UA endpoint your dashboard connects to, then generate and send the dashboard to the server, or save it as a .fuxa.json or .scada.json file. With a screen plan active, the generated dashboard carries all the planned screens with a navigation sidebar; without a plan you get a single view of the picked signals. Only the signals you ticked are included, and sending replaces the whole project on the server after you confirm.

Everything the page does is also available as the individual commands above; the page just gathers them into one convenient workflow.

Plan a multi-screen dashboard

The Screens section of the SCADA page turns your picked signals into a set of ready-made screens instead of one flat view. It sits between the node-set tree and the generate options.

Propose Screens: with a node set loaded and signals selected, one click builds a screen plan for you. You get an Overview screen with one tile per plant module (each tile shows the module's name, a status lamp when the module has a status signal, and opens that module's screen), plus one screen per module with its signals grouped into sections. Very large groups get their own detail screen, reached by a button, and every screen has a Back button so you can always step out again.
Edit the plan: the proposed screens appear as an editable list. For each screen you can rename it, change its layout (Tiles, Sections, Table or Free), move it Up or Down, merge it into another screen with Merge Into…, or remove it. A summary line tells you how many screens and how many widgets the plan holds.
Background: each screen row has a Background… button that puts an SVG image (for example a plant drawing or a layout exported from a design tool) behind that screen's widgets. Once a file is chosen, the button opens a small menu to pick another file or remove the background. Unsafe content in the file (scripts, click handlers, links to external addresses) is removed automatically, and a short notice tells you when something was removed. A file that cannot be read or is not a usable SVG is reported, and the screen keeps no background.
Save, load and clear: Save Plan stores the plan as a .scadaplan.json file, and Load Plan brings it back later (load a node set first, since the plan belongs to its signals). Clear Plan discards the current plan.

When a plan is active and you choose Generate and Send to FUXA or Save as .fuxa.json, Studio builds the whole planned project. Each signal becomes the control that fits it: a lamp for on/off signals, a toggle button for switchable ones, a bar gauge for values (with limits taken from the signal's min and max comments), a slider for writable values with limits, and a plain value field otherwise. The controls are laid out across the planned screens with a navigation sidebar and clickable tiles, and each screen you gave a background shows that image behind its elements. Save as .scada.json still writes the plain signal snapshot of your current selection, without the screens.

Loading a different node set clears the plan, because the plan belongs to the signals you loaded. The Assistant Preview panel shows the screens you have planned, so you can check them before you generate.

Let the assistant propose the screens

Instead of assembling the screen plan by hand, you can ask the chat assistant to propose it for you. Load a node set on the SCADA page first, then open the chat and describe what you want, for example "Build a clear SCADA from this node set with one screen per plant area." The assistant reads the loaded signals, groups them into an overview screen and module screens, and picks the control that fits each signal: a readout or a dial for measured values, a lamp for status, a slider or an input field for setpoints, a button for commands, a chart for trends, plus navigation tiles between the screens. The proposal appears in the Screens section and the Assistant Preview panel, where you can review and adjust it like a screen set you planned yourself before you generate. Nothing is sent to the server without your confirmation.

Stage your own symbol library

When you deploy a FUXA instance from the SCADA page, the Deployment section gains a Stage Symbol Library… button once a FUXA instance is running. It lets you pick a folder of your own SVG symbol files – for example a tank, a pump, or a valve you drew yourself. Studio turns them into a symbol group and loads them into the running FUXA, so they appear in FUXA's editor next to the built-in shapes when you edit the generated screens. A short status reports how many symbols were staged and how many files were skipped.

Repeat this whenever the FUXA instance is rebuilt: staged symbols are not kept when the instance is recreated.

Use your own symbol as a switch

You can take your own symbol straight into the generated SCADA as a live switch, not only for editing in FUXA. On the SCADA page, use the button by the Screens section to pick a folder of your SVG symbols. Then give a switch your symbol: either through the symbol picker on the widget's row in the Screens section, or by asking the assistant in chat to bind a particular symbol to a variable. The switch gets your symbol, a variable, and an off and an on colour. Once generated, the symbol changes colour at runtime with the value of the variable. More than two states are possible when you give several colour ranges. Draw the symbol so that recolouring its shapes looks right, since the off and on colour overrides the shape's own colours.

See what Forge is doing

The Output panel has its own Forge channel: it shows live what the generator and the Forge connection are doing — helpful when a capture or a deploy doesn't produce the result you expected.

Notes & limitations

Forge and the TIA project must both be connected. If either connection is missing, or the project has no PLC, a notification says so and nothing is changed.
Overwriting requires confirmation — same-named blocks are only replaced after you confirm.
Graphical blocks (LAD/FBD) may be rejected by TIA Portal depending on the target CPU; SCL blocks, instance and global DBs, UDTs, and tag tables deploy reliably. The final notification reports any blocks that were not imported, with the reason.
Statement-list blocks (STL) are skipped up front during a deploy and named in the final notification with their name and reason — instead of producing a TIA Portal error.
Same names in several places: when two items share one name — say a data type under the PLC data types and a same-named one inside a Software Unit — both are captured; the item from the Software Unit gets a unique label in the library that shows which Software Unit it belongs to. Only identical duplicates in the same place are skipped quietly.
Tag tables from Software Units are currently skipped up front on deploy and named in the final notification with their name and reason — deploying into Software Units is not yet supported.
Deploying nested groups requires TIA Portal V17 or newer.

← Previous

Library Management

Hardware