Automatizarea Siemens NX: versiunea scurtă
Automatizarea Siemens NX înseamnă înlocuirea pașilor manuali repetitivi din NX, precum crearea desenelor, plasarea PMI, inserarea pieselor standard și verificările de model, cu cod sau reguli care rulează la fel de fiecare dată. inteliScience construiește acest lucru pe NX Open pentru echipe de inginerie din DACH și Europa. Primul proiect tipic: desene de variante care durau ore fiecare sunt generate în minute.
| Flux de lucru NX manual | Automatizat cu NX Open | |
|---|---|---|
| Desen de variantă | 2 până la 3 ore per membru al unei familii de piese | Minute per familie, bazat pe șablon, verificat în Teamcenter |
| PMI pe geometrie modificată | Replasate și renumerotate manual după fiecare modificare | Plasare și numerotare bazate pe reguli, care se reordonează singure |
| Reguli de proiectare ale companiei | Descoperite la eliberare sau în producție | Verificate la biroul proiectantului, în timpul modelării |
| Cine face munca | Inginerul, din nou | Un instrument testat, o singură dată; inginerul verifică |
Problema: echipele NX automatizează mai întâi ce nu trebuie
Cele mai multe inițiative de automatizare Siemens NX pornesc de la ceea ce a înregistrat un inginer motivat într-un journal săptămâna trecută și se blochează șase luni mai târziu, când acel inginer își schimbă jobul sau NX își schimbă versiunea. Proiectele care supraviețuiesc pornesc de la o altă întrebare: ce sarcină repetitivă costă departamentul cele mai multe ore pe lună și pot fi scrise regulile ei?
Orele sunt reale. În departamentele pe care le evaluăm, modelarea repetitivă, reviziile de desene și documentarea consumă în mod regulat o treime din săptămâna de lucru a unui inginer. La producătorii engineer-to-order am văzut cum doar munca de desenare ocupă până la jumătate din timpul de inginerie, pentru că fiecare comandă configurată are nevoie de un set de desene pe care nimeni nu vrea să îl facă.
Recomandarea noastră clară, înainte de a scrie orice cod: listați cele zece sarcini cel mai des repetate, notați lângă fiecare numărul de ore pe lună și marcați-le pe cele ale căror reguli le poate dicta un proiectant senior într-o singură ședință. Acestea sunt candidatele dumneavoastră. Tot ce necesită judecată rămâne la inginer, cel puțin în faza întâi.
Ce automatizăm mai întâi: șase sarcini care se amortizează într-un trimestru
Sarcinile de mai jos s-au amortizat într-un trimestru în proiectele noastre, în această ordine. Fiecare are reguli clare, repetiție ridicată și un rezultat ușor de verificat, exact profilul de care are nevoie un prim proiect de automatizare Siemens NX.
- Desene pentru familii de piese. Dintr-un singur șablon de desen, instrumentul creează desenul pentru fiecare membru al unei familii și îl arhivează în Teamcenter. Am construit acest lucru de două ori, independent, pentru clienți diferiți; de ambele dăți a fost cel mai rapid câștig de pe listă.
- Plasarea și numerotarea PMI. Adnotări plasate și numerotate pe baza coordonatelor X, Y și Z ale unui sistem de coordonate, cu un algoritm care reordonează și renumerotează atunci când proiectul se schimbă. Întreținerea manuală a PMI se rupe la fiecare revizie; o structură bazată pe reguli se corectează singură.
- Verificări ale regulilor de proiectare la biroul proiectantului. O suită de verificări care semnalează încălcările ghidurilor interne în timp ce proiectantul încă modelează, nu abia la eliberare. Costul unei încălcări de regulă crește cu fiecare poartă pe care o trece.
- Plasarea pieselor standard și rutine de curățare. Reference set-uri, disciplina straturilor, completitudinea atributelor, igiena feature-urilor suprimate, aplicate pe un întreg ansamblu într-o singură rulare.
- Generarea variantelor din expresii. Ingineria transformatoarelor și a mașinilor trăiește din familii de piese similare; expresiile plus NX Open generează varianta, desenul ei și lista de materiale (BOM), în loc ca un inginer să le editeze pe fiecare manual.
- Conversie și export în batch. Fișiere STEP aliniate la un sistem de coordonate definit și exportate per vedere ca STEP, PRT și JPEG, controlate printr-un fișier de comandă, cu NX rulând headless în spatele unui serviciu web.
De unde nu vă recomandăm să începeți? De la orice atinge intenția de proiectare: alegerea unei strategii de referințe pentru o clasă nouă de piese, stabilirea unei toleranțe sau refacerea unui model legacy a cărui istorie nu o înțelege nimeni. Acestea sunt probleme de revizuire, nu de automatizare, iar forțarea lor într-un script produce un instrument în care inginerii nu au încredere.
Ce instrument de automatizare NX pentru ce job
NX livrează mai multe straturi de automatizare decât folosesc majoritatea echipelor, iar alegerea stratului greșit este al doilea cel mai frecvent motiv pentru care un proiect se blochează. Tabelul este harta noastră de lucru la nivelul Designcenter 2606, versiunea din iunie 2026 în care Siemens a redenumit NX în Designcenter.
| Strat | Cel mai potrivit pentru | Cine îl întreține | Risc la upgrade |
|---|---|---|---|
| Journal-uri (sesiuni NX înregistrate, Python, C#, VB, Java) | Descoperirea apelurilor API de care are nevoie un flux de lucru; joburi batch punctuale | Inginerul care l-a înregistrat | Ridicat: codul înregistrat fixează rigid numele obiectelor și stările dialogurilor |
| NX Open (API-ul oficial, .NET, Python, C++, Java) | Tot ce livrați către mai mult de un inginer: comenzi personalizate, generare de desene și PMI, integrare Teamcenter | Un dezvoltator, cu teste | Mediu: API-ul este versionat și documentat; retragerile sunt anunțate |
| Expresii, familii de piese, Product Template Studio | Produse configurabile, variante cerute de vânzări, șabloane fără cod cu o interfață simplă | Proiectanți seniori | Scăzut: trăiește în piesă |
| Knowledge Fusion | Geometrie condusă de reguli, unde regulile trebuie să trăiască în model și să reacționeze la modificări | Specialiști KF, rari pe piață | Mediu; riscul sunt competențele, nu API-ul |
| Algorithmic Modeling (logică vizuală, Logic Editor) | Reguli bazate pe noduri pentru comportamentul geometriei, măsurătorilor și adnotărilor, fără programare; reutilizabile prin Reuse Library | Utilizatori avansați | Scăzut spre mediu; nou, încă în extindere |
| Agenți AI prin MCP | Acces conversațional pentru a citi piesa și, prin poarta de confirmare (gate), a rula instrumente NX Open tipizate | Dezvoltatori plus un strat AI | Depinde în întregime de gate-ul pe care îl construiți |
Trei poziții pe care le susținem după suficiente proiecte ca să fim siguri.
Journal-urile sunt pentru învățat, nu pentru livrat. Înregistrați journal-ul, citiți ce a făcut NX, apoi scrieți instrumentul real în NX Open, cu intrări denumite și tratarea erorilor. Journaling-ul este inclus în fiecare licență NX Mach series, motiv pentru care este primul pas al tuturor și ultimul pas al nimănui.
NX Open bate Knowledge Fusion pentru aproape orice echipă care nu folosește deja KF. API-ul este documentat, versionat și găsiți oameni pentru el; expertiza KF este rară și devine tot mai rară. Am descris compromisul în detaliu în comparația noastră NXOpen și Knowledge Fusion.
Algorithmic Modeling merită acum un pilot, nu un rollout. Siemens l-a introdus în 2606 pentru baze de fabricație aditivă, cu un Logic Editor și partajare prin Reuse Library, iar direcția este corectă: reguli ca noduri, nu ca scripturi. Dați-i un utilizator avansat și un caz de utilizare bine delimitat înainte de a miza un proces pe el.
Un prim instrument NX Open: de la journal la job batch
Exemplul de mai jos are forma unui prim instrument livrat: un script Python NX Open care parcurge un ansamblu, setează un atribut standard pe fiecare componentă și raportează ce a modificat. Înregistrat dintr-un journal, apoi rescris cu intrări explicite, o verificare și un jurnal de execuție. Rulează din interpretorul Python al NX sau headless prin 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__":
import sys
session = NXOpen.Session.GetSession()
path = sys.argv[-1] if sys.argv else ""
if path.lower().endswith(".prt"): # batch: assembly passed after -args
session.Parts.OpenBaseDisplay(path)
n = set_attribute_on_components("ISC_RELEASE_STATE", "IN_WORK")
session.ListingWindow.WriteLine(f"components updated: {n}")
if path.lower().endswith(".prt"):
session.Parts.Work.Save(NXOpen.BasePart.SaveComponents.TrueValue, NXOpen.BasePart.CloseAfterSave.TrueValue)Rulați-l headless pe un folder de ansambluri fără a deschide interfața NX, pentru că așa își au locul joburile batch în producție:
# 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"
)Două obiceiuri îl deosebesc de journal-ul din care a pornit. Instrumentul își primește intrările ca parametri și refuză să ruleze pe o piesă care nu este un ansamblu. Și scrie ce a modificat în listing window, astfel încât inginerul care îl rulează să poată verifica rezultatul în loc să se încreadă în el.
Acesta rulează ca un POC. Ce lipsește pentru producție: o distribuire controlată de administratorul CAD, teste pe versiunile NX pe care le folosiți efectiv, tratarea erorilor pentru piese blocate sau extrase (checked-out), conștientizarea Teamcenter și un responsabil după plecarea autorului. Închidem decalajul dintre “rulează pe mașina mea” și “rulează în departamentul de inginerie” — vedeți cum construim automatizarea fluxurilor NX pentru producție.
Cum supraviețuiește automatizarea NX următorului upgrade
Un instrument NX Open scris în 2024 va întâlni anul acesta Designcenter 2606, iar întrebarea este dacă l-a testat cineva. Siemens versionează API-ul NX Open și documentează retragerile, deci ruperea este previzibilă; ceea ce lipsește de obicei sunt un set de teste și un responsabil.
Ce punem în practică în fiecare proiect și ce recomandăm chiar și pentru instrumente pe care nu le-am scris noi:
- Un set de regresie de cinci până la zece piese reale per instrument, cu rezultate așteptate, rulat înaintea fiecărui upgrade NX.
- Parametri și unități în fiecare semnătură. Niciodată selecții pe ecran, niciodată nume de obiecte fixate în cod dintr-un journal.
- O singură cale de distribuire. O comandă personalizată pe care administratorul CAD o instalează și o actualizează, nu un script trimis prin e-mail.
- Responsabilitate nominală. Un instrument fără responsabil este datorie tehnică cu dată de început.
Dacă aveți un raft de journal-uri și macro-uri Visual Basic pe care nimeni nu îndrăznește să le atingă, soluția onestă este o trecere de modernizare, nu o rescriere de la zero; serviciul nostru de modernizare a codului NX legacy începe cu inventarierea a ceea ce încă rulează.
Unde își are locul AI în automatizarea Siemens NX astăzi
AI schimbă două lucruri în 2026 și lasă neatins nucleul determinist. Întâi, generarea de cod: un model de frontieră precum claude-sonnet-5 scrie fiabil schela de cod NX Open și inventează apeluri API care nu există, motiv pentru care ancorarea pe referința NX Open și verificarea headless a fiecărui journal înjumătățesc aproximativ timpul până la un instrument revizuit. Am măsurat acest lucru în testele noastre de generare de cod NX Open. În al doilea rând, agenții: prin Model Context Protocol, un asistent poate citi piesa deschisă și, după o previzualizare și o confirmare, poate apela aceleași instrumente NX Open tipizate descrise mai sus.
Propriul Designcenter Copilot al Siemens, livrat cu 2606, răspunde din documentație și din sarcina curentă. Nu rulează NX Open în locul dumneavoastră și, la septembrie 2026, nu există un server MCP oficial Siemens pentru modelarea NX. Pentru automatizare, asta înseamnă că stratul AI este ceva ce adăugați setului de instrumente, nu ceva care îl înlocuiește.
Poziția noastră: păstrați regulile deterministe, lăsați AI să genereze și să explice cod și lăsați agenții să apeleze instrumente doar printr-un gate. Echipele care au lăsat un model să scrie și să ruleze journal-uri direct au dat înapoi, fără excepție.
Siemens NX AI de la inteliScience pune această abordare în practică: asistenți care răspund, agenți care acționează printr-o poartă de aprobare și instrumente de geometrie testate pe piesele dumneavoastră.
Costuri și calendar pentru un prim proiect
Un prim proiect de automatizare Siemens NX este mai mic decât se așteaptă majoritatea echipelor, pentru că prima sarcină este aleasă după repetiție și reguli clare. Evaluarea noastră gratuită de automatizare NX analizează fluxurile dumneavoastră recurente și le ordonează după orele economisite. Un proof of concept NX Open, un caz de utilizare concret construit și testat pe datele dumneavoastră în mediul dumneavoastră NX, începe de la €3,000. Un sprint proof-of-value cu preț fix pe bibliotecile dumneavoastră NX Open începe de la €12,900. Proiectele complete de automatizare, de exemplu un generator de desene pentru o linie de produse cu arhivare în Teamcenter, se situează în zona de mijloc a sumelor cu cinci cifre și sunt dimensionate după proof of concept, nu înainte.
Calendar: două săptămâni pentru un proof of concept pe o sarcină, șase până la zece săptămâni pentru un instrument de producție cu teste, distribuire și predare. Amortizarea cazurilor de utilizare pentru desene și PMI de mai sus s-a produs într-un trimestru în fiecare proiect în care lista de sarcini a fost construită din ore măsurate.
Întrebări frecvente
Ce este automatizarea Siemens NX?
Automatizarea Siemens NX înseamnă folosirea straturilor de programare și de reguli din NX, în principal NX Open, journal-uri, expresii și Product Template Studio, pentru a executa sarcini repetitive de modelare, desenare, verificare și documentare fără clicuri manuale. Sarcina rulează la fel de fiecare dată, iar inginerul verifică rezultatul în loc să îl producă.
Ce ar trebui să automatizăm mai întâi în NX?
Începeți cu sarcina care costă cele mai multe ore pe lună și ale cărei reguli le poate dicta un proiectant senior într-o singură ședință. În proiectele noastre, aceasta este aproape întotdeauna generarea desenelor pentru familii de piese, urmată de plasarea și numerotarea PMI, apoi de verificările regulilor de proiectare ale companiei direct la biroul proiectantului.
Journal-uri NX vs. NX Open: care este diferența?
Un journal (jurnal NX) este înregistrarea unei sesiuni NX interactive sub formă de cod; NX Open este API-ul oficial, versionat, pe care journal-ul îl apelează. Journal-urile sunt ideale pentru a descoperi de ce apeluri are nevoie un flux de lucru. Instrumentele pe care le va rula mai mult de un inginer ar trebui rescrise în NX Open cu parametri, tratarea erorilor și teste.
Cât costă automatizarea Siemens NX?
O evaluare a fluxurilor dumneavoastră de lucru recurente este gratuită la noi. Un proof of concept pentru un caz de utilizare începe de la €3,000, un sprint proof-of-value pe bibliotecile dumneavoastră de la €12,900, iar instrumentele complete de producție, cum ar fi un generator de desene cu arhivare în Teamcenter, se situează în zona de mijloc a sumelor cu cinci cifre. Prima sarcină se amortizează de regulă într-un trimestru.
Ar trebui să folosim Python sau C# pentru NX Open?
Python este cea mai rapidă cale de a începe, pentru că NX livrează un interpretor și journal-urile se înregistrează în el; C# și .NET sunt alegerea mai bună pentru comenzi personalizate pe care administratorul CAD le distribuie unui întreg departament. Am comparat cele două în detaliu în ghidul nostru NXOpen Python vs. C#; majoritatea instrumentelor noastre de producție sunt .NET, majoritatea prototipurilor sunt Python.