NX Journal vs NXOpen: The Short Version
NX Journal vs NXOpen is the same API in two packages. A journal compiles on the fly in the Journal Editor. A signed add-in is what other seats run. inteliScience writes both for DACH teams on Designcenter 2606. Record to learn. Sign to ship.
| NX journal | Compiled NXOpen | |
|---|---|---|
| What it actually is | NXOpen source, one file, compiled at run time by NX | The same API, built in Visual Studio / csc / python, then signed |
| Author license to run | No, for a journal in the editor | Unsigned: pulls Author at runtime. Signed: other seats run on Gateway |
| Author license to ship | .NET journals: no. Python distribution is stricter (Python Author or NX30106) | NX30104 (.NET) or NX30106 (C++, .NET, Java, Python toolkits) |
| Editor | Journal Editor. One file. Fixed assembly list | Visual Studio, unit tests, more than one project |
| Speed | JIT each run. Fine for a batch of 50 features. Painful for a nightly 8,000-part dump | You pay once at compile |
| UI | Limited. Saving Block Styler dialogs needs the Dialog Designer feature | Block Styler, WinForms, proper menus |
| When we use it | Record, learn, one-off cleanup, AI-generated first draft | Anything another person will still run in 2027 |
The Problem: The Siemens Thread Is Right, and Incomplete
The first Google result for this question is still a Siemens Community thread: a journal is an NXOpen program. That sentence is true and it is why people stay confused.
If there is no difference, why does the Author license exist. Why does SignDotNet.exe exist. Why does an unsigned DLL fail with an Author-license error on a colleague’s seat and run on yours.
Because packaging is the difference, not the API. NX Journal vs NXOpen is a shipping question. The Community answer stops at the Journal Editor. It does not tell you when to buy NX30104 or NX30106, or that Python is not the same deal as a recorded VB journal, or that Knowledge Fusion is a third box.
We would advise against treating “we have journals, we do not need NXOpen” as a strategy. You already have NXOpen. You have not decided who is allowed to run it.
A journal is NXOpen with training wheels, on purpose
Record (Developer tab > Journal group > Record), or type in the Journal Editor. NX compiles that file when you play it. No Author feature is consumed for a normal .NET journal run. That is the whole point of journaling: automation without a developer SKU.
The training wheels are real.
- One file. A 2,000-line journal that calls three helpers you pasted at the bottom is how these things die.
- A fixed list of assemblies. You cannot add your company NuGet and pretend you are in Visual Studio.
- The editor is a notepad with a Play button. Fine for a hole pattern. Not fine for anything with tests.
- It is slower. JIT every play. You will not notice on a single part. You will notice on a release batch.
Languages: the recorder can emit the NXOpen languages NX supports (.NET, and depending on release and setup, others). A recorded journal is a terrible API tutorial and a decent map of which builders you just clicked. We keep recordings as scaffolding, then throw most of the generated FindObject("NO NAME") noise away.
Python is the trap in 2026. It feels like a journal because you drop a .py next to the part. Siemens’ license terms are blunter: to author and distribute Python NXOpen code you want the NX Open Python Author feature or the Toolkits bundle (NX30106, which includes the Python toolkit). “It ran on my seat” is not the same as “licensed to hand to the shop.” Ask your Siemens partner which feature code sits on your quote.
Compiled NXOpen is the same API, with a signature
Compiled means a DLL, EXE, or JAR that NX loads as an application. To build and sign it you need an Author feature. The names that show up in license files:
- NX30104 NX Open for .NET Author: C# / VB.NET libraries, docs,
SignDotNet. - NX30106 NX Open Toolkits Author: C++, .NET, Java, Python in one bundle (license modules
c_p_p_author,dotnet_author,java_author,ufunc_development). - NX Open Python Author, if you only need Python (separate feature, ask for the code on your quote).
- Dialog Designer, if you will save Block Styler dialogs.
There is no separate NXOpen runtime license. A signed application runs on a Gateway seat plus whatever module licenses the code actually exercises. An unsigned application, if Author is available on that machine, will grab Author for the run. That is an expensive way to share a tool. Do not do it on purpose.
Signing .NET is mechanical: embed UGOPEN\NXSigningResource.res as a Win32 resource, then call SignDotNet.exe on the output. Skip the resource and NX refuses the assembly with a signing error, even if you remembered the exe. Current releases document a .NET 8 / Visual Studio 2022 build path; check the NX Open Programmer’s Guide for the exact release you build against. Designcenter 2606 (June 2026) did not change that story. Designcenter ships in June and December. Plan for the next compiler matrix before the December drop, not after.
// 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;
}The same loop as a journal, minus the editor, plus a signature. That is the upgrade.
When we pick which
Our clear recommendation: journal until the second person needs it. Then compile.
A recorded journal is the right artifact when you are learning a builder, when Claude Code just emitted a first draft, or when one engineer will play it twice and delete it. Compiled NXOpen is the right artifact when the CAM team will run it after you leave, when it must sit on a menu, when it must call two other assemblies, when it has to survive the NX 2612 unload.
SNAP and GRIP are not this comparison. GRIP is frozen. SNAP is a licensed overlay. If your question is rules that live inside the part, that is Knowledge Fusion: update mechanism, not packaging. Different article.
Language choice (Python vs C#) is another axis again. Short version: Python journals are fast to author and awkward to distribute. C# is what we sign for shop-floor add-ins.
inteliScience’s rule on NX 2606 projects, from the DACH NX Open work we actually ship: if it is still in the Journal Editor after two weeks, it is already a maintenance problem. Either throw it away or put it on a menu.
Ready to implement? How we take an AI-drafted journal to something that compiles is in our NX Open AI code generation guide.
What to look for when choosing
- Who runs it next month? Only you: journal. Anyone else: signed NXOpen.
- Do you have Author on the build machine? Check the license file for
dotnet_author(NX30104 or NX30106). If not, you can still record. You cannot ship a signed DLL. - Python or .NET? Recorded VB/C# journals are the license-light path. Python distribution wants the Python Author feature or NX30106. Do not assume they are equal.
- One file or a solution? The day you need a second file, you have outgrown the Journal Editor.
- Will it meet 2612? Journals bit-rot on upgrades because recordings hard-code object names. Compiled code with tests at least fails in CI.
Siemens NX consulting at inteliScience means we decide packaging in week one, not after the intern’s journal is in every department share.
Frequently Asked Questions
What is the difference between an NX journal and NXOpen?
A journal is NXOpen source that NX compiles when you play it. NXOpen is the API underneath, in any packaging: journal, signed DLL, Java JAR, Python. NX Journal vs NXOpen is therefore “unsigned one-file script” vs “application you can ship.” Same calls, different license and editor.
Do I need an NX Open Author license for journals?
Not to record and play a .NET journal on your own seat. You need Author (NX30104 or NX30106) to sign compiled applications so other seats can run them without pulling Author. Python distribution is the exception: budget the Python Author feature or NX30106 if you will hand .py files around.
NX Journal vs NXOpen: which is faster?
The compiled DLL, once. A journal JIT-compiles every play. For a ten-line cleanup you will not measure it. For a nightly run across a product line you will. Speed is not why we compile. Sharing is.
How much does NX Open Author cost?
Siemens does not print NX30104 / NX30106 list prices on the marketing site. They are add-ons, not in the common Mach bundles. Count one Author seat on the build machine, not one per user. Signed apps then run on Gateway plus module licenses. Ask your Siemens partner for the 2026 quote, not a blog.
Can I start in a journal and compile later?
Yes, and that is the path we use. Record, strip the FindObject noise, move into Visual Studio, embed NXSigningResource.res, sign. The API does not change. The project file does. Do not wait until the journal is 3,000 lines.
Next Step
Unsure whether your automation is still a journal, or already an add-in you are afraid to sign? Book a free 60-minute strategy call. Book a strategy call about NX Journal vs NXOpen
Related Topics
- NXOpen training with Python
- Learn NXOpen: a learning path for NX engineers
- NX Open code generation with AI
- NXOpen vs Knowledge Fusion
- NXOpen Python vs C#