Bausteine generieren mit TIA Openness

Vierzig Motorbausteine, die sich nur in Namen und Schnittstelle unterscheiden? Das ist kein Fall für Handarbeit, sondern für Codegenerierung über TIA Openness: einmal sauber vorlegen, dann die Serie erzeugen.

Zwei Wege ins Projekt

• Externe Quellen (SCL als Text). Der direkteste Weg für SCL: eine Quelldatei pro Baustein, als externe Quelle importieren, daraus Bausteine erzeugen lassen. Vorlagen sind einfache Textdateien, jedes Werkzeug kann sie erzeugen.
• SimaticML (XML). Openness exportiert und importiert Bausteine als XML, inklusive KOP/FUP-Netzwerken. Mächtiger als der Textweg, aber an das Schema der jeweiligen Portal-Version gebunden.

Der Ablauf in der Praxis

1. Referenz bauen: einen Baustein im TIA Portal von Hand sauber aufsetzen und exportieren. Das ist deine Vorlage.
2. Parametrisieren: alles, was pro Instanz variiert (Name, Schnittstelle, Kommentare), wird zum Platzhalter.
3. Serie erzeugen: ein Skript füllt die Platzhalter, oder eine KI generiert die Varianten gleich aus der Beschreibung.
4. Importieren und kompilieren: der Compile gegen das echte Projekt ist das Gate. Was nicht baut, kommt nicht rein.

Die Stolpersteine

• Das XML-Schema hängt an der Portal-Version. Ein V17-Export lässt sich nicht blind nach V21 importieren.
• Zeitstempel und IDs gehören nicht in die Vorlage, sonst rauscht jeder Diff.
• Know-how-geschützte Bausteine exportiert Openness nicht.
• Openness braucht ein installiertes TIA Portal und einen Benutzer in der Windows-Gruppe „Siemens TIA Openness".

Generiert ist erst die Hälfte

Ein generierter Baustein ist wertlos, solange er nur „vermutlich richtig" ist. Deshalb gehören SCL-Unit-Tests und Versionierung mit Git in denselben Fluss. In AnyAutomation Studio ist genau dieser Weg eingebaut: beschreiben, generieren, importieren, testen.