NX-Konstruktionsautomatisierung & Altcode

Ihre beste Automatisierung hat jemand geschrieben, der 2019 gegangen ist. Seitdem hat sich niemand mehr herangetraut.

Fast jeder NX-Betrieb mit Geschichte hat sie: die VB-Journals, die Schriftfelder füllen, die C# NXOpen-Makros, die die Standardgehäuse erzeugen, manchmal ein GRIP-Programm, das seit den Unigraphics-Tagen still drei CAD-Generationen überlebt hat. Einst waren sie der Produktivitätsvorsprung der Abteilung. Dann ging der Autor, NX brachte weiter Releases heraus, und heute läuft die Automatisierung “irgendwie” — undokumentiert, ungetestet, auf einer NX-Version, die Sie nicht zu aktualisieren wagen, und tut etwas, das niemand vollständig erklären kann.

Dieser Zustand hat einen Preis, den Sie doppelt zahlen. Einmal in Angst: Jedes NX-Upgrade wird zum Glücksspiel gegen Ihre eigenen Werkzeuge, also werden Upgrades verschoben und die ganze Installation altert. Und einmal in Verlust: Die Konstruktionslogik in diesem Makro — echtes, hart erarbeitetes Ingenieurwissen — ist einen kaputten API-Aufruf davon entfernt, verschwunden zu sein.

Genau diese Lücke berühren Siemens’ Copilots nicht: Sie assistieren generisch innerhalb von NX, aber sie kennen weder Ihren eigenen Code noch Ihre undokumentierten APIs noch Ihre Werkslogik. Wir machen das hauptberuflich — und Large Language Models haben die Wirtschaftlichkeit dieser Arbeit grundlegend verändert. Code-Archäologie, die früher Wochen Reverse Engineering kostete, dauert heute Tage: verstehen, auf unterstützte NXOpen-APIs portieren, gegen echte Modelle testen. Und auf demselben Fundament bauen wir die neue Automatisierung, für die Sie nie Kapazität hatten.

// Verwaiste Automatisierung, in Zahlen

0+ Jahre

Alter der ältesten Automatisierung, die bei typischen NX-Betrieben noch produktiv läuft — teils GRIP

0 / Jahr

NX-Releases pro Jahr — jedes eine potenzielle Breaking Change für undokumentierten Eigencode

0 Doku

Zeilen Dokumentation zu dem Makro, von dem Ihr Auftragsfluss abhängt — seien Sie ehrlich

Wo. → Tage

was LLM-gestützte Code-Archäologie mit dem Aufwand gemacht hat, Altautomatisierung zu verstehen und zu portieren

Eingefrorene Upgrades, Wissen als Geisel

Fragen Sie einen NX-Administrator, warum die Installation noch zwei Releases zurückliegt, und irgendwo in der Antwort finden Sie ein Makro. Nicht das CAD-System, nicht die Anwender — die Eigenautomatisierung, die niemand gefahrlos testen kann, weil niemand genau weiß, was sie tut. Also wartet das Upgrade, dann wartet es wieder, und der Abstand zwischen Ihrer Installation und dem aktuellen NX wächst: fehlende Funktionen, die Ihre Wettbewerber nutzen, nicht eingespielte Sicherheitspatches, sich schließende Support-Fenster.

Das tiefere Problem ist, was dieser Code enthält. Ein Makro, das Ihre Standardkomponenten korrekt erzeugt, ist nicht bloß Werkzeug — es ist die ausführbare Form von Konstruktionsentscheidungen: welche Abstände, welche Benennungslogik, welche Zeichnungskonventionen. Als sein Autor ging, verlor die Abteilung die Fähigkeit, es zu ändern; wenn es endgültig kaputtgeht, verliert sie das Wissen selbst. Ein Neuschrieb von null bedeutet, Regeln erneut herzuleiten, die schon einmal gelöst waren.

Der Ausweg ist weder “nie anfassen” noch “alles neu schreiben”. Es ist systematische Rettung: den Code wieder verständlich machen, dokumentieren, was er tatsächlich tut, ihn auf unterstützte NXOpen-APIs portieren, unter Versionskontrolle und Tests stellen — und ihn dann auf diesem gesunden Fundament erweitern. Vor zwei Jahren war das ein Luxusprojekt. Mit LLM-Unterstützung, die liest, entwirft und übersetzt, während Ingenieure prüfen und verifizieren, ist es heute Routinearbeit zum Festpreis.

// Rettung in der Praxis — dieselbe Routine, vorher und nachher

Gefunden — Journal, zuletzt 2016 bearbeitet, Autor weg

