Siemens NX Automation: Die Kurzfassung
Siemens NX Automation bedeutet, wiederkehrende manuelle Schritte in NX, etwa Zeichnungserstellung, PMI-Platzierung, Normteil-Einfügung und Modellprüfungen, durch Code oder Regeln zu ersetzen, die jedes Mal gleich ablaufen. inteliScience baut das auf NX Open für Engineering-Teams in DACH und Europa. Typisches erstes Projekt: Variantenzeichnungen, die jeweils Stunden dauerten, entstehen in Minuten.
| Manueller NX-Workflow | Automatisiert mit NX Open | |
|---|---|---|
| Variantenzeichnung | 2 bis 3 Stunden pro Mitglied einer Teilefamilie | Minuten pro Familie, vorlagengesteuert, in Teamcenter geprüft |
| PMI bei geänderter Geometrie | Nach jeder Änderung von Hand neu platziert und neu nummeriert | Regelbasierte Platzierung und Nummerierung, die sich selbst neu ordnet |
| Firmeninterne Konstruktionsregeln | Fallen bei der Freigabe oder in der Fertigung auf | Werden während des Modellierens am Arbeitsplatz des Konstrukteurs geprüft |
| Wer macht die Arbeit | Der Konstrukteur, wieder und wieder | Ein getestetes Werkzeug, einmal; der Konstrukteur prüft |
Das Problem: NX-Teams automatisieren zuerst das Falsche
Die meisten Siemens NX Automation-Vorhaben beginnen mit dem, was ein motivierter Konstrukteur letzte Woche als Journal aufgezeichnet hat, und bleiben sechs Monate später stecken, wenn dieser Konstrukteur den Job wechselt oder NX die Version. Die Projekte, die überleben, starten mit einer anderen Frage: Welche wiederkehrende Aufgabe kostet die Abteilung pro Monat die meisten Stunden, und lassen sich ihre Regeln aufschreiben?
Die Stunden sind real. In den Abteilungen, die wir bewerten, beanspruchen wiederkehrendes Modellieren, Zeichnungsrevisionen und Dokumentation regelmäßig ein Drittel der Arbeitswoche eines Konstrukteurs. Bei Engineer-to-Order-Herstellern haben wir erlebt, dass allein die Zeichnungsarbeit bis zur Hälfte der Engineering-Zeit beansprucht, weil jeder konfigurierte Auftrag einen Zeichnungssatz braucht, den niemand erstellen will.
Unsere klare Empfehlung, bevor eine Zeile Code geschrieben wird: Listen Sie die zehn am häufigsten wiederholten Aufgaben auf, schreiben Sie zu jeder die monatlichen Stunden, und markieren Sie diejenigen, deren Regeln ein erfahrener Konstrukteur in einer Sitzung diktieren kann. Das sind Ihre Kandidaten. Alles, was Urteilsvermögen braucht, bleibt beim Konstrukteur, zumindest in Phase eins.
Was zuerst automatisieren: Sechs Aufgaben, die sich innerhalb eines Quartals rechnen
Die folgenden Aufgaben haben sich in unseren Projekten innerhalb eines Quartals amortisiert, in dieser Reihenfolge. Jede hat klare Regeln, hohe Wiederholung und ein leicht prüfbares Ergebnis, genau das Profil, das ein erstes Siemens NX Automation-Projekt braucht.
- Zeichnungen für Teilefamilien. Aus einer Zeichnungsvorlage erstellt das Werkzeug die Zeichnung für jedes Mitglied einer Familie und legt sie in Teamcenter ab. Wir haben das zweimal unabhängig voneinander für verschiedene Kunden gebaut; beide Male war es der schnellste Gewinn auf der Liste.
- PMI-Platzierung und -Nummerierung. Annotationen, die anhand der X-, Y- und Z-Koordinaten eines Koordinatensystems platziert und nummeriert werden, mit einem Algorithmus, der bei Konstruktionsänderungen neu ordnet und neu nummeriert. Manuelle PMI-Pflege bricht bei jeder Revision; eine regelbasierte Struktur korrigiert sich selbst.
- Konstruktionsregel-Prüfungen am Arbeitsplatz. Eine Prüfsuite, die Verstöße gegen interne Richtlinien meldet, während der Konstrukteur noch modelliert, statt erst bei der Freigabe. Die Kosten eines Regelverstoßes wachsen mit jedem Gate, das er passiert.
- Normteil-Platzierung und Aufräumroutinen. Reference Sets, Layer-Disziplin, Attributvollständigkeit, Hygiene unterdrückter Features, in einem Durchlauf auf eine ganze Baugruppe angewendet.
- Variantenerzeugung aus Expressions. Transformatoren- und Maschinenbau leben von Familien ähnlicher Teile; Expressions plus NX Open erzeugen die Variante, ihre Zeichnung und ihre Stückliste (BOM), statt dass ein Konstrukteur jede einzeln von Hand bearbeitet.
- Batch-Konvertierung und Export. STEP-Dateien, die auf ein definiertes Koordinatensystem ausgerichtet und je Ansicht als STEP, PRT und JPEG exportiert werden, gesteuert über eine Steuerdatei, mit NX headless hinter einem Webservice.
Wovon raten wir als Einstieg ab? Von allem, was die Konstruktionsabsicht berührt: die Bezugsstrategie für eine neue Teileklasse wählen, eine Toleranz festlegen oder ein Legacy-Modell überarbeiten, dessen Historie niemand versteht. Das sind Review-Probleme, keine Automatisierungsprobleme, und sie in ein Skript zu zwingen erzeugt ein Werkzeug, dem Konstrukteure misstrauen.
Welches NX-Automatisierungswerkzeug für welche Aufgabe
NX liefert mehr Automatisierungsschichten mit, als die meisten Teams nutzen, und die falsche Schicht zu wählen ist der zweithäufigste Grund, warum ein Projekt stecken bleibt. Die Tabelle ist unsere Arbeitskarte, Stand Designcenter 2606, dem Release vom Juni 2026 , in dem Siemens NX in Designcenter umbenannt hat.
| Schicht | Am besten für | Wer pflegt sie | Upgrade-Risiko |
|---|---|---|---|
| Journale (aufgezeichnete NX-Sitzungen, Python, C#, VB, Java) | Herausfinden, welche API-Aufrufe ein Workflow braucht; einmalige Batch-Jobs | Der Konstrukteur, der es aufgezeichnet hat | Hoch: aufgezeichneter Code verdrahtet Objektnamen und Dialogzustände fest |
| NX Open (die offizielle API, .NET, Python, C++, Java) | Alles, was Sie an mehr als einen Konstrukteur ausliefern: Custom Commands, Zeichnungs- und PMI-Erzeugung, Teamcenter-Integration | Ein Entwickler, mit Tests | Mittel: API ist versioniert und dokumentiert; Deprecations werden angekündigt |
| Expressions, Teilefamilien, Product Template Studio | Konfigurierbare Produkte, vertriebsgetriebene Varianten, codefreie Vorlagen mit einfacher Oberfläche | Erfahrene Konstrukteure | Niedrig: lebt im Teil |
| Knowledge Fusion | Regelgetriebene Geometrie, bei der die Regeln im Modell leben und auf Änderungen reagieren müssen | KF-Spezialisten, am Markt selten | Mittel; das Risiko sind die Skills, nicht die API |
| Algorithmic Modeling (visuelle Logik, Logic Editor) | Knotenbasierte Regeln für Geometrie-, Mess- und Annotationsverhalten ohne Programmierung; wiederverwendbar über die Reuse Library | Power-User | Niedrig bis mittel; neu, wird noch ausgebaut |
| KI-Agenten über MCP | Konversationeller Zugriff, um das Bauteil zu lesen und, mit Gate, typisierte NX Open-Tools auszuführen | Entwickler plus eine KI-Schicht | Hängt vollständig vom Gate ab, das Sie bauen |
Drei Positionen, die wir nach genug Projekten mit Sicherheit vertreten.
Journale sind zum Lernen da, nicht zum Ausliefern. Zeichnen Sie das Journal auf, lesen Sie, was NX getan hat, und schreiben Sie dann das eigentliche Werkzeug in NX Open mit benannten Eingaben und Fehlerbehandlung. Journaling ist in jeder Lizenz der NX Mach Series enthalten, weshalb es für alle der erste Schritt ist und für niemanden der letzte.
NX Open schlägt Knowledge Fusion für fast jedes Team, das KF nicht bereits im Einsatz hat. Die API ist dokumentiert, versioniert und man findet Leute dafür; KF-Expertise ist knapp und wird knapper. Die Abwägung haben wir ausführlich beschrieben in unserem Vergleich von NXOpen und Knowledge Fusion.
Algorithmic Modeling ist jetzt einen Piloten wert, keinen Rollout. Siemens hat es in 2606 für Basen in der additiven Fertigung eingeführt, mit einem Logic Editor und Freigabe über die Reuse Library, und die Richtung stimmt: Regeln als Knoten, nicht als Skripte. Geben Sie ihm einen Power-User und einen klar abgegrenzten Anwendungsfall, bevor Sie einen Prozess darauf setzen.
Ein erstes NX Open-Werkzeug: Vom Journal zum Batch-Job
Das Beispiel unten hat die Form eines ersten ausgelieferten Werkzeugs: ein Python-NX-Open-Skript, das eine Baugruppe durchläuft, auf jeder Komponente ein Standardattribut setzt und berichtet, was es geändert hat. Aus einem Journal aufgezeichnet, dann mit expliziten Eingaben, einer Prüfung und einem Protokoll neu geschrieben. Es läuft aus dem NX-Python-Interpreter oder headless über den Journal-Runner.
# set_attribute_batch.py — NX Open (Python), tested on NX 2412 and Designcenter 2606
# Walks the assembly tree of the work part and sets a company attribute on every component.
import NXOpen
import NXOpen.Assemblies
def set_attribute_on_components(attr_name: str, attr_value: str) -> int:
session = NXOpen.Session.GetSession()
work = session.Parts.Work
if work.ComponentAssembly.RootComponent is None:
raise RuntimeError("work part is not an assembly")
changed = 0
seen = set()
stack = [work.ComponentAssembly.RootComponent]
while stack:
comp = stack.pop()
part = comp.Prototype.OwningPart
if part.FullPath not in seen:
seen.add(part.FullPath)
current = part.GetUserAttributeAsString(attr_name, NXOpen.NXObject.AttributeType.String, -1) if part.HasUserAttribute(attr_name, NXOpen.NXObject.AttributeType.String, -1) else None
if current != attr_value:
part.SetUserAttribute(attr_name, -1, attr_value, NXOpen.Update.Option.Now)
changed += 1
session.ListingWindow.Open()
session.ListingWindow.WriteLine(f"{part.Leaf}: {attr_name} = {attr_value}")
stack.extend(comp.GetChildren())
return changed
if __name__ == "__main__":
import sys
session = NXOpen.Session.GetSession()
path = sys.argv[-1] if sys.argv else ""
if path.lower().endswith(".prt"): # batch: assembly passed after -args
session.Parts.OpenBaseDisplay(path)
n = set_attribute_on_components("ISC_RELEASE_STATE", "IN_WORK")
session.ListingWindow.WriteLine(f"components updated: {n}")
if path.lower().endswith(".prt"):
session.Parts.Work.Save(NXOpen.BasePart.SaveComponents.TrueValue, NXOpen.BasePart.CloseAfterSave.TrueValue)Führen Sie es headless gegen einen Ordner mit Baugruppen aus, ohne die NX-Oberfläche zu öffnen, denn so gehören Batch-Jobs in die Produktion:
# Windows, NX/Designcenter install: run a journal in batch mode for every assembly in a folder
for %f in (C:\work\assemblies\*_asm.prt) do (
"C:\Program Files\Siemens\NX2606\NXBIN\run_journal.exe" C:\tools\set_attribute_batch.py -args "%f"
)Zwei Gewohnheiten unterscheiden das vom Journal, aus dem es entstanden ist. Das Werkzeug nimmt seine Eingaben als Parameter entgegen und verweigert die Ausführung auf einem Teil, das keine Baugruppe ist. Und es schreibt, was es geändert hat, ins Listing Window, damit der ausführende Konstrukteur das Ergebnis prüfen kann, statt ihm zu vertrauen.
Das läuft als POC. Was für die Produktion fehlt: ein Deployment, das Ihr CAD-Admin kontrolliert, Tests gegen die NX-Versionen, die Sie tatsächlich einsetzen, Fehlerbehandlung für gesperrte und ausgecheckte Teile, Teamcenter-Bewusstsein und ein Verantwortlicher, wenn der Autor weiterzieht. Wir schließen die Lücke von “läuft auf meinem Rechner” zu “läuft in der Konstruktionsabteilung” — sehen Sie, wie wir produktionsreife NX-Workflow-Automatisierung bauen.
NX-Automatisierung, die das nächste Upgrade überlebt
Ein 2024 geschriebenes NX Open-Werkzeug trifft dieses Jahr auf Designcenter 2606, und die Frage ist, ob es jemand getestet hat. Siemens versioniert die NX Open API und dokumentiert Deprecations, der Bruch ist also vorhersehbar; was meist fehlt, sind ein Testsatz und ein Verantwortlicher.
Was wir in jedem Projekt einrichten und was wir auch für Werkzeuge empfehlen, die wir nicht geschrieben haben:
- Ein Regressionssatz aus fünf bis zehn echten Teilen pro Werkzeug, mit erwarteten Ergebnissen, ausgeführt vor jedem NX-Upgrade.
- Parameter und Einheiten in jeder Signatur. Nie Bildschirm-Picks, nie fest codierte Objektnamen aus einem Journal.
- Ein Deployment-Pfad. Ein Custom Command, das Ihr CAD-Administrator installiert und aktualisiert, kein per E-Mail herumgereichtes Skript.
- Benannte Verantwortung. Ein Werkzeug ohne Verantwortlichen ist technische Schuld mit Startdatum.
Wenn Sie ein Regal voller Journale und Visual-Basic-Makros haben, die niemand anzufassen wagt, ist die ehrliche Lösung ein Modernisierungsdurchgang statt eines Neuschreibens von null; unser Service zur Modernisierung von NX-Legacy-Code beginnt mit einer Bestandsaufnahme dessen, was noch läuft.
Wo KI in der Siemens NX Automation heute ihren Platz hat
KI ändert 2026 zwei Dinge und lässt den deterministischen Kern in Ruhe. Erstens die Code-Generierung: Ein Frontier-Modell wie claude-sonnet-5 schreibt NX Open-Gerüstcode zuverlässig und erfindet API-Aufrufe, die es nicht gibt, weshalb das Verankern auf der NX Open-Referenz und das headless Verifizieren jedes Journals die Zeit bis zu einem geprüften Werkzeug ungefähr halbiert. Das haben wir gemessen in unseren Tests zur NX Open-Code-Generierung. Zweitens die Agenten: Über das Model Context Protocol kann ein Assistent das geöffnete Teil lesen und nach einer Vorschau und Bestätigung dieselben oben beschriebenen typisierten NX Open-Tools aufrufen.
Siemens’ eigener Designcenter Copilot, ausgeliefert mit 2606, antwortet aus der Dokumentation und der aktuellen Aufgabe. Er führt kein NX Open für Sie aus, und Stand September 2026 gibt es keinen offiziellen Siemens-MCP-Server für NX-Modellierung. Für die Automatisierung heißt das: Die KI-Schicht ist etwas, das Sie Ihrem Werkzeugkasten hinzufügen, nicht etwas, das ihn ersetzt.
Unsere Position: Regeln deterministisch halten, KI Code generieren und erklären lassen, und Agenten Tools nur über ein Gate aufrufen lassen. Teams, die ein Modell direkt Journale schreiben und ausführen ließen, haben das ausnahmslos zurückgedreht.
Siemens NX KI steht bei inteliScience für Lösungen, die diese Haltung umsetzen: Assistenten, die antworten, Agenten, die über ein Freigabe-Gate handeln, und Geometrie-Tools, die an Ihren Teilen getestet sind.
Kosten und Zeitplan für ein erstes Projekt
Ein erstes Siemens NX Automation-Projekt ist kleiner, als die meisten Teams erwarten, weil die erste Aufgabe nach Wiederholung und klaren Regeln ausgewählt wird. Unser kostenloses NX-Automatisierungs-Assessment prüft Ihre wiederkehrenden Workflows und ordnet sie nach eingesparten Stunden. Ein NX Open Proof of Concept, ein konkreter Anwendungsfall, gebaut und getestet auf Ihren eigenen Daten in Ihrer NX-Umgebung, beginnt bei €3,000. Ein Proof-of-Value-Sprint zum Festpreis auf Ihren eigenen NX Open-Bibliotheken beginnt bei €12,900. Vollständige Automatisierungsprojekte, etwa ein Zeichnungsgenerator für eine Produktlinie mit Teamcenter-Ablage, liegen im mittleren fünfstelligen Bereich und werden nach dem Proof of Concept dimensioniert, nicht davor.
Zeitplan: zwei Wochen für einen Proof of Concept zu einer Aufgabe, sechs bis zehn Wochen für ein Produktionswerkzeug mit Tests, Deployment und Übergabe. Die Amortisation der oben genannten Zeichnungs- und PMI-Anwendungsfälle lag in jedem Projekt, in dem die Aufgabenliste aus gemessenen Stunden aufgebaut wurde, innerhalb eines Quartals.
Häufig gestellte Fragen
Was ist Siemens NX Automation?
Siemens NX Automation ist der Einsatz der Programmier- und Regelschichten von NX, vor allem NX Open, Journale, Expressions und Product Template Studio, um wiederkehrende Modellier-, Zeichnungs-, Prüf- und Dokumentationsaufgaben ohne manuelle Klicks auszuführen. Die Aufgabe läuft jedes Mal gleich ab, und der Konstrukteur prüft das Ergebnis, statt es selbst zu erzeugen.
Was sollten wir in NX zuerst automatisieren?
Beginnen Sie mit der Aufgabe, die pro Monat die meisten Stunden kostet und deren Regeln ein erfahrener Konstrukteur in einer Sitzung diktieren kann. In unseren Projekten ist das fast immer die Zeichnungserstellung für Teilefamilien, gefolgt von PMI-Platzierung und -Nummerierung und dann Konstruktionsregel-Prüfungen direkt am Arbeitsplatz des Konstrukteurs.
NX-Journale vs. NX Open: Was ist der Unterschied?
Ein Journal ist die Aufzeichnung einer interaktiven NX-Sitzung als Code; NX Open ist die offizielle, versionierte API, die das Journal aufruft. Journale eignen sich ideal, um herauszufinden, welche Aufrufe ein Workflow braucht. Werkzeuge, die mehr als ein Konstrukteur ausführt, sollten in NX Open mit Parametern, Fehlerbehandlung und Tests neu geschrieben werden.
Was kostet Siemens NX Automation?
Ein Assessment Ihrer wiederkehrenden Workflows ist bei uns kostenlos. Ein Proof of Concept für einen Anwendungsfall beginnt bei €3,000, ein Proof-of-Value-Sprint auf Ihren eigenen Bibliotheken bei €12,900, und vollständige Produktionswerkzeuge wie ein Zeichnungsgenerator mit Teamcenter-Ablage liegen im mittleren fünfstelligen Bereich. Die erste Aufgabe amortisiert sich in der Regel innerhalb eines Quartals.
Sollten wir Python oder C# für NX Open verwenden?
Python ist der schnellste Einstieg, weil NX einen Interpreter mitliefert und Journale darin aufgezeichnet werden; C# und .NET sind die bessere Wahl für Custom Commands, die Ihr CAD-Administrator für eine ganze Abteilung ausrollt. Wir haben beide ausführlich verglichen in unserem Leitfaden NXOpen Python vs. C#; die meisten unserer Produktionswerkzeuge sind .NET, die meisten unserer Prototypen Python.