NXOpen-API-Migration: Die Kurzfassung
NXOpen-API-Migration ist die Arbeit, Journals und kompilierte NX-Open-Bibliotheken auf das nächste Siemens-NX-Release (Designcenter) zu heben, ohne Produktionstools zu stoppen. inteliScience, ein rumänischer Nearshore-Engineering-Partner eine Stunde voraus gegenüber CET, behandelt jeden Sechs-Monats-Drop als Compile-und-Diff-Auftrag. Das Ergebnis ist Automatisierung, die auf Designcenter 2606 weiterläuft.
Das Problem: Tools, die nur auf dem NX des letzten Jahres laufen
Die NXOpen-API-Migration scheitert, wenn die IT den CAD-Seat aktualisiert und das Nacht-Journal oder das signierte Add-in nicht startet. Siemens NX ist nicht das Problem. Seats, die nie gegen die neuen NXBIN Assemblies neu gebaut wurden, sind es. Named Drops kommen etwa alle sechs Monate. Monatliche Updates sind keine Ausrede, den Rebuild zu überspringen.
Denselben Stillstand sehen wir in DACH-Programmen. Ein Journal von 2019 wurde 2021 zur DLL. NX ist zweimal weitergezogen. Niemand hat das Projekt neu ausgerichtet. An dem Tag, an dem Designcenter 2606 landet, ist der Menüeintrag weg.
Unsere Empfehlung: halten Sie NX aktuell und behandeln Sie die NXOpen-API-Migration als geplantes Engineering. Die Paketierung (Journal versus signierte Bibliothek) steht in Journal versus kompiliertem NXOpen. Dieser Beitrag bleibt beim Bruch von Version zu Version.
Was zwischen NX-Releases tatsächlich bricht
Binäre Verweise, zurückgezogene Open-C-Einsprungspunkte und Journal-Bezeichner aus einer alten Aufzeichnung sind das, was bricht. Das NXOpen-Objektmodell bleibt. Behandeln Sie jedes Sechs-Monats-Release als neues Compiler-Ziel, nicht als Neuschreiben der Designregeln, die Sie bereits kodiert haben.
Siemens hat Continuous Release 2019 gestartet. Jahr-Monat-Namen begannen mit NX 2206 im Juni 2022. Im Januar 2025 wurde die Suite als Designcenter NX bezeichnet. Am 23. Juni 2026 teilte Siemens mit, dass das Juni-2026-Release zum Download bereitsteht, mit dem CAD-Namen Designcenter (Familie 2606). Die nächste Named Family ist 2612. Siemens hat im September 2026 ein Designcenter-2612-Early-Access-Program durchgeführt, einschließlich einer virtuellen Woche vom 31. August bis 4. September und Vor-Ort-Wochen in Mason, Ohio.
| Schicht | Wofür wir Zeit einplanen | Was üblicherweise überlebt |
|---|---|---|
| NXOpen .NET / Python | Session, Teil, die meisten Builder | Als obsolete markierte Member, später entfernt |
Open C / NXOpen.UF | Aufrufe mit dokumentiertem Nachfolger | UF_* Namen ohne Nachfolger |
| Projektdatei | Quellcode, der Ihnen gehört | Alte NXOpen.dll, NXOpen.UF.dll, NXOpen.Utilities.dll, NXOpenUI.dll Verweise |
| Journal | Der Algorithmus | FindObject("...") Strings aus einer Session |
| Signierung | Author auf dem Build-Seat | Signing Resource für das neue Kit neu erzeugt |
Das Splash-Screen-Rebranding ist kein API-Bruch. Bindings bleiben C++, C# und VB.NET, Java und Python. Siemens dokumentiert “NX Open differences between releases” in den Release Notes zu NX 2206. Lesen Sie dasselbe Thema für die Version, in die Sie gehen.
Veraltet ist nicht gelöscht. Eine Durchstreichung kann länger als einen Drop dauern. Wir würden die Warnung lieber auf der vorherigen Named Family beheben, als einen fehlenden Export auf 2606 zu debuggen, wenn die Fertigung schon umgestellt ist.
Wie wir eine als veraltet markierte NX-Open-API finden
Eine als veraltet markierte NX-Open-API finden Sie, indem Sie den Compiler auf die neuen NX-Bibliotheken zeigen und jedes obsolete Member abgehen, das die IDE markiert. Zuerst Release Notes. Dann Grep. Eine Forumsliste von 2014 ist die Art, wie Sie Aufrufe “reparieren”, die gar nicht in Ihrem Tree liegen.
Release Notes, dann das Open-Kit
Öffnen Sie “NX Open differences between releases” für die Zielversion. Die 2206-Notes zeigen das öffentliche Muster. Ihre Support-Center-Kopie für 2606 ist die, die zählt. Ein Journal, das einen zurückgezogenen NX-Befehl steuert, schlägt fehl, selbst wenn C# kompiliert. Open-C-Kits liefern uf_legacy_header.txt, uf_legacy_source.txt, und uf_ui_legacy_source.txt für alte Namen aus der FORTRAN-Ära. Nutzen Sie diese Dateien oder ersetzen Sie den Aufruf. Erfinden Sie keine Signatur.
NXBIN neu ausrichten und neu kompilieren
Für .NET entfernen Sie die alten NXBIN-Verweise und fügen Sie NXOpen.dll, NXOpen.UF.dll, NXOpen.Utilities.dll, NXOpen.Guide.dll, und NXOpenUI.dll aus der neuen Installation hinzu. Kompilieren Sie neu. Durchstreichung plus Tooltip ist die Spezifikation, wenn Siemens einen Nachfolger benannt hat. Leerer Tooltip: anhalten und die Differences-Liste lesen.
Python-Journals überspringen diese Durchstreichung. Spielen Sie sie auf einem Sandbox-Seat mit 2606. Fehler kommen als Exceptions, später als bei einem C#-Rebuild. Unsere klare Empfehlung: wenn ein Visual-Studio-Projekt existiert, migrieren Sie das zuerst, dann das Journal.
- Vergleichen Sie den letzten grünen Build mit den neuen
NXBINDatumsangaben. - Kompilieren Sie neu und behandeln Sie obsolete NXOpen-Member auf dem kritischen Pfad als Fehler.
- Durchsuchen Sie das Repo nach
UF_,uc, undFindObject(. - Spielen Sie jedes Journal auf einem Sandbox-Seat, einen Ordner nach dem anderen.
- Vergleichen Sie die Listing-Window-Ausgabe gegen ein Golden Part.
Überspringen Sie Schritt 2 und Sie werden eine Journal-Migration “abschließen”, die immer noch die alten DLLs linkt.
Eine Migrationsreihenfolge, die die Automatisierung am Laufen hält
Migrieren Sie das Compiler-Ziel, dann die Critical-Path- UF_* Aufrufe, dann Journals, dann die Seats. Niemals andersherum. User zuerst bedeutet ein dunkles Menü und ein War Room. inteliScience führt den Rebuild als Nearshore-Engineering aus Rumänien aus (EET, CET+1, nicht die DACH-Uhr).
- Inventar. Jede
.vb,.cs,.py,.cpp,.dll, und Menüdatei, plus wer sie startet. - Sandbox-NX. Installieren Sie das Ziel neben dem aktuellen Seat. Überschreiben Sie nicht das produktive
UGII_BASE_DIRbevor die Suite grün ist. - Leerer Rebuild. Nur neue NXBIN-Verweise. Kompilierfehler beheben, keine Logikänderungen.
- Kritischer Pfad. Veraltete Aufrufe auf dem Nightly Job. Kosmetische Journals später.
- Golden Part. Eine Referenz
.prtund eine Ausgabe, die Sie vergleichen können. - Signieren und bereitstellen. Neue Signing Resource, Pilotgruppe, dann die Fläche.
- Erst dann lassen Sie die IT das vorherige NX außer Betrieb nehmen.
Smoke-Test für die Sandbox mit Session, Work Part und Listing Window.
# Sandbox smoke test, Designcenter 2606. Recorded-journal shape.
import NXOpen
theSession = NXOpen.Session.GetSession()
workPart = theSession.Parts.Work
lw = theSession.ListingWindow
lw.Open()
if workPart is None:
lw.WriteLine("FAIL: no work part")
else:
lw.WriteLine("OK: work part is loaded")
lw.Close()Wenn dieser Block auf 2606 kein OK drucken kann, beheben Sie die Installation, bevor Sie Feature-Builder anfassen. Fünfzig Journals und drei DLLs sind dann Software-Wartung, kein CAD-Admin-Nachmittag.
Das läuft als POC. Was für Produktion fehlt: Versions-Pinning, ein zweiter Engineer, der neu kompilieren kann, Golden-Part-Diffs in CI und ein Kalender bei jedem Sechs-Monats-NX-Drop statt eines Wochenend-Scrambles. Wir nehmen Journals und DLLs, die nur noch auf dem Seat des letzten Jahres laufen, und halten sie auf dem aktuellen Designcenter-Release am Leben: Modernisierung von NX-Open-Legacy-Code.
Was üblicherweise überlebt, und was wir nicht schnell flicken
Parametrische Absicht, Block UI Styler .dlx -Dateien, die Sie noch haben, und Golden-Part-Tests überstehen ein NX-Open-Upgrade. Aufgezeichnete FindObject Strings und kopiertes Open C von 2004 nicht. Den Shortcut “alte DLL wrappen und hoffen” lehnen wir ab.
FindObject ist ein Schnappschuss einer Session. Spielen Sie ihn auf einem umstrukturierten Part ab, und der Bezeichner ist weg. Während der Journal-Migration selektieren Sie nach Typ, Attribut oder einem Builder, den Sie selbst besitzen.
NXOpen.UF bleibt, weil große Landschaften es noch aufrufen. Setzen Sie ein Warnungsbudget auf den kritischen Pfad, dann arbeiten Sie den Rest über zwei Continuous-Release-Zyklen ab (zwölf Monate). Ein vollständiger UF-Purge an einem Wochenende ist der Weg, wie CAM-Regressionen landen. Koppeln Sie NX mit dieser Praxis. Frieren Sie den Seat nicht stattdessen ein.
Kosten und Kalender: zwei Named Releases pro Jahr
Budgetieren Sie die NXOpen-API-Migration als wiederkehrende Position, nicht als einmaliges Projekt. Zwei Named Families pro Jahr (2206 dann 2212, jetzt 2606 mit 2612 bereits im EAP) sind die Uhr. Monatliche Updates sind die falsche Woche, um DLLs neu auszurichten.
Die NX-CAD-Produktseite von Siemens nennt Continuous Release alle sechs Monate seit 2019, mit Jahr-Monat-Namen ab NX 2206 (Juni 2022). Wir fahren monatliche Updates auf einem Pilot-Seat ein und richten NXBIN auf der Named Family neu aus.
Wir erfinden keine Euro-Zahl, die Siemens nicht druckt. Ein leerer Rebuild eines kompilierenden C#-Add-ins sind Stunden. Ein Ordner unsignierter Journals ohne Repo sind Wochen. Author-Signierung ist ein Siemens-Angebot. Setzen Sie den leeren Rebuild vor dem EAP in den Kalender. Teams beim Designcenter-2612-EAP im September 2026 hatten bereits eine Sandbox.
API-Änderungen sind ein Teil eines Releasewechsels. Unser Service für den NX Releasewechsel plant und testet den gesamten Umstieg, einschließlich Vorlagen, Customer Defaults und CAM-Postprozessoren.
Häufig gestellte Fragen
Fragen von CAD-Admins zur NXOpen-API-Migration bündeln sich um Timing, Kosten, Journals versus DLLs und ob ein Rewrite günstiger wäre. Die Antworten darunter stehen für sich. Wenn die Landschaft mehr als ein Add-in umfasst, ist der nächste Schritt ein eingegrenztes Inventar, nicht noch ein Forum-Thread.
Was bricht zuerst bei einer NXOpen-API-Migration?
Kompilierte Verweise auf frühere NXBIN -Kopien von NXOpen.dll, dann veraltete Member, die im letzten Release noch Warnungen waren, dann FindObject -Strings. Das Session-Objektmodell ist nicht das, was am ersten Tag ausfällt. Ihre Projektdatei ist es.
Wie finde ich einen als veraltet markierten NX-Open-API-Aufruf, ohne Namen zu raten?
Richten Sie Visual Studio auf die neuen NX-Binaries aus und lesen Sie jeden obsoleten Tooltip. Gegenprüfen Sie “NX Open differences between releases” für diese Version. Für Python spielen Sie das Journal auf einem Sandbox-Seat. Wenn die Siemens-Docs keinen Nachfolger nennen, lassen Sie den Aufruf.
Was kostet eine NXOpen-API-Migration?
Siemens veröffentlicht keinen Listenpreis für die Migration von NX Open. Rechnen Sie Author auf dem Build-Seat, Sandbox-NX, das Sie bereits besitzen, und Engineering-Zeit. Ein sauberes C#-Add-in sind Stunden. Ein Ordner unsignierter Journals ohne Tests ist ein Inventar über mehrere Wochen. Fragen Sie Ihren Siemens-Partner nach den Lizenznummern für 2026.
Ist eine NXOpen-API-Migration besser als das Neuschreiben der Automatisierung?
Ja, wenn die Automatisierung noch zum Prozess passt. Neu kompilieren, veraltete Aufrufe ersetzen, einen Golden-Part-Diff hinzufügen. Ein Rewrite gewinnt, wenn das Journal einen toten Prozess kodiert oder der Quellcode fehlt. Wir würden von einem Rewrite als Standardreaktion auf einen Sechs-Monats-NX-Drop abraten.
Sollten wir monatliche NX-Updates bis zum nächsten Named Release aussetzen?
Nein. Monatliche Updates sind der Einlaufpfad von Siemens für Fixes. Lassen Sie sie auf einem Pilot-Seat. Machen Sie die NXOpen-API-Migration gegen die Named Family (jetzt 2606, als Nächstes 2612).
Nächster Schritt
Wenn Journals nur noch auf der NX-Installation laufen, die die IT ablösen will, buchen Sie einen 60-Minuten-Durchgang über Inventar, Sandbox und die DLL auf dem kritischen Pfad. inteliScience macht das als NX-Open-Engineering aus Rumänien, auf der EET-Uhr, nicht als Staffing-Pitch.
Verwandte Themen
Siemens-NX-Arbeit, die wir übernehmen, beginnt im Solutions-Hub. Daneben liegen der Python-Seat für Journals und Custom-NX-Open-Programming, wenn ein Ordner Skripte zu einem gepflegten Add-in werden muss, das Sie noch ausliefern können.