NXOpen Version-to-Version Quirks That Trip People Up

Community-sourced examples of things that broke or changed behavior across NX releases — the kind of detail that only shows up after someone's automation stopped working on upgrade day.

NX 11 → NX 12: utilities moved out of the UGII folder

Per discussion referenced from the Siemens PLM community ("NX Open v11 and v12 compatibility"), starting with NX 11 some command-line utilities that used to live in the UGII folder moved to a new folder called NXBIN. The specific example called out is run_journal — if a deployment script or wrapper still points at the old UGII location, it silently fails to find the utility after upgrading. This is an easy thing to miss because .NET NXOpen application code generally keeps working across this boundary (assuming no functions you use were removed) — it's specifically external tooling/scripts referencing NX's own folder layout that breaks.

NX 2212 → NX 2306: a journal broke because of a startup template file, not the API

A concrete, resolved case from Eng-Tips ("journal stopped working between 2212 and 2306"): a journal that ran fine in NX 2212 started erroring out in NX 2306, in every project, and the failure looked at first like an API-level regression. The actual root cause was that the journal depended on model-plain-1-inch-template.prt, which lived in the startup directory — but the real culprit turned out to be the ugs_model_templates.pax file in that same startup directory. The fix was overwriting the 2306 ugs_model_templates.pax with the working one carried over from the 2212 startup directory. The diagnostic path that got them there: check the NX log file after the failure for clues about where NX expected to find the template, then diff the startup/custom directory contents between the two versions.

Lesson generalized: when a journal/NXOpen tool breaks across an NX version bump with no code changes, don't assume it's an API-level breaking change first — check startup-directory config files (templates, .pax files, custom directory contents) that may not have been carried forward or regenerated correctly during the upgrade.

Python/NXOpen batch execution differences (NX 10 vs NX 12)

NX Journaling's article on NX10/NX12 Python NXOpen batch file differences documents that batch-mode invocation details for Python journals shifted between these releases — worth consulting directly if maintaining batch-processing scripts that need to run unattended across both versions (the exact invocation flags/paths differ enough to break existing batch wrappers).

General migration posture Siemens takes

Per community discussion, Siemens publishes API change/deprecation reports alongside each release along with tooling to assess how an incoming update affects existing customizations — but the practical, on-the-ground experience reported by developers is that most breakage they actually hit comes from environment/config drift (folder layout, startup templates, custom directory files) rather than pure API signature changes, which is why the two concrete cases above are both about installation layout, not code.

Practical takeaway

• Keep an explicit checklist when upgrading NX versions for automation: recheck UGII vs NXBIN paths in any wrapper scripts, and diff startup-directory contents (templates, .pax files) between old and new installs.
• Don't jump straight to "the API changed" when a journal breaks after an NX upgrade — check the NX log for the actual missing-file/path error first.
• Track Siemens' own per-release API change reports for genuine signature-level deprecations, but treat environment/config drift as the more common real-world cause of breakage.