Sub M3()  Dim s As Session = Session.GetSession()  Dim wp As Part = s.Parts.Work  ' keine Kommentare, gleich kommen magische Zahlen  Dim h As Double = 12.5 * f1 + 3  Call DoIt(wp, h, 4, True, False, 2)  uf.Modl.CreateFixedDplane(...)  ' old UF callEnd Sub

Gerettet — NXOpen C#, dokumentiert, aktuelle API

/// Erzeugt den Flanschrohling für die/// Gehäusefamilie H3. Höhenregel nach Werks-/// norm: h = 12,5·sizeFactor + 3.public void CreateFlangeBlank(Part work,    H3Config cfg){  var height = FlangeRules.Height(cfg);  FlangeRules.CreateDatum(work, cfg);  // via DatumPlaneBuilder}

KI-Analyse (von Ingenieuren verifiziert): Dieses Makro baut Flanschrohlinge für die Gehäusefamilie H3; die magische Konstante 12,5 setzt eine Werksnorm um und ist jetzt benannt, dokumentiert und per Unit-Test gegen 14 Referenzmodelle abgesichert.

Retten. Bauen. Befähigen.

Das Angebot hat drei Ebenen, die aufeinander aufbauen — die meisten Kunden starten mit Retten, weil dort die Angst sitzt, und nutzen dann das gesunde Fundament, um zu bauen, was vorher nie möglich war:

01 — RETTEN

Verwaister Code, zurück unter Kontrolle

Bestandsaufnahme Ihrer Makrolandschaft — was existiert, was läuft, wovon das Geschäft abhängt. Eine LLM-gestützte Analyse zeigt, was jede Routine tatsächlich tut (von Ingenieuren an echten Modellen verifiziert); anschließend werden die kritischen Routinen auf unterstützte NXOpen-APIs portiert, unter Versionskontrolle gestellt und getestet. Das nächste NX-Upgrade ist kein Glücksspiel mehr.

Code-ArchäologieAPI-MigrationJournals · GRIP · KF

02 — BAUEN

Neue Automatisierung, im LLM-Tempo

Modellierungsautomatisierung, Zeichnungsableitung, Stapelverarbeitung, Teamcenter-integrierte Workflows — in Ihrer Sprache beschrieben, vom LLM entworfen, von uns entwickelt und getestet. Entwicklung, die sich früher preislich verbot, passt jetzt in mittelständische Budgets, und alles wird deterministisch ausgeliefert: Dieselbe Eingabe erzeugt jedes Mal dasselbe freigegebene Ergebnis.

NXOpen C# / C++ / PythonZeichnungsautomatisierungStapel- & TC-Workflows

03 — BEFÄHIGEN

Ihr Team behält die Schlüssel

Der Sinn der Rettung ist, dass sie nie wieder nötig wird. Der Code ist versioniert, Ihre Power-User lernen, ihn mit LLM-Unterstützung zu lesen und zu erweitern — eine Fähigkeit, die keinen eigenen Entwickler mehr erfordert —, und Wartungsrichtlinien legen fest, wie Änderungen getestet und freigegeben werden. Für die schwierigen Fälle bleiben wir erreichbar; wir weigern uns, der nächste Single Point of Failure zu werden.

TrainingVersionskontrolleLLM-gestützte Wartung

Wann rechnet sich das?

Sie sind ein Kandidat, wenn Ihnen das meiste hiervon bekannt vorkommt:

Eigene NX-Automatisierung existiert — Journals, NXOpen-Makros, Knowledge-Fusion-Regeln — und ihre Autoren sind weg oder gehen bald.
NX-Upgrades werden aus Angst verschoben , was den Eigencode betrifft, und die Installation altert mit ihnen.
Niemand kann sagen, was die kritischen Makros genau tun — es gibt keine Dokumentation, keine Tests, keine Versionskontrolle.
Repetitive Modellier- und Zeichnungsarbeit wird von Hand erledigt, weil neue Automatisierung immer zu teuer war , um sie zu beauftragen.
Variantenreiche Produktfamilien schreien nach Automatisierung — genau der Fall, den unser Angebot zur Variantenkonstruktion end-to-end abdeckt.
Sie betreiben Siemens NX (irgendeine aktuelle Version — genau darum geht es ja) und wollen Werkzeuge auf unterstützten Erweiterungspunkten.

Unser NX-Automatisierungs-Stack

Full-Stack-NX-Entwicklung über die Technologien hinweg, auf denen Ihre Automatisierung läuft — alte wie neue.

