← Blog
2026-07-18
Generating blocks with TIA Openness
Forty motor blocks that differ only in name and interface? That is not a case for manual work but for code generation over TIA Openness: set it up cleanly once, then produce the series.
Two routes into the project
- External sources (SCL as text). The most direct route for SCL: one source file per block, imported as an external source, blocks generated from it. Templates are plain text files; any tool can produce them.
- SimaticML (XML). Openness exports and imports blocks as XML, including LAD/FBD networks. More powerful than the text route, but tied to the schema of the specific Portal version.
The workflow in practice
- Build the reference: set up one block cleanly by hand in TIA Portal and export it. That is your template.
- Parameterize: everything that varies per instance (name, interface, comments) becomes a placeholder.
- Produce the series: a script fills the placeholders, or an AI generates the variants straight from the description.
- Import and compile: the compile against the real project is the gate. What does not build does not get in.
The pitfalls
- The XML schema is tied to the Portal version. A V17 export cannot blindly be imported into V21.
- Timestamps and IDs do not belong in the template, or every diff turns into noise.
- Openness does not export know-how-protected blocks.
- Openness needs an installed TIA Portal and a user in the Windows "Siemens TIA Openness" group.
Generated is only half the job
A generated block is worthless as long as it is only "probably correct". That is why SCL unit tests and versioning with Git belong in the same flow. AnyAutomation Studio has exactly this path built in: describe, generate, import, test.