Siemens NX Automation: The Short Version
Siemens NX automation means replacing repeated manual steps in NX, such as drawing creation, PMI placement, standard-part insertion and model checks, with code or rules that run the same way every time. inteliScience builds this on NX Open for engineering teams in DACH and Europe. Typical first project: variant drawings that took hours each are generated in minutes.
| Manual NX workflow | Automated with NX Open | |
|---|---|---|
| Variant drawing | 2 to 3 hours per member of a part family | Minutes per family, template-driven, checked in Teamcenter |
| PMI on changed geometry | Re-placed and re-numbered by hand after every change | Rule-based placement and numbering that re-orders itself |
| Company design rules | Found at release or in manufacturing | Checked at the designer’s desk while modelling |
| Who does the work | The engineer, again | A tested tool, once; the engineer reviews |
The Problem: NX Teams Automate the Wrong Thing First
Most Siemens NX automation efforts start with whatever a motivated engineer recorded in a journal last week, and they stall six months later when that engineer changes jobs or NX changes version. The projects that survive start from a different question: which repeated task costs the department the most hours per month, and can its rules be written down?
The hours are real. In the departments we assess, repetitive modelling, drafting revisions and documentation regularly consume a third of an engineer’s week. For engineer-to-order manufacturers we have seen drawing work alone take up to half of engineering time, because every configured order needs a drawing set nobody wants to make.
Our clear recommendation before any code is written: list the ten most repeated tasks, put a monthly hour count next to each, and mark the ones whose rules a senior designer can dictate in one sitting. Those are your candidates. Everything that needs judgement stays with the engineer, at least in phase one.
What to Automate First: Six Tasks That Pay Back Within a Quarter
The tasks below have paid back within one quarter in our projects, in this order. Each one has clear rules, high repetition, and an output that is easy to verify, which is exactly the profile a first Siemens NX automation project needs.
- Drawings for part families. From one drawing template the tool creates the drawing for every member of a family and files it in Teamcenter. We have built this twice, independently, for different clients; both times it was the fastest win on the list.
- PMI placement and numbering. Annotations placed and numbered from the X, Y and Z coordinates of a coordinate system, with an algorithm that re-orders and re-numbers when the design changes. Manual PMI maintenance breaks with every revision; a rule-based structure corrects itself.
- Company design-rule checks at the desk. A check suite that flags violations of internal guidelines while the designer is still modelling, instead of at release. The cost of a rule violation grows with every gate it passes.
- Standard-part placement and clean-up routines. Reference sets, layer discipline, attribute completeness, suppressed-feature hygiene, applied across an assembly in one run.
- Variant generation from expressions. Transformer and machinery engineering live on families of similar parts; expressions plus NX Open generate the variant, its drawing and its BOM instead of an engineer editing each by hand.
- Batch conversion and export. STEP files aligned to a defined coordinate system and exported per view as STEP, PRT and JPEG, driven by a control file, with NX running headless behind a web service.
Where do we advise against starting? Anything that touches design intent: choosing a datum strategy for a new part class, deciding a tolerance, or reworking a legacy model whose history nobody understands. Those are review problems, not automation problems, and forcing them into a script produces a tool engineers distrust.
Which NX Automation Tool for Which Job
NX ships more automation layers than most teams use, and picking the wrong layer is the second most common reason a project stalls. The table is our working map as of Designcenter 2606, the June 2026 release in which Siemens renamed NX to Designcenter.
| Layer | Best for | Who maintains it | Upgrade risk |
|---|---|---|---|
| Journals (recorded NX sessions, Python, C#, VB, Java) | Discovering which API calls a workflow needs; one-off batch jobs | The engineer who recorded it | High: recorded code hard-wires object names and dialog states |
| NX Open (the official API, .NET, Python, C++, Java) | Anything you ship to more than one engineer: custom commands, drawing and PMI generation, Teamcenter integration | A developer, with tests | Medium: API is versioned and documented; deprecations are announced |
| Expressions, part families, Product Template Studio | Configurable products, sales-driven variants, codeless templates with a simple UI | Senior designers | Low: lives in the part |
| Knowledge Fusion | Rule-driven geometry where the rules must live inside the model and react to changes | KF specialists, rare on the market | Medium; skills are the risk, not the API |
| Algorithmic Modeling (visual logic, Designcenter 2606) | Node-based rules for geometry, measurement and annotation behaviour without programming; reusable via the Reuse Library | Power users | Low to medium; new, still expanding |
| AI agents over MCP | Conversational access to read the part and, gated, run typed NX Open tools | Developers plus an AI layer | Depends entirely on the gate you build |
Three positions we hold after enough projects to be sure.
Journals are for learning, not for shipping. Record the journal, read what NX did, then write the real tool in NX Open with named inputs and error handling. Journaling is included in every NX Mach series licence, which is why it is everyone’s first step and nobody’s last.
NX Open beats Knowledge Fusion for almost every team that does not already run KF. The API is documented, versioned and hireable for; KF expertise is scarce and getting scarcer. We wrote up the trade-off in detail in our comparison of NXOpen and Knowledge Fusion.
Algorithmic Modeling is worth a pilot now, not a rollout. Siemens introduced it for additive manufacturing bases in 2606 with a Logic Editor and Reuse Library sharing, and the direction is right: rules as nodes, not as scripts. Give it one power user and one bounded use case before betting a process on it.
A First NX Open Tool: From Journal to Batch Job
The example below is the shape of a first shipped tool: a Python NX Open script that walks an assembly, sets a standard attribute on every component, and reports what it changed. Recorded from a journal, then rewritten with explicit inputs, a check and a log. It runs from the NX Python interpreter or headless through the journal runner.
# set_attribute_batch.py — NX Open (Python), tested on NX 2412 and Designcenter 2606
# Walks the assembly tree of the work part and sets a company attribute on every component.
import NXOpen
import NXOpen.Assemblies
def set_attribute_on_components(attr_name: str, attr_value: str) -> int:
session = NXOpen.Session.GetSession()
work = session.Parts.Work
if work.ComponentAssembly.RootComponent is None:
raise RuntimeError("work part is not an assembly")
changed = 0
seen = set()
stack = [work.ComponentAssembly.RootComponent]
while stack:
comp = stack.pop()
part = comp.Prototype.OwningPart
if part.FullPath not in seen:
seen.add(part.FullPath)
current = part.GetUserAttributeAsString(attr_name, NXOpen.NXObject.AttributeType.String, -1) if part.HasUserAttribute(attr_name, NXOpen.NXObject.AttributeType.String, -1) else None
if current != attr_value:
part.SetUserAttribute(attr_name, -1, attr_value, NXOpen.Update.Option.Now)
changed += 1
session.ListingWindow.Open()
session.ListingWindow.WriteLine(f"{part.Leaf}: {attr_name} = {attr_value}")
stack.extend(comp.GetChildren())
return changed
if __name__ == "__main__":
n = set_attribute_on_components("ISC_RELEASE_STATE", "IN_WORK")
NXOpen.Session.GetSession().ListingWindow.WriteLine(f"components updated: {n}")Run it headless against a folder of assemblies without opening the NX user interface, which is how batch jobs belong in production:
# Windows, NX/Designcenter install: run a journal in batch mode for every assembly in a folder
for %f in (C:\work\assemblies\*_asm.prt) do (
"C:\Program Files\Siemens\NX2606\NXBIN\run_journal.exe" C:\tools\set_attribute_batch.py -args "%f"
)Two habits separate this from the journal it started as. The tool takes its inputs as parameters and refuses to run on a part that is not an assembly. And it writes what it changed to the listing window, so the engineer who runs it can check the result instead of trusting it.
This runs as a POC. What’s missing for production: a deployment your CAD admin controls, tests against the NX versions you actually run, error handling for locked and checked-out parts, Teamcenter awareness, and an owner after the author moves on. We close the gap from “runs on my machine” to “runs in the engineering department” — see how we build production NX workflow automation.
Making NX Automation Survive the Next Upgrade
An NX Open tool written in 2024 will meet Designcenter 2606 this year, and the question is whether anyone tested it. Siemens versions the NX Open API and documents deprecations, so the breakage is predictable; what is usually missing is a test set and an owner.
What we put in place on every project, and what we recommend even for tools we did not write:
- A regression set of five to ten real parts per tool, with expected outputs, run before every NX upgrade.
- Parameters and units in every signature. Never screen picks, never hard-coded object names from a journal.
- One deployment path. A custom command your CAD administrator installs and updates, not a script emailed around.
- Named ownership. A tool without an owner is technical debt with a start date.
If you have a shelf of journals and Visual Basic macros that nobody dares to touch, the honest fix is a modernisation pass rather than a rewrite from zero; our NX legacy code modernisation service starts by inventorying what still runs.
Where AI Fits in Siemens NX Automation Now
AI changes two things in 2026 and leaves the deterministic core alone. First, code generation: a frontier model such as claude-sonnet-5 writes NX Open scaffolding reliably and invents API calls that do not exist, which is why grounding it on the NX Open reference and verifying every journal headless roughly halves the time to a reviewed tool. We measured that in our NX Open code generation tests. Second, agents: over the Model Context Protocol an assistant can read the open part and, after a preview and confirmation, call the same typed NX Open tools described above.
Siemens’ own Designcenter Copilot, shipped with 2606, answers from documentation and the current task. It does not run NX Open for you, and as of September 2026 there is no official Siemens MCP server for NX modelling. For automation that means the AI layer is something you add to your tool set, not something that replaces it.
Our position: keep the rules deterministic, let AI generate and explain code, and let agents call tools only through a gate. Teams that let a model write and run journals directly have, without exception, rolled it back.
Cost and Timeline for a First Project
A first Siemens NX automation project is smaller than most teams expect, because the first task is chosen for repetition and clear rules. Our free NX automation assessment reviews your recurring workflows and ranks them by hours saved. An NX Open proof of concept, one concrete use case built and tested on your own data inside your NX environment, starts at €3,000. A fixed-price proof-of-value sprint on your own NX Open libraries starts at €12,900. Full automation projects, for instance a drawing generator for a product line with Teamcenter filing, run from the mid five figures and are scoped after the proof of concept, not before.
Timeline: two weeks for a proof of concept on one task, six to ten weeks for a production tool with tests, deployment and hand-over. Payback for the drawing and PMI use cases above has landed within a quarter in every project where the task list was built from measured hours.
Frequently Asked Questions
What is Siemens NX automation?
Siemens NX automation is the use of NX’s programming and rule layers, mainly NX Open, journals, expressions and Product Template Studio, to execute repeated modelling, drafting, checking and documentation tasks without manual clicks. The task runs the same way every time, and the engineer reviews the output instead of producing it.
What should we automate first in NX?
Start with the task that costs the most hours per month and whose rules a senior designer can dictate in one sitting. In our projects that is almost always drawing generation for part families, followed by PMI placement and numbering, then company design-rule checks at the designer’s desk.
NX journals vs NX Open: what is the difference?
A journal is a recording of an interactive NX session as code; NX Open is the official, versioned API the journal calls into. Journals are ideal for discovering which calls a workflow needs. Tools that more than one engineer will run should be rewritten in NX Open with parameters, error handling and tests.
How much does Siemens NX automation cost?
An assessment of your recurring workflows is free with us. A proof of concept for one use case starts at €3,000, a proof-of-value sprint on your own libraries at €12,900, and full production tools such as a drawing generator with Teamcenter filing run from the mid five figures. The first task typically pays back within one quarter.
Should we use Python or C# for NX Open?
Python is the fastest way to start because NX ships an interpreter and journals record to it; C# and .NET are the better choice for custom commands your CAD administrator deploys to a whole department. We compared the two in detail in our NXOpen Python vs C# guide; most of our production tools are .NET, most of our prototypes are Python.
Next Step
Book a free NX automation assessment: we rank your recurring workflows by hours saved