NXOpen (C# / C++ / Python) Journals (VB) GRIP-Analyse & -Migration Knowledge Fusion Product Template Studio Zeichnungsautomatisierung Batch / headless NX Teamcenter-Integration (SOA/ITK) Versionskontrolle · CI · Tests LLM-gestützte Entwicklung (on-prem)

Vorher und nachher: der Tag des NX-Upgrades

Der klarste Test für die Gesundheit Ihrer Automatisierung ist der Tag, an dem ein neues NX-Release erscheint. So sieht dieser Tag auf beiden Seiten der Veränderung aus:

Vorher — das Glücksspiel

Upgrade zweimal verschoben — „wegen der Makros“
Testplan: alles einmal laufen lassen und hoffen
Das Schriftfeld-Journal scheitert still — entdeckt von einem Kunden
Der eine Kollege, der den Code „so ungefähr“ kennt, ist im Urlaub
Rollback. Nächster Versuch: nächstes Jahr

Nachher — die Routine

Die Automatisierung läuft in einer Testumgebung gegen das neue Release — vor dem Rollout
Die Testsuite meldet zwei veraltete APIs — an einem Nachmittag behoben
Jede Routine dokumentiert — kein Kollege ist ein Single Point of Failure
Das Upgrade kommt planmäßig — Anwender bekommen aktuelles NX, die IT ihr Wochenende
Die Makros sind wieder ein Aktivposten — und ein Fundament zum Weiterbauen

Warum inteliScience — und wie wir KI ohne Glücksspiel einsetzen

Diese Seite beschreibt unsere Kerndisziplin. Wir bauen jeden Tag NX- und Teamcenter-Anpassungen auf Siemens’ unterstützten Erweiterungspunkten — dieselbe upgrade-sichere Philosophie hinter unserer Teamcenter-Programmierung gilt für jede Zeile NXOpen, die wir anfassen. Und wir sprechen beide Sprachen, die der Job braucht: den Code und die Konstruktion. Ein Ingenieur, der nie neben einem Konstrukteur gesessen hat, portiert die Syntax Ihres Makros und verfehlt seine Absicht; unsere Leute erkennen, dass die magische Zahl 12,5 eine Werksnorm ist und keine Laune.

Bei der KI ist die Arbeitsteilung streng, denn produktive CAD-Werkzeuge sind kein Ort für Improvisation. LLMs lesen, entwerfen, übersetzen und erklären — sie sind spektakulär darin, eine undokumentierte Codebasis zu verdauen und ein modernes Äquivalent vorzuschlagen. Ingenieure prüfen, testen und geben frei — jede portierte Routine wird gegen echte Referenzmodelle verifiziert, bevor sie überhaupt in die Nähe der Produktion kommt, und alles wird deterministisch und versionskontrolliert ausgeliefert. Das LLM läuft nicht in Ihrem NX; sein Ergebnis tut es, nachdem es sich das Recht dazu verdient hat.

Eine ehrliche Anmerkung zu GRIP und dem wirklich Alten: Nicht alles lässt sich eins zu eins portieren, und etwas anderes zu behaupten hieße, Ihnen Archäologie als Magie zu verkaufen. Wo eine direkte Migration keinen Sinn ergibt, extrahieren wir die Logik — die Regeln, die der Code kodiert — und bauen sie sauber auf NXOpen neu. Das Wissen überlebt; die technischen Schulden nicht.

Festpreis — keine Tagessätze, keine Überraschungen

Automatisierungs-Rettungs-Pilot

€9,900 Festpreis

Vollständige Inventur Ihrer Automatisierungslandschaft — was existiert, was läuft, was kritisch ist
LLM-gestützte Analyse der wichtigsten Routinen — von Ingenieuren verifiziert
Ihr geschäftskritischstes Makro modernisiert, portiert und auf aktuellem NX getestet
Versionskontrolle, Test-Setup und Freigabeprozess als Vorlage etabliert
Modernisierungs-Roadmap für den Rest — nach Geschäftsrisiko priorisiert

Pilotgespräch starten

2–3 Wochen · auf Ihrer NX-Installation · der gesamte Code, die Dokumentation und die Roadmap gehören Ihnen, wie auch immer Sie sich danach entscheiden.

Zum Vergleich

Die Kosten des eingefrorenen Zustands

Die kritischen Makros von null neu schreiben, wenn sie endgültig kaputtgehen — unter Zeitdruck
Jahre an NX-Funktionen und -Fixes, die Ihre Anwender nicht bekommen, während Upgrades warten
Und das nicht eingepreiste Risiko: Konstruktionswissen, das nur als unlesbarer Code existiert

Häufige Fragen

LLM-generierter Code in produktiven CAD-Werkzeugen — ist das sicher?

Für sich genommen nicht — und genau deshalb machen wir das nicht so. Das LLM liest, entwirft und übersetzt; Ingenieure prüfen jede Zeile, und nichts geht raus, ohne Tests gegen echte Referenzmodelle aus Ihrer Produktion zu bestehen. Was in Ihrem NX landet, ist deterministischer, versionskontrollierter, von Menschen freigegebener Code — der nur eben um ein Vielfaches schneller entstanden ist als früher. Die KI beschleunigt die Arbeit; sie wird nie zur Freigabeinstanz.

Wir betreiben noch GRIP-Programme. Lassen die sich wirklich migrieren?

Von Fall zu Fall — und wir sagen Ihnen ehrlich, welcher Fall Ihrer ist. Manches GRIP portiert sauber; vieles davon sollte gar nicht portiert, sondern übersetztwerden: Wir extrahieren die Logik, die das Programm kodiert — die Regeln, die Konventionen, die Berechnungen — und bauen sie auf unterstützten NXOpen-APIs neu. Der Unterschied zählt: Sie bewahren dreißig Jahre Konstruktionswissen, nicht dreißig Jahre Syntax. Die Inventurphase des Piloten ordnet jede Routine einer Kategorie zu: portieren, neu bauen oder stilllegen.

Unser Makro-Autor ist noch da. Brauchen wir das überhaupt?

Das ist der bestmögliche Zeitpunkt — wirklich. Dokumentation, die entsteht, solange der Autor sie noch prüfen kann, ist doppelt so viel wert, und der Schritt von „Wissen in einem Kopf“ zu „versioniertem Code, den Ihr Team testen kann“ ist jetzt schnell und günstig, nach der Abschiedsfeier dagegen teuer und verlustbehaftet. Mehrere Rettungsprojekte beginnen genau so: als strukturierte Wissenssicherung zwölf Monate vor einem Ruhestand.

Können unsere eigenen Leute die Automatisierung danach pflegen?

Die Rechte werden im Vertrag vereinbart. Und Wartbarkeit ist ein Designziel, kein Versprechen — Code wird so geschrieben, dass man ihn lesen kann, und die Enable-Ebene schult Ihre Power-User darin, ihn mit LLM-Unterstützung zu erweitern, was diese Hürde tatsächlich gesenkt hat: NXOpen-Code zu lesen und anzupassen erfordert keinen Berufsentwickler mehr. Für die schwierigen Fälle bleiben wir erreichbar, aber für die alltäglichen Änderungen braucht man uns nicht mehr. Wir weigern uns, der nächste Single Point of Failure zu werden — das würde nur die Geschichte wiederholen, mit der diese Seite beginnt.

Macht das nicht ohnehin Siemens' NX-Copilot?

Nein — andere Ebene. Die Copilots von Siemens assistieren Anwendern innerhalb von NX mit generischem Wissen: Befehle, Best Practices, Standard-Workflows. Sie kennen weder Ihre Makrolandschaft noch Ihre in zwanzig Jahre altem Code kodierten Werksnormen noch Ihre Teamcenter-Integration — und sie portieren, testen oder geben nichts frei. Eigene Automatisierung auf Ihrer eigenen Logik ist genau die Schicht, die werksspezifisch bleibt, und deshalb bauen wir sie und Ihnen gehört sie.

Wie verhält sich das zu Ihrem Angebot für Variantenkonstruktion?

Diese Seite ist die Fähigkeit; jene Seite ist ihr größter Ertrag. Automatisierte Variantenkonstruktion (siehe unser Energie-Angebot für Transformatorenhersteller) ist das, was Sie bauen, sobald das Fundament gesund ist: Regeln, die aus Auftragsparametern Modelle und Zeichnungssätze machen. Viele Kunden gehen genau in dieser Reihenfolge vor — erst Retten, weil die alten Makros meist schon die Hälfte der Regeln enthalten, dann darauf die Variantenautomatisierung bauen. Wenn Ihr Schmerz eher die Varianten als der Altcode sind, starten Sie auf jener Seite; die Technologie darunter ist dieselbe.

Irgendwo in Ihrem NX läuft ein Makro, das niemand versteht. Machen wir es wieder zu Ihrem.

Schicken Sie uns Ihre gruseligste Routine — die, die niemand anzufassen wagt — und wir zeigen Ihnen, was die LLM-gestützte Analyse darin findet, verifiziert von einem Ingenieur, der NXOpen spricht.

Mit einem NX-Automatisierungs-Ingenieur sprechen

Wir sind jederzeit für Sie da: Kontaktieren Sie uns mit Ihren Fragen – wir begleiten Sie Schritt für Schritt.

Telefon: +40 774 463 429
Unser Standort: Str. Ploiești 9, 400157
Cluj-Napoca, Rumänien
E-Mail: info@inteliscience.net
LinkedIn: inteliScience auf LinkedIn
YouTube: inteliScience auf YouTube