Pexon Consulting | 11 Min. Lesezeit | 20.06.2026
TL;DR
Siemens NX Automatisierung verbindet die NX Open API mit einem LLM: Ihr beschreibt eine Konstruktionsaufgabe in Worten, das Modell generiert ein lauffähiges NXOpen-Python-Journal. Pexon baut solche Pipelines als 6-Wochen-Pilot für Maschinenbauer. Ergebnis aus Projekten: bis zu 75 Prozent weniger Zeit für repetitive Modellierung, ohne neue CAD-Lizenz.
Das Problem: Konstrukteure modellieren immer wieder dasselbe von Hand
Ein typischer Konstruktionsleiter im Maschinenbau kennt das Muster. Varianten einer Baugruppe, Bohrbilder nach Norm, Stücklisten-Updates, Zeichnungsableitungen mit immer gleichen Ansichten. Studien beziffern den Anteil repetitiver CAD-Tätigkeiten an der Engineering-Zeit auf bis zu 40 Prozent, was pro Ingenieur über 17.000 US-Dollar an gebundener Arbeitszeit im Jahr kostet (Synergy Codes).
NX bringt die Lösung im Werkzeugkasten mit, nur nutzt sie kaum jemand. Die NX Open API gibt programmatischen Zugriff auf das komplette NX-Modell und alle Befehle. Für Maschinenbauer ist das einer der konkretesten KI-Use-Cases in der Fertigung, weil er ohne Sensorik und ohne neue Hardware auskommt. Der Grund für die niedrige Nutzung ist banal: Konstrukteure sind keine Softwareentwickler. Das Journal aufzunehmen ist einfach, aber daraus ein parametrisiertes, robustes Skript zu machen, scheitert an fehlender Programmiererfahrung.
Genau hier setzt der LLM-Hebel an. Ein Sprachmodell wie claude-sonnet-4-6 (Anthropic, veröffentlicht am 15.02.2026, 1M-Token-Kontext) kennt die NXOpen-Klassenstruktur und übersetzt eine Aufgabenbeschreibung in API-Code. Der Konstrukteur beschreibt, das Modell schreibt das Journal, NX führt es aus.
Wir sagen es deutlich: Das ersetzt keinen Konstrukteur. Es nimmt ihm die Tipparbeit ab, die ohnehin niemand machen will.
Wie die NX Open API mit Python funktioniert
Die NX Open API ist die programmatische Schnittstelle zu Siemens NX, ansprechbar aus Python, C#, VB.NET, C++ und Java. Python ist seit NX 10 dabei und für Konstrukteure die naheliegende Wahl, weil die Syntax lesbar ist und NX einen eingebauten Python-Interpreter mitbringt. Jede Aktion in der NX-Oberfläche lässt sich aufzeichnen und als Code abspielen.
Der schnellste Einstieg führt über das Journal. Ihr nehmt eine Aktion interaktiv auf, NX erzeugt daraus Code, ihr seht sofort, welche Klassen und Methoden hinter einem Befehl stecken. Das ist die Trainingsgrundlage, sowohl für euch als auch für das LLM, dem ihr später Beispiele mitgebt.
Ein minimales Journal, das sich in NX über Datei > Ausführen > Journal starten lässt, sieht so aus:
# hello_nx.py - minimales NXOpen-Journal
# Gibt Text ins NX-Informationsfenster aus, um die Session zu prüfen
import NXOpen
def main():
# aktive NX-Session und das laufende Bauteil holen
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
# Listing-Window (Informationsfenster) öffnen und beschreiben
listing = session.ListingWindow
listing.Open()
listing.WriteLine("NX Open ist aktiv.")
listing.WriteLine("Aktives Bauteil: " + work_part.FullPath)
if __name__ == "__main__":
main()Die drei zentralen Bausteine tauchen in jedem Journal auf: NXOpen.Session.GetSession() als Einstiegspunkt, session.Parts.Work als aktives Bauteil und ein Builder-Objekt für jede Geometrie-Operation. Wer diese drei verstanden hat, liest jedes generierte Journal.
Tutorial: Eine parametrische Geometrie per NX Open erzeugen
Der nächste Schritt ist echte Geometrie. Das folgende Journal erzeugt einen parametrischen Zylinder, etwa für eine Welle oder einen Bolzen. Die Maße kommen als Variablen herein, womit das Skript bereits eine Varianten-Engine ist: gleiche Logik, andere Werte.
# create_cylinder.py - parametrischer Zylinder via NX Open
# Erzeugt einen Zylinder mit konfigurierbarem Durchmesser und Höhe
import NXOpen
import NXOpen.Features
def create_cylinder(diameter_mm, height_mm):
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
# Undo-Marker setzen, damit der Schritt rückgängig gemacht werden kann
markId = session.SetUndoMark(
NXOpen.Session.MarkVisibility.Visible, "Zylinder erzeugen")
# Cylinder-Builder anlegen (Null = neues Feature, kein Edit)
builder = work_part.Features.CreateCylinderBuilder(NXOpen.Features.Feature.Null)
builder.BooleanOption.Type = NXOpen.GeometricUtilities.BooleanOperation.BooleanType.Create
# Achse: Ursprung + Richtung Z definieren
origin = NXOpen.Point3d(0.0, 0.0, 0.0)
z_axis = NXOpen.Vector3d(0.0, 0.0, 1.0)
direction = work_part.Directions.CreateDirection(
origin, z_axis, NXOpen.SmartObject.UpdateOption.WithinModeling)
# Maße als Expressions setzen (parametrisch, später änderbar)
builder.Diameter.SetFormula(str(diameter_mm))
builder.Height.SetFormula(str(height_mm))
# Feature committen und Builder aufräumen
feature = builder.CommitFeature()
builder.Destroy()
session.SetUndoMarkName(markId, "Zylinder fertig")
return feature
def main():
# Beispiel: Welle Durchmesser 25 mm, Länge 120 mm
create_cylinder(25.0, 120.0)
if __name__ == "__main__":
main()Was hier passiert, ist der Kern jeder NX-Automatisierung. Ihr holt das Bauteil, setzt einen Undo-Marker (Pflicht für sauberes Fehlerverhalten), konfiguriert einen Builder, committet das Feature und räumt auf. Genau dieses Muster wiederholt sich für Bohrungen, Taschen, Verrundungen, Patterns. Wer den Zylinder verstanden hat, hat das Schema.
Die offizielle Referenz für alle Builder-Klassen und Signaturen findet ihr in der NX Open API Dokumentation, die jede Klasse mit Methoden und Parametern auflistet.
Der KI-Hebel: LLM generiert das NXOpen-Journal
Hier wird es interessant für alle, die nicht selbst programmieren. Statt das Journal von Hand zu schreiben, beschreibt ihr die Aufgabe in Klartext, und das LLM erzeugt den NXOpen-Code. Der folgende Aufruf zeigt das Muster mit dem Anthropic SDK und claude-sonnet-4-6.
# nx_codegen.py - LLM generiert ein NXOpen-Journal aus einer Aufgabenbeschreibung
# Voraussetzung: pip install anthropic, ANTHROPIC_API_KEY gesetzt
import anthropic
client = anthropic.Anthropic()
# System-Prompt: das Modell auf NXOpen-Python und unsere Konventionen festnageln
SYSTEM = """Du bist ein NX-Open-Experte. Gib ausschließlich lauffähigen
NXOpen-Python-Code zurück, keine Erklärungen. Pflicht:
- import NXOpen und NXOpen.Features
- Session über NXOpen.Session.GetSession()
- vor jeder Geometrie einen SetUndoMark setzen
- Builder nach CommitFeature mit Destroy() aufräumen
- deutsche Kommentare"""
def generate_journal(aufgabe: str) -> str:
"""Erzeugt aus einer natürlichsprachigen Aufgabe ein NXOpen-Journal."""
response = client.messages.create(
model="claude-sonnet-4-6", # Modell-ID, Stand Juni 2026
max_tokens=2000,
temperature=0, # deterministisch, keine Code-Varianz
system=SYSTEM,
messages=[{"role": "user", "content": aufgabe}],
)
return response.content[0].text
if __name__ == "__main__":
aufgabe = ("Erzeuge eine Platte 200x100x10 mm und setze ein Bohrbild "
"aus 4 Durchgangsbohrungen Durchmesser 8 mm, je 15 mm "
"von den Ecken entfernt.")
code = generate_journal(aufgabe)
# generiertes Journal speichern, danach manuell in NX prüfen und ausführen
with open("generiert_bohrbild.py", "w", encoding="utf-8") as f:
f.write(code)
print("Journal geschrieben nach generiert_bohrbild.py")Der Workflow ist damit: Aufgabe in Worten, generiertes Journal als Datei, Review durch den Konstrukteur, Ausführung in NX. temperature=0 sorgt dafür, dass dieselbe Aufgabe denselben Code erzeugt, was für reproduzierbare Konstruktion zwingend ist.
Ein Wort zur Erwartungshaltung, weil hier viel Unsinn kursiert. Das Modell trifft bei gut umrissenen Operationen, für die es Trainingsbeispiele gesehen hat, sehr zuverlässig. Bei exotischen NX-Funktionen oder firmenspezifischen Makros halluziniert es Methoden, die es nicht gibt. Deshalb gehört in jede produktive Pipeline ein Validierungsschritt, der den Code gegen die geladene NXOpen-Klassenliste prüft, bevor er in NX läuft. Wir lassen generierten CAD-Code nie ungeprüft auf ein Produktivmodell los.
Was das in der Praxis bringt: Zahlen statt Versprechen
Die belastbaren Zahlen kommen nicht aus dem Marketing, sondern aus realen Automatisierungsprojekten. Wer repetitive Zeichnungs- und Modellierungsschritte automatisiert, spart 15 bis 20 Prozent der Teamzeit. In einem dokumentierten Fall sank die Konstruktionszeit von 24 auf rund 6 Stunden, eine Reduktion um 75 Prozent (Descode Solutions). Bei reinen Dokumentationsaufgaben sind bis zu 90 Prozent Zeitersparnis messbar.
Der entscheidende Punkt für die Wirtschaftlichkeitsrechnung: NX Open ist in eurer NX-Lizenz enthalten. Es fällt keine zusätzliche CAD-Lizenz an. Die einzigen neuen Kosten sind die LLM-API-Aufrufe, und die sind klein. claude-sonnet-4-6 kostet 3 US-Dollar pro Million Input-Token und 15 US-Dollar pro Million Output-Token. Ein generiertes Journal liegt im Bereich weniger Cent.
Diese Zahlen gelten für wiederkehrende, regelhafte Arbeit. Für echte Neukonstruktion bringt der Ansatz wenig, dort ist der Kopf des Ingenieurs der Engpass, nicht die Tippgeschwindigkeit. Unsere klare Empfehlung: Automatisiert dort, wo dieselbe Operation pro Woche mehrfach anfällt, und lasst kreative Konstruktion in Ruhe.
Worauf ihr bei der Einführung achten solltet
Eine NX-Open-Automatisierung scheitert selten an der Technik und meist an der Organisation. Aus unseren Projekten die fünf Punkte, die wirklich zählen:
- Validierung vor Ausführung. Generierten Code immer gegen die geladene NXOpen-API prüfen, nie blind in ein Produktivmodell laufen lassen. Ein Halluzinations-Fehler in der Geometrie ist teurer als der gesparte Aufwand.
- Versionskanal fixieren. Builder-Signaturen ändern sich zwischen NX-Releases. Legt fest, gegen welchen Continuous-Release-Channel ihr entwickelt, und testet beim Wechsel.
- Beispiel-Journals als Trainingsbasis. Das LLM wird deutlich besser, wenn ihr ihm eure aufgenommenen Journals als Beispiele mitgebt. Investiert in eine kleine, saubere Beispielsammlung.
- Mensch im Loop. Der Konstrukteur reviewt das generierte Journal vor dem ersten Lauf. Das ist kein Misstrauen, sondern Engineering-Hygiene.
- Klein anfangen. Ein einziger, oft wiederkehrender Workflow als Pilot. Nicht die ganze Konstruktion auf einmal automatisieren wollen.
Häufig gestellte Fragen
Brauche ich eine zusätzliche Lizenz für die NX Open API?
Nein. NX Open ist in der NX-Lizenz enthalten und bringt einen eigenen Python-Interpreter mit. Zusätzliche Kosten entstehen nur durch die LLM-API-Aufrufe, die im Cent-Bereich pro generiertem Journal liegen.
Welche Programmiersprache sollte ich für NX-Automatisierung wählen?
Python für den Einstieg und für Konstrukteure ohne tiefe Programmiererfahrung, weil die Syntax lesbar ist und NX es seit NX 10 nativ unterstützt. C# oder VB.NET nur, wenn ihr kompilierte, in die NX-Oberfläche integrierte Erweiterungen mit Dialogen braucht.
Was kostet eine KI-gestützte NX-Automatisierung im Betrieb?
Die laufenden Kosten sind klein. Bei claude-sonnet-4-6 zahlt ihr 3 US-Dollar pro Million Input- und 15 US-Dollar pro Million Output-Token, ein einzelnes generiertes Journal liegt bei wenigen Cent. Der Hauptaufwand ist die einmalige Einrichtung der Pipeline, die wir als 6-Wochen-Pilot abbilden.
Kann das LLM auch fehlerhaften NX-Code erzeugen?
Ja, und das müsst ihr einplanen. Bei gängigen Operationen ist die Trefferquote hoch, bei exotischen NX-Funktionen erfindet das Modell manchmal Methoden, die es nicht gibt. Deshalb gehört ein Validierungsschritt gegen die echte NXOpen-Klassenliste plus ein Konstrukteur-Review vor jede produktive Ausführung.
NX Open Journal aufnehmen oder gleich per LLM generieren?
Beides kombiniert. Nehmt eine Operation einmal als Journal auf, um die richtigen Klassen und Methoden zu sehen, und nutzt diese Aufnahmen als Beispiele für das LLM. Die Journal-Aufnahme ist eure Trainingsgrundlage, der LLM-Aufruf ist die Skalierung.
Nächster Schritt
Wenn ihr einen wiederkehrenden Konstruktions-Workflow habt, der das Team Stunden pro Woche kostet, lohnt ein Pilot an genau diesem Workflow. Wir bauen die NX-Open-Pipeline mit LLM-Anbindung an einem realen Bauteil aus eurem Haus auf, inklusive Validierungsschritt und Review-Prozess.
Verwandte Themen
→KI-Workflows mit Hooks, Skills und MCP automatisieren
→KI entlang der Wertschöpfungskette in der Fertigung
