NX Journal vs NXOpen: Die Kurzfassung
NX Journal vs NXOpen ist dieselbe API in zwei Paketen. Ein Journal kompiliert on the fly im Journal Editor. Ein signiertes Add-in ist das, was andere Arbeitsplätze ausführen. inteliScience schreibt beides für DACH-Teams auf Designcenter 2606. Aufzeichnen zum Lernen. Signieren zum Ausliefern.
| NX-Journal | Kompiliertes NXOpen | |
|---|---|---|
| Was es tatsächlich ist | NXOpen-Quellcode, eine Datei, von NX zur Laufzeit kompiliert | Dieselbe API, gebaut in Visual Studio / csc / python, dann signiert |
| Author-Lizenz zum Ausführen | Nein, für ein Journal im Editor | Unsigniert: zieht Author zur Laufzeit. Signiert: andere Arbeitsplätze laufen auf Gateway |
| Author-Lizenz zum Ausliefern | .NET-Journale: nein. Python-Distribution ist strenger (Python Author oder NX30106) | NX30104 (.NET) oder NX30106 (C++-, .NET-, Java-, Python-Toolkits) |
| Editor | Journal Editor. Eine Datei. Feste Assembly-Liste | Visual Studio, Unit-Tests, mehr als ein Projekt |
| Geschwindigkeit | JIT bei jedem Lauf. Fein für einen Batch von 50 Features. Schmerzhaft für einen nächtlichen Dump von 8.000 Teilen | Sie zahlen einmal beim Kompilieren |
| Benutzeroberfläche | Begrenzt. Block-Styler-Dialoge speichern erfordert das Feature Dialog Designer | Block Styler, WinForms, richtige Menüs |
| Wann wir es einsetzen | Aufzeichnen, lernen, einmaliges Cleanup, KI-generierter erster Entwurf | Alles, was eine andere Person 2027 noch ausführen wird |
Das Problem: Der Siemens-Thread hat recht, und ist unvollständig
Das erste Google-Ergebnis zu dieser Frage ist immer noch ein Siemens-Community-Thread: Ein Journal ist ein NXOpen-Programm. Der Satz ist wahr, und genau deshalb bleibt die Verwirrung.
Wenn es keinen Unterschied gibt, warum gibt es dann die Author-Lizenz. Warum gibt es SignDotNet.exe überhaupt. Warum schlägt eine unsignierte DLL auf dem Arbeitsplatz eines Kollegen mit einem Author-Lizenzfehler fehl und läuft auf Ihrem.
Weil das Packaging der Unterschied ist, nicht die API. NX Journal vs NXOpen ist eine Auslieferungsfrage. Die Community-Antwort endet beim Journal Editor. Sie sagt Ihnen nicht, wann Sie NX30104 oder NX30106 kaufen sollten, dass Python nicht dasselbe ist wie ein aufgezeichnetes VB-Journal, oder dass Knowledge Fusion eine dritte Schublade ist.
Wir raten davon ab, “wir haben Journale, wir brauchen kein NXOpen” als Strategie zu behandeln. Sie haben NXOpen bereits. Sie haben nur nicht entschieden, wer es ausführen darf.
Ein Journal ist NXOpen mit Stützrädern, und zwar absichtlich
Aufzeichnen (Developer tab > Journal group > Record) oder im Journal Editor tippen. NX kompiliert diese Datei, wenn Sie sie abspielen. Für einen normalen .NET-Journal-Lauf wird kein Author-Feature verbraucht. Genau das ist der Sinn des Journaling: Automatisierung ohne Entwickler-SKU.
Die Stützräder sind real.
- Eine Datei. Ein 2.000-Zeilen-Journal, das drei unten hineinkopierte Helfer aufruft, ist die Art, wie diese Dinge sterben.
- Eine feste Liste von Assemblies. Sie können nicht Ihr Firmen-NuGet hinzufügen und so tun, als wären Sie in Visual Studio.
- Der Editor ist ein Notepad mit Play-Button. Fein für ein Lochmuster. Nicht fein für irgendetwas mit Tests.
- Es ist langsamer. JIT bei jedem Abspielen. Bei einem einzelnen Teil merken Sie nichts. Bei einem Freigabe-Batch schon.
Sprachen: Der Recorder kann die NXOpen-Sprachen ausgeben, die NX unterstützt (.NET und je nach Release und Setup weitere). Ein aufgezeichnetes Journal ist ein miserables API-Tutorial und eine brauchbare Karte der Builder, die Sie gerade angeklickt haben. Wir behalten Aufzeichnungen als Gerüst und werfen den Großteil des generierten FindObject("NO NAME") Rauschens weg.
Python ist 2026 die Falle. Es fühlt sich an wie ein Journal, weil Sie eine .py neben das Teil legen. Die Lizenzbedingungen von Siemens sind deutlicher: Wer Python-NXOpen-Code schreiben und verteilen will, braucht das Feature NX Open Python Author oder das Toolkits-Bundle (NX30106, das das Python-Toolkit enthält). “Lief auf meinem Arbeitsplatz” ist nicht dasselbe wie “lizenziert für die Weitergabe an die Fertigung.” Fragen Sie Ihren Siemens-Partner, welcher Feature-Code auf Ihrem Angebot steht.
Kompiliertes NXOpen ist dieselbe API, mit Signatur
Kompiliert heißt eine DLL, EXE oder JAR, die NX als Anwendung lädt. Um sie zu bauen und zu signieren, brauchen Sie ein Author-Feature. Die Namen, die in Lizenzdateien auftauchen:
- NX30104 NX Open for .NET Author: C#-/VB.NET-Bibliotheken, Doku,
SignDotNet. - NX30106 NX Open Toolkits Author: C++, .NET, Java, Python in einem Bundle (Lizenzmodule
c_p_p_author,dotnet_author,java_author,ufunc_development). - NX Open Python Author, wenn Sie nur Python brauchen (separates Feature, fragen Sie nach dem Code auf Ihrem Angebot).
- Dialog Designer, wenn Sie Block-Styler-Dialoge speichern werden.
Eine separate NXOpen-Lizenz nur für die Laufzeit gibt es nicht. Eine signierte Anwendung läuft auf einem Gateway-Arbeitsplatz plus den Modullizenzen, die der Code tatsächlich nutzt. Eine unsignierte Anwendung zieht sich, falls Author auf dieser Maschine verfügbar ist, für den Lauf die Author-Lizenz. Das ist eine teure Art, ein Werkzeug zu teilen. Tun Sie das nicht absichtlich.
.NET zu signieren ist mechanisch: Betten Sie UGOPEN\NXSigningResource.res als Win32-Ressource ein und rufen Sie dann SignDotNet.exe auf der Ausgabe auf. Lassen Sie die Ressource weg, verweigert NX die Assembly mit einem Signaturfehler, auch wenn Sie an die Exe gedacht haben. Aktuelle Releases dokumentieren einen Build-Pfad mit .NET 8 / Visual Studio 2022; prüfen Sie im NX Open Programmer’s Guide das exakte Release, gegen das Sie bauen. Designcenter 2606 (Juni 2026) hat daran nichts geändert. Designcenter erscheint im Juni und im Dezember. Planen Sie die nächste Compiler-Matrix vor dem Dezember-Drop, nicht danach.
// Compiled NXOpen, C#, NX 2606. This is not a journal.
// Sign with SignDotNet.exe after build or only Author seats will run it.
using NXOpen;
public class ListSolidBodies
{
public static int Main(string[] args)
{
Session session = Session.GetSession();
Part work = session.Parts.Work;
ListingWindow lw = session.ListingWindow;
lw.Open();
foreach (Body body in work.Bodies)
{
if (!body.IsSolidBody) continue;
lw.WriteLine(body.JournalIdentifier);
}
return 0;
}
public static int GetUnloadOption(string dummy) =>
(int)Session.LibraryUnloadOption.Immediately;
}Dieselbe Schleife wie ein Journal, minus Editor, plus Signatur. Das ist das Upgrade.
Wann wir was wählen
Unsere klare Empfehlung: Journal, bis die zweite Person es braucht. Dann kompilieren.
Ein aufgezeichnetes Journal ist das richtige Artefakt, wenn Sie einen Builder kennenlernen, wenn Claude Code gerade einen ersten Entwurf ausgegeben hat oder wenn ein Konstrukteur es zweimal abspielt und dann löscht. Kompiliertes NXOpen ist das richtige Artefakt, wenn das CAM-Team es nach Ihrem Weggang ausführen wird, wenn es in einem Menü sitzen muss, wenn es zwei andere Assemblies aufrufen muss, wenn es den NX-2612-Unload überleben muss.
SNAP und GRIP gehören nicht in diesen Vergleich. GRIP ist eingefroren. SNAP ist ein lizenziertes Overlay. Wenn Ihre Frage Regeln betrifft, die innerhalb des Teils leben, dann ist das Knowledge Fusion: Update-Mechanismus, nicht Packaging. Anderer Artikel.
Die Sprachwahl (Python vs C#) ist noch einmal eine andere Achse. Kurzfassung: Python-Journale sind schnell geschrieben und umständlich zu verteilen. C# ist das, was wir für Add-ins in der Fertigung signieren.
Die Regel von inteliScience für NX-2606-Projekte, aus der DACH-NX-Open-Arbeit, die wir tatsächlich ausliefern: Was nach zwei Wochen noch im Journal Editor steckt, ist bereits ein Wartungsproblem. Entweder wegwerfen oder auf ein Menü legen.
Bereit zur Umsetzung? Wie wir ein KI-entworfenes Journal zu etwas machen, das kompiliert, steht in unserem Leitfaden zur NX Open KI-Code-Generierung.
Worauf Sie bei der Auswahl achten sollten
- Wer führt es nächsten Monat aus? Nur Sie: Journal. Jemand anderes: signiertes NXOpen.
- Haben Sie Author auf der Build-Maschine? Prüfen Sie die Lizenzdatei auf
dotnet_author(NX30104 oder NX30106). Falls nicht, können Sie weiterhin aufzeichnen. Eine signierte DLL ausliefern können Sie nicht. - Python oder .NET? Aufgezeichnete VB-/C#-Journale sind der lizenzarme Weg. Python-Distribution verlangt das Python-Author-Feature oder NX30106. Gehen Sie nicht davon aus, dass beides gleich ist.
- Eine Datei oder eine Solution? An dem Tag, an dem Sie eine zweite Datei brauchen, sind Sie dem Journal Editor entwachsen.
- Übersteht es 2612? Journale verrotten bei Upgrades, weil Aufzeichnungen Objektnamen hart kodieren. Kompilierter Code mit Tests schlägt wenigstens in der CI fehl.
Beratung zu Siemens NX bei inteliScience heißt: Wir entscheiden das Packaging in Woche eins, nicht erst, wenn das Journal des Praktikanten auf jedem Abteilungslaufwerk liegt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem NX-Journal und NXOpen?
Ein Journal ist NXOpen-Quellcode, den NX beim Abspielen kompiliert. NXOpen ist die API darunter, in jeder Verpackung: Journal, signierte DLL, Java-JAR, Python. NX Journal vs NXOpen heißt daher “unsigniertes Ein-Datei-Skript” vs “Anwendung, die Sie ausliefern können.” Gleiche Aufrufe, andere Lizenz und anderer Editor.
Brauche ich für Journale eine NX Open Author-Lizenz?
Nicht, um ein .NET-Journal auf Ihrem eigenen Arbeitsplatz aufzuzeichnen und abzuspielen. Sie brauchen Author (NX30104 oder NX30106), um kompilierte Anwendungen zu signieren, damit andere Arbeitsplätze sie ausführen können, ohne Author zu ziehen. Python-Distribution ist die Ausnahme: Budgetieren Sie das Python-Author-Feature oder NX30106, wenn Sie Dateien vom Typ .py weitergeben werden.
NX Journal vs NXOpen: Was ist schneller?
Die kompilierte DLL, einmalig. Ein Journal wird bei jedem Abspielen JIT-kompiliert. Bei einem zehnzeiligen Cleanup werden Sie es nicht messen. Bei einem nächtlichen Lauf über eine ganze Produktlinie schon. Geschwindigkeit ist nicht der Grund, warum wir kompilieren. Teilen ist es.
Was kostet NX Open Author?
Siemens veröffentlicht keine Listenpreise für NX30104 / NX30106 auf der Marketing-Site. Es sind Add-ons, nicht in den üblichen Mach-Bundles enthalten. Rechnen Sie mit einem Author-Arbeitsplatz auf der Build-Maschine, nicht mit einem pro Nutzer. Signierte Apps laufen dann auf Gateway plus Modullizenzen. Fragen Sie Ihren Siemens-Partner nach dem Angebot für 2026, nicht einen Blog.
Kann ich in einem Journal anfangen und später kompilieren?
Ja, und genau diesen Weg gehen wir. Aufzeichnen, das FindObject Rauschen entfernen, nach Visual Studio umziehen, Ressource einbetten: NXSigningResource.res, signieren. Die API ändert sich nicht. Die Projektdatei schon. Warten Sie nicht, bis das Journal 3.000 Zeilen hat.
Nächster Schritt
Unsicher, ob Ihre Automatisierung noch ein Journal ist oder schon ein Add-in, das Sie sich nicht zu signieren trauen? Buchen Sie ein kostenloses 60-minütiges Strategiegespräch. Strategiegespräch zu NX Journal vs NXOpen buchen
Verwandte Themen
- NXOpen Schulung mit Python
- NXOpen lernen: ein Lernpfad für NX-Ingenieure
- NX Open Code-Generierung mit KI
- NXOpen vs Knowledge Fusion
- NXOpen Python vs C#