NX Open for Machine Builders: What It Actually Does
NX Open for machine builders means driving Siemens NX from code — variants, drawings, bills of material, quotation checks — instead of repeating them by hand. inteliScience modernises the automation you already have and builds what is missing, on-premise. The result our customers care about is simple: more orders engineered per engineer, without new headcount.
| Where the hours go today | With NX Open automation | |
|---|---|---|
| A customer-specific variant | Copy the last one, edit everything | Driven from a parameter set |
| Quoting a new enquiry | Senior engineer reads the geometry | Pre-checked, flagged, then reviewed |
| The 2013 automation scripts | One person understands them | Rewritten, tested, in source control |
The Problem: The People Are Not Coming
German mechanical and plant engineering employs more than 1.2 million people and turns over around €245 billion — the country’s largest industrial employer. It is also running out of engineers, and the pipeline behind them has collapsed rather than tightened.
First-year enrolment in mechanical and process engineering programmes has fallen by roughly 16,000 over the past decade, a drop of about 45%. VDMA’s survey of more than 300 member companies found only two thirds able to fill most of their skilled vacancies, and nearly half reporting outright lost sales as a consequence — 27% losing up to 5% of revenue, another 20% losing more than that. Every third company can fill at most half of its apprenticeship places.
Read that as a planning input rather than a lament. The number of engineering hours available to your company over the next five years is roughly fixed, and probably shrinking. Order intake is not. So the only variable left is how many of those hours go into work that a machine could have done.
In a typical special-machinery or plant-engineering business, that share is large. Rebuilding a near-identical variant of a module you have shipped forty times. Redrawing the drawing set. Rebuilding the parts list. Opening a customer’s STEP file and manually working out whether it is manufacturable before quoting. None of it is design. All of it is done by designers.
What NX Open Is, and Why Yours Is Probably Rusting
NX Open is the programming interface to Siemens NX — the platform Siemens rebranded to Designcenter with the June 2026 release, generally available 23 June 2026. The rebrand changed the name on the splash screen, not the API. Bindings cover C++, C# and VB.NET, Java and Python; everything you can do interactively you can do from code, which is the foundation under every one of the Siemens NX capabilities we deliver.
Most machine builders are not starting from zero. They have automation. That is usually the problem.
The typical estate we walk into is a folder of journals recorded in 2011, a VB.NET add-in written by an engineer who left in 2018, and a Python script that only runs if you launch NX from a specific shortcut. It works, sort of, on the version of NX nobody wants to upgrade from. There is no source control, no tests, and one person who is nervous about holidays.
The fix is not glamorous and it is not a rewrite from scratch. It is: get it into Git, get the deprecated UF_* calls off the critical path, get a test that runs the automation against a reference part and compares the output, and get a second person able to read it. Then upgrade NX. We do this often enough that it has its own name in our catalogue — legacy NX Open code modernisation — and it is almost always the highest-return first project, because it unblocks the platform upgrade that everything else is waiting on.
Four platform capabilities are worth knowing before you scope anything:
Journaling. NX records an interactive session as source code. This is how a designer who does not program produces the first draft of an automation, and how we capture what your process actually is rather than what the manual claims.
Expressions. Named parameters that drive geometry, readable and writable from code. If your modules are parametric, a variant generator is a small program. If they are not, the parametrisation is the project and the code is the easy part.
Knowledge Fusion. Declarative rules that live in the part and re-evaluate when inputs change. This is where a senior designer’s judgement gets encoded before they retire — and in an industry with your demographics, that is not a theoretical concern.
Block UI Styler. Native NX dialogs. An automation with a dialog becomes a department tool; one without becomes a script two people know about.
Pre-Checking Geometry Before You Quote
The single most annoying hour in a machine builder’s week is a senior engineer opening a customer’s imported model to judge whether it can be made and what it will cost.
Much of that judgement is countable. Number of bores, their diameters, wall thickness, whether tolerances are plausible, how many separate setups the part implies. NX Open can count it in seconds and hand the engineer a summary instead of a blank model.
# NX Open (Python) - quick manufacturability scan of an imported customer part.
# Run with the imported part open as work part (Developer tab > Journal > Play).
import NXOpen
import NXOpen.UF
MIN_BORE_MM = 3.0 # below this, our shop needs a special tool
DEEP_RATIO = 5.0 # depth/diameter above this needs gun drilling
def bore_report(part, uf):
holes, flags = [], []
for body in part.Bodies:
for face in body.GetFaces():
if face.SolidFaceType != NXOpen.Face.FaceType.Cylindrical:
continue
# UF_MODL_ask_face_data: type, point, direction, box, radius, rad_data, norm
data = uf.Modl.AskFaceData(face.Tag)
diameter = data[4] * 2.0
holes.append(diameter)
if diameter < MIN_BORE_MM:
flags.append("bore %.2f mm below shop minimum" % diameter)
return holes, flags
def main():
session = NXOpen.Session.GetSession()
uf = NXOpen.UF.UFSession.GetUFSession()
part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
holes, flags = bore_report(part, uf)
bodies = len(list(part.Bodies))
lw.WriteLine("bodies: %d cylindrical faces: %d" % (bodies, len(holes)))
if holes:
lw.WriteLine("bore range: %.2f - %.2f mm" % (min(holes), max(holes)))
if bodies > 1:
flags.append("multi-body part - confirm it is one component, not an assembly")
for f in flags:
lw.WriteLine("FLAG: %s" % f)
if not flags:
lw.WriteLine("no automatic flags - proceed to costing")
if __name__ == "__main__":
main()This is deliberately not clever. It does not attempt to cost the part or decide anything. It converts twenty minutes of clicking and measuring into a printed summary with a handful of flags, and it runs in batch across every part in an enquiry. The engineer still makes the call — faster, and with the awkward features already surfaced. Extended with your own shop rules and the historical costing data you already hold, it becomes the AI DFM and quotation check we deploy for machine builders.
Quoting slower than your competitors and blaming sales? It is usually engineering throughput, and it is measurable in a morning. We start by counting where the quotation hours actually go — not by proposing software.
Simplification, Because Nobody Sends You a Clean Model
Two recurring jobs in this industry deserve automation more than they get it.
The first is preparing models for simulation. A full assembly with every fastener, thread and fillet is unusable for FEA or CFD in reasonable time, so someone defeatures it by hand — and does it again after the next design change. NX Open can strip features by rule: suppress fasteners below a size, remove fillets under a radius threshold, delete internal detail that does not affect the result. It is repeatable, which manual defeaturing is not.
The second is what you send to customers and suppliers. You want to hand over geometry that is sufficient to integrate your machine, without shipping your internal design. Rule-driven simplification produces that envelope model automatically, at the right level of detail, every time. Both cases sit in the same toolkit we package as automated CAD model simplification and defeaturing.
And then there is the archive. Most machine builders have decades of drawings for machines still in the field, held as scans and PDFs, and every spare-parts enquiry is a search. Vision models can extract part numbers, materials, dimensions and referenced standards from those drawings; NX Open reconciles the result against live CAD and PLM data and flags where they disagree. What you end up with is a searchable installed base, which is the precondition for a service business that does not depend on two long-serving employees.
AI in the NX Workflow
The June 2026 Designcenter release added Designcenter Copilot — a natural-language assistant grounded in Siemens documentation, best practice and what the user is currently doing. It answers platform questions well and knows nothing about your machines.
Where AI moves the needle for a machine builder is one step out from the CAD window: reading unstructured input. Customer enquiries as PDFs, specifications with embedded requirement tables, legacy drawings, supplier documentation. A retrieval system over your own history — past quotations, standard modules, previous deviations — turns “has anyone built something like this before” from a corridor conversation into a query with citations.
We deploy these on-premise by default. Not because cloud AI is inherently unsafe, but because your quotation history and customer drawings are the most commercially sensitive data you own, and the internal debate about sending them anywhere costs more time than the deployment. Open-weight models on a single GPU node handle retrieval and drafting perfectly well.
Code generation is the exception where frontier models genuinely win. claude-opus-5-5 writes a solid first draft of an NX Open script far faster than a person, and we use it constantly. It also invents API calls with total confidence — methods that do not exist, arguments transposed, classes from the wrong namespace. Generated code goes through an import check and a run against a reference part before anyone reviews the logic. With that loop it is a real accelerator; without it, it is a way to move debugging time from Tuesday to Thursday.
Where to Start
| Weeks | Focus | Result |
|---|---|---|
| 1–2 | Inventory the existing automation; journal the three most repeated workflows | An honest map, and hours attached to each workflow |
| 3–5 | Modernise the critical legacy script: source control, tests, deprecated calls removed | The NX upgrade stops being blocked |
| 6–10 | Build the highest-value new automation with a Block UI Styler dialog and batch mode | One tool in the ribbon, one nightly job |
| 11–13 | Add the quotation pre-check, or extend the variant generator to a second module | A second measurable win, chosen by the users |
Fix the legacy estate before adding to it. Building new automation on top of scripts nobody can maintain produces a larger thing nobody can maintain, and it is the most common way these programmes quietly stop.
Nobody in-house to take over that modernisation? Then an NXOpen developer on demand from our team in Cluj-Napoca takes it on: Python, C# or C++ for your NX version, at a day rate or starting with an NX Sprint on one use case.
One more piece of advice we give every machine builder: do not aim for the generator that handles every exception. Cover the cases you ship most often and let the rest route to an engineer with a clear reason for the rejection. Automation that refuses cleanly gets trusted. Automation that silently produces something subtly wrong gets switched off after one bad delivery, and it does not get switched back on.
Frequently Asked Questions
How much does NX Open for machine builders cost to implement?
Modernising an existing legacy script — source control, deprecated API calls — commonly lands between €6,000 and €15,000. A new automation with a dialog and batch capability is more often €12,000 to €30,000, driven mainly by how parametric your models already are. We scope after the journaling exercise, because guessing from a requirements document is how both sides end up unhappy.
Our scripts still run. Why modernise them?
Because they are the reason you are still on an old NX version, and because the knowledge sits with one person. The trigger is usually an upgrade that cannot happen or a leaver who cannot be replaced. Doing it before either event costs a fraction of doing it during.
NX Open or Knowledge Fusion for our design rules?
Knowledge Fusion for constraints that must travel with the part and re-evaluate when something changes — clearances, standard dimensions, configuration rules. NX Open for procedural work: batch runs, drawings, parts lists, talking to ERP or PLM. Most real automations use both, and deciding the boundary early saves a rewrite later.
Can we do this without hiring a developer?
Yes, and that is usually the point given the hiring market. Journaling lets your own designers produce first drafts, and we take those to production quality, put them under source control and hand back something two of your people can maintain. What does not work is expecting a busy designer to also be your software maintenance function.
Does it need Teamcenter?
No. The automation runs against NX and the file system, and plenty of machine builders start exactly there. Teamcenter changes where results are stored, not whether the automation works. If you already run it, integrate from the beginning; if you do not, adding a PLM rollout to the scope is the surest way to push the first result out by two quarters.
Next Step
Bring your existing automation folder and the module you build most often. One hour is enough to say what should be modernised, what should be automated next, and what each is worth in engineering hours.
Book a call about NX Open automation for your engineering department