Automatizarea desenelor NX: versiunea scurtă
Automatizarea desenelor NX înseamnă producerea desenelor Siemens NX din modelul master prin șabloane, atribute de piesă și programe NXOpen, astfel încât fiecare foaie a unei familii de piese să arate ca prima. inteliScience, specialiști Siemens NX și NXOpen care livrează nearshore din România, lucrează pe trei niveluri, șabloane, jurnale și generare batch, și măsoară fiecare pilot față de o linie de referință.
| Întrebare | Răspuns într-o propoziție |
|---|---|
| De ce încă desene? | MBD crește, dar desenul rămâne documentul pe care îl semnează furnizorii, achizițiile și QA. |
| Care este fundația? | Modelul master: un fișier de piesă conține geometria, un al doilea fișier de piesă conține desenul și îl referențiază pe primul. |
| Unde începe automatizarea? | Cu șabloane înregistrate în PAX și un indicator care citește atributele piesei. Încă fără cod. |
| Când se amortizează codul? | Când același tipar de foaie se repetă într-o familie de piese sau când un depozit de date (vault) plin de piese are nevoie de desene regenerate. |
| Ce trebuie verificat după aceea? | Starea vederilor, alinierea, vederile orfane, completitudinea indicatorului și scara, ideal de un verificator în batch. |
| Unde se încadrează AI? | Citește modelul și propune documentația. NXOpen execută, un om eliberează. |
1. De ce desenele încă există în 2026
Desenele supraviețuiesc pentru că sunt contracte, nu pentru că cineva iubește desenarea. Un furnizor ofertează pe baza unui desen. Inspecția la recepție măsoară pe baza unui desen. Departamentul de achiziții al unui client arhivează o revizie de desen lângă comandă. Definiția bazată pe model mută adnotările în modelul 3D și este în mod clar direcția de dezvoltare, însă în majoritatea lanțurilor de aprovizionare DACH cu care lucrăm, desenul PDF este încă artefactul care primește o semnătură. Am comparat cele două abordări în detaliu în articolul nostru despre MBD versus desenul 2D; răspunsul scurt este că cele două coexistă ani de zile în orice lanț de aprovizionare real.
Această coexistență este motivul pentru care automatizarea desenelor NX contează. Dacă desenul ar dispărea anul viitor, nimeni n-ar trebui să investească în automatizarea lui. Nu dispare. Este produs, în multe companii, manual, pentru piese a căror geometrie a ieșit deja dintr-un configurator sau dintr-un tabel de familie.
Momentul este potrivit și dintr-un alt motiv. Siemens a redenumit Designcenter NX în Designcenter odată cu versiunea din iunie 2026, versiunea 2606, anunțată pe 23 iunie 2026, iar titlurile au fost Copilot, colaborarea Live Share și ingineria imersivă. Drafting nu este locul unde se află noile funcții, ceea ce înseamnă că aplicația Drafting și API-ul de drafting NXOpen sunt mature, stabile și sigure pentru automatizare. Programul Early Access din septembrie 2026 pentru următoarea versiune, Designcenter 2612 (săptămâna virtuală de la 31 august la 4 septembrie, săptămânile cu prezență fizică de la 14 la 25 septembrie 2026 în Mason, Ohio), a enumerat ca arii de focus modelarea de bază, un sistem unificat de tokenuri, ingineria colaborativă și proiectarea asistată de AI. Din nou, nu drafting-ul. Stiva de desenare pe care o automatizați azi este stiva pe care o veți avea peste doi ani.
Acest document este scris pentru manageri CAD, administratori NX și lideri de inginerie care răspund de debitul de desene.
2. Conceptul model master în NX
Un desen model master înseamnă două fișiere. Piesa model, să zicem bracket.prt, conține geometria, expresiile, PMI și vederile de model. Piesa desen, să zicem bracket_dwg.prt, conține modelul master ca o componentă de ansamblu și găzduiește foile, vederile de desen, cotele și indicatorul. Vederile din desen indică vederi de model din master. Modificați masterul, actualizați desenul, gata. Siemens descrie aceasta ca fiind modalitatea recomandată de a crea desene, iar fiecare nivel de automatizare din acest whitepaper o presupune.
De ce două fișiere în loc de foi în interiorul piesei model? Trei motive care contează pentru automatizare. Desenul nu blochează modelul: un proiectant lucrează pe bracket.prt în timp ce un desenator lucrează pe bracket_dwg.prt, iar în Teamcenter cele două există ca dataset-uri separate sub aceeași revizie de item, modelul ca dataset UGMASTER și desenul ca dataset UGPART care poartă masterul ca o componentă. Desenul poate purta propria geometrie, o vedere explodată sau un set de referință doar pentru desen, fără a polua masterul de care depind CAM, simularea și exportul STEP al furnizorului. Iar un proces batch poate regenera desene fără a atinge modelul, ceea ce este proprietatea pe care se sprijină întregul nivel batch din capitolul 6.
Recomandarea noastră, spusă cât se poate de clar: niciodată nu „salvați modelul ca desen”. O piesă model cu foi în interior este un fișier cu două cicluri de viață, iar în ziua în care cineva o salvează sub un nume nou pentru a face o variantă, istoricul reviziilor se bifurcă. Am curățat asta pentru clienți de mai multe ori și costă întotdeauna mai mult decât cele zece minute economisite prin scurtătură.
Piesa model (bracket.prt) |
Piesa desen (bracket_dwg.prt) |
|
|---|---|---|
| Conține | Geometrie, expresii, PMI, vederi de model, atribute | Foi, vederi de desen, cote, note, indicator |
| Referințe | Nimic deasupra ei | Piesa model ca o componentă |
| Se modifică atunci când | Se modifică proiectarea | Se modifică proiectarea (prin actualizare) sau documentația |
| Dataset Teamcenter | UGMASTER | UGPART |
| Atins de batch | Nu | Da |
3. Șabloane de desen și standarde
Șabloanele sunt primul nivel de automatizare și cel pe care fiecare instalare NX îl are deja. Când alegeți File > New > Drawing, NX citește un fișier PAX, un fișier text care listează fiecare șablon cu un id, un nume, o descriere, unități și numele de fișier al piesei șablon. Două fișiere contează: ugs_drawing_templates.pax pentru File > New > Drawing și ugs_sheet_templates.pax pentru Insert > Sheet, cu variantele cu prefixul nxdm_ pentru instalările gestionate de Teamcenter. Într-o instalare nativă, ele se află în folderul DRAFTING\templates al instalării NX, de exemplu C:\Program Files\Siemens\NX2206\DRAFTING\templates într-o instalare NX 2206. Varianta mai curată este să setați UGII_TEMPLATE_DIR către un folder al companiei și să păstrați acolo fișierele PAX și piesele șablon, astfel încât un upgrade NX să nu le suprascrie. Comanda „Mark as Template” înregistrează o piesă șablon și actualizează fișierul PAX pentru dvs.; un editor de text funcționează la fel de bine.
Un singur tag din intrarea PAX decide mai mult decât își dau oamenii seama: UsesMasterModel. Controlează dacă noul desen vă cere o piesă de referențiat sau stă singur. Dacă vreți desene model master, și vreți, tagul trebuie setat pe fiecare șablon pe care echipa dvs. îl poate alege.
3.1 ISO față de ANSI
Standardul de desenare se stabilește la crearea desenului și determină dimensiunile foilor, unghiul de proiecție, stilul cotelor, vârfurile de săgeată, fonturile și stilul de vedere implicit. Pentru atelierele DACH, asta înseamnă standardul ISO cu proiecție în primul diedru și foi din seria A; șabloanele ANSI livrate cu NX și care apar în majoritatea tutorialelor YouTube folosesc proiecția în al treilea diedru și foi format letter. Un desen creat pe șablonul greșit nu se repară schimbând chenarul. Se recreează.
Recomandarea noastră clară: reduceți fișierele PAX la șabloanele pe care compania dvs. le folosește efectiv, câte unul per dimensiune de foaie și standard. Un selector cu treizeci de intrări, jumătate dintre ele ANSI, este modul în care standardul greșit ajunge pe un desen de furnizor.
3.2 Indicatorul citește atribute, nu se tastează
Indicatorul dintr-un șablon este un tabel cu note, iar fiecare câmp care poate fi o referință la atribut ar trebui să fie una. Numărul piesei, denumirea, revizia, materialul, masa, câmpurile desenat-de și verificat-de, data: toate acestea există ca atribute de piesă pe master sau pe piesa desen, iar o notă care referențiază un atribut se actualizează când atributul se schimbă. Un indicator tastat manual este un indicator care minte după următoarea revizie și este totodată motivul pentru care un proces batch nu îl poate completa.
Aceasta este granița dintre nivelul unu și nivelul doi. Dacă indicatorul este bazat pe atribute, un program NXOpen trebuie doar să seteze atribute, iar foaia urmează. Dacă indicatorul este tastat, programul trebuie să găsească și să editeze textul notelor, ceea ce este fragil și specific standardului. Reparați mai întâi șablonul, scrieți codul după.
| Abordare | Efort de configurare | Efort per desen | Consecvență | Se strică atunci când |
|---|---|---|---|---|
| Desenare manuală pe un șablon implicit | nimic | ridicat, fiecare vedere și fiecare câmp manual | depinde de desenator | cineva se grăbește |
| Bazat pe șablon (PAX, standard, indicator cu atribute) | zile, o singură dată | mediu, vederi manual, indicator fără efort | ridicată la indicator, medie la vederi | apare un standard nou sau o dimensiune de foaie nouă |
| Batch NXOpen pe desene bazate pe șablon | săptămâni, o dată per tipar de foaie | minute de timp de mașină | ridicată, identică prin construcție | se schimbă tiparul de foaie sau o piesă iese din tipar |
4. Tipuri de vederi în practică
Vederea de bază, vederile proiectate, secțiunile, secțiunile parțiale (break-out) și vederile explodate acoperă mare parte din ce are nevoie un desen mecanic. Fiecare se comportă puțin diferit în conceptul model master, iar una dintre ele are o capcană care umple firele de discuție din Siemens Community an de an.
| Tip de vedere | Familie de comenzi | În conceptul model master | Notă de automatizare |
|---|---|---|---|
| Vedere de bază | Base View, alegeți vederea de model (Front, Top, Trimetric sau o vedere salvată) | Citește vederile de model ale masterului și ale piesei desen | Singura vedere pe care o plasează fiecare job batch; ancora pentru restul |
| Vedere proiectată | Trageți din vederea de bază cu cursorul | Urmează standardul și unghiul de proiecție ale vederii de bază | Plasată relativ la părinte, ieftin de automatizat |
| Vedere în secțiune | Section View pe un părinte activ, trasați linia de secționare | Hașura din stilul de vedere și din setările de secțiune ale corpului | Are nevoie de o linie de secționare definită; automatizați doar pentru tipare de geometrie fixe |
| Secțiune parțială (break-out) | Break-Out Section (în Command Finder: breakout), contur închis plus adâncime | Tăietură locală, părintele rămâne întreg | Bazată pe schiță; rareori merită automatizată |
| Vedere explodată | Explozie creată în Modeling pe piesa desen, apoi Base View cu Part = piesa desen | Trebuie să existe în piesa desen, nu în master | Automatizabilă odată ce explozia există în piesa desen |
4.1 Mai întâi vederea de bază, apoi restul
File > New > Drawing. Alegeți șablonul ISO de dimensiunea potrivită. Dialogul cere o piesă: indicați modelul, nu un desen gol. Plasați o Base View, alegeți Front sau ce prescrie standardul dvs. ca vedere principală, apoi trageți vederile proiectate din ea. Trei vederi, o comandă. Tot ce urmează este un tip de vedere.
4.2 Secțiunea și secțiunea parțială
O vedere în secțiune taie părintele de-a lungul unei linii pe care o trasați și plasează rezultatul în direcția de proiecție. Hașura vine din stilul de vedere și din setările de secțiune ale corpului; a picta o hașură manual este un semn că stilul de vedere este greșit. O secțiune parțială (break-out) este diferită: aveți nevoie de un contur închis schițat pe vederea părinte expandată și de o adâncime, iar NX îndepărtează un buzunar local de material, astfel încât o gaură sau o nervură să se vadă fără a tăia întreaga piesă. Dacă break-out-ul arată ca o secțiune completă, adâncimea străbate piesa sau conturul este întreaga vedere. Undo, contur mai mic.
4.3 Vederea explodată și capcana selectorului Part
Aceasta este vederea care umple firele de discuție din Siemens Community. În conceptul model master, nu puteți afișa în piesa desen o vedere explodată a masterului. Indicația din sfatul rapid Siemens Community despre vederile explodate în conceptul de desen model master este explicită: creați explozia în aplicația Modeling a piesei desen, salvați vederea de model, reveniți în Drafting, deschideți Base View, extindeți grupul Piesă din partea de sus a dialogului, selectați piesa desen sub Loaded Parts și abia apoi alegeți vederea de model explodată.
Valoarea implicită a câmpului Part din dialogul Base View este masterul. Explozia nu este în master. De aceea „Explosion 1” nu apare niciodată în lista de vederi și acesta este cel mai frecvent motiv pentru care o echipă trage concluzia că vederile explodate „nu funcționează pe desene”.
Unele echipe sar peste explozii și folosesc un aranjament de ansamblu denumit în acest scop, apoi aleg acel aranjament pe vedere; pentru subansambluri imbricate, asta este adesea mai curat. Liniile de trasare (tracelines) sunt punctul slab în ambele cazuri. Nu facem afirmații specifice unei versiuni despre dacă o versiune viitoare de Designcenter relaxează această restricție. Verificați selectorul Part de fiecare dată, pe fiecare versiune.
Primul lucru pe care îl rulăm pe orice desen despre care cineva spune că este „greșit” este o listare a foilor și vederilor cu scara și starea de actualizare. Răspunde dintr-o privire la întrebarea vederii explodate, deoarece o vedere plasată pe master arată un nume de vedere normal, nu explozia.
# List every sheet and drafting view in the work part (NXOpen Python).
# Run inside NX (File > Execute > Journal) or via run_journal in batch.
import NXOpen
def list_drawing_views():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
lw.WriteLine("Drawing part: " + work_part.Leaf)
for sheet in work_part.DrawingSheets:
lw.WriteLine("Sheet: " + sheet.Name)
for view in sheet.SheetDraftingViews:
state = "OUT OF DATE" if view.IsOutOfDate else "current"
lw.WriteLine(" view={0} scale={1} {2}".format(
view.Name, view.Scale, state))
if __name__ == "__main__":
list_drawing_views()Dacă vederea dvs. explodată lipsește din acea listă, ați plasat o vedere trimetrică a masterului. Repetați Base View cu piesa desen selectată.
5. Moștenirea PMI: reutilizarea adnotărilor modelului
Dacă modelele dvs. poartă PMI, desenul nu ar trebui să le retasteze. NX Drafting poate moșteni PMI într-o vedere de desen, iar comportamentul este bine definit în documentația NX. PMI moștenit este afișat cu preferințele de adnotare ale desenului, nu cu preferințele aplicate în vederea de model, iar dimensiunea sa se ajustează la scara desenului. Poziția și orientarea față de geometrie rămân ca în vederea de model; dacă axa z a adnotării este orientată spre interiorul desenului, NX o rotește astfel încât să se citească corect.
Partea care contează pentru acest whitepaper este suportul pentru model master. Când creați un desen non-master dintr-o piesă master, sunt disponibile vederile de model atât ale piesei desen, cât și ale piesei master, NX menține asocierile către master, iar vederile de desen preiau modificările PMI din master atunci când se actualizează. Dacă cineva adaugă PMI la o vedere de model deja plasată pe un desen cu opțiunea Inherit PMI, NX marchează desenul ca neactualizat, evidențiază vederile afectate în dialogul Update Views și adaugă noul PMI la vederea de desen la actualizare.
Trei consecințe practice. Moștenirea PMI transformă desenul într-o redare a adnotărilor modelului, singura modalitate prin care un desen și un model rămân consecvente fără ca o persoană să le compare. Calitatea desenului moștenit este exact calitatea PMI, așa că PMI prost plasat sau prost numerotat produce o vedere ilizibilă, motiv pentru care automatizăm plasarea și numerotarea PMI înainte de a automatiza desenele. Iar o vedere de desen neactualizată este o stare citibilă de mașină, IsOutOfDate în NXOpen, pe care un job batch o verifică și o actualizează în locul unei persoane care deschide fiecare desen.
Am sfătui împotriva moștenirii PMI într-un desen al cărui standard diferă de cel sub care a fost creat PMI. Adnotările se redau, dar convențiile de tolerare s-ar putea să nu corespundă cu ce așteaptă furnizorul, iar nimeni nu observă până la inspecția la recepție.
6. Cele trei niveluri de automatizare
Automatizarea desenelor NX nu este un singur lucru. Sunt trei niveluri cu costuri diferite, riscuri diferite și puncte diferite în care se rup. Majoritatea echipelor ar trebui să le urce în ordine.
| Nivel | Ce este | Efort de configurare | Beneficiu | Se strică atunci când |
|---|---|---|---|---|
| (a) Șabloane + atribute | Șabloane înregistrate în PAX per standard și dimensiune, indicator bazat pe atribute, stiluri de vedere ale companiei | Zile, o singură dată, fără cod | Fiecare desen începe corect; indicatorul nu se tastează niciodată | Apare un al doilea standard sau o copie de șablon negestionată |
| (b) Jurnale și programe NXOpen | Jurnale înregistrate curățate în funcții, sau un program NXOpen compilat, care plasează foaia și vederile recurente pentru o clasă de piese | Una până la trei săptămâni per tipar de foaie | O primă foaie în secunde, identică pentru fiecare membru al familiei | Geometrie în afara tiparului sau o vedere care necesită judecată (secțiuni prin caracteristici variabile) |
| (c) Generare batch | Nivelul (b) condus de run_journal peste o listă de piese, pe un folder sau pe vault, cu verificări ale rezultatului | Săptămâni, inclusiv pasul de verificare și tratarea erorilor | Sute de desene regenerate peste noapte după o modificare de șablon sau de standard | Piese cu legături rupte, vederi de model lipsă sau seturi de referință nestandard; fără GUI înseamnă fără dialoguri |
6.1 Nivelul (a): nivelul fără cod
Tot ce este în capitolul 3. Începem fiecare proiect de automatizare a desenelor aici, deoarece un program care plasează vederi pe un șablon prost configurat produce doar desene proaste mai repede.
6.2 Nivelul (b): jurnale și programe
Un jurnal înregistrat este cea mai rapidă cale de a învăța ce face API-ul de drafting NXOpen: înregistrați o vedere de bază și două vederi proiectate și aveți apelurile de builder exacte pentru versiunea dvs. de NX. Înregistrarea nu este însă automatizarea. Are nume hard-codate, coordonate hard-codate și nicio tratare a erorilor. Pasul de la jurnal la program, pe care l-am descris în comparația noastră dintre jurnalele NX și programele NXOpen, este locul unde tiparul de foaie devine o funcție cu parametri: care piesă, care vederi de model, care scară, care șablon.
Suprafața API de care aveți nevoie este mică. NXOpen.Session.GetSession() și session.Parts.Work vă dau piesa desen. work_part.DrawingSheets și sheet.SheetDraftingViews vă permit să inspectați ce există. work_part.DraftingViews.CreateBaseViewBuilder(...) returnează un BaseViewBuilder a cărui proprietate SelectModelView, Placement, Să scaleze și Style sub-buildere corespund grupurilor din dialogul Base View. Atributele se citesc cu GetUserAttributes() și se scriu cu SetUserAttribute(...) pe orice NXObject, inclusiv pe piesa însăși.
Recomandarea noastră pentru nivelul (b): rămâneți în Python pentru inspecție, verificare și orchestrare și treceți la un program NXOpen compilat doar atunci când logica de plasare depășește câteva sute de linii sau are nevoie de o interfață adecvată. Jurnalele Python nu au nevoie de pas de build și sunt ceea ce majoritatea administratorilor CAD pot întreține după ce plecăm.
6.3 Nivelul (c): batch pe folder sau pe vault
run_journal.exe pornește un proces NX fără GUI și rulează un jurnal în el; începând cu NX 11 se află în folderul NXBIN al instalării. În modul batch nu există dialoguri, așa că un jurnal care apelează o casetă de mesaj eșuează, iar jurnalul trebuie să deschidă singur piesa pe care lucrează. Aceasta este o constrângere și o caracteristică: un job batch este determinist prin construcție.
Nivelul (c) este locul unde o modificare de șablon, de indicator sau de standard încetează să mai fie un proiect: regenerarea desenelor unei familii după ce indicatorul a primit un câmp nou devine o noapte de timp de mașină. Este și nivelul la care erorile se cumulează. O piesă cu o legătură WAVE ruptă, o vedere de model lipsă sau un set de referință neobișnuit eșuează silențios dacă jobul nu își verifică propriul rezultat, ceea ce este capitolul 8.
Nu începeți la nivelul (c). Jobul batch este doar atât de bun cât funcția de foaie pe care o apelează, iar funcția de foaie este doar atât de bună cât șablonul de la care pornește.
7. Exemplu practic: automatizarea primei foi a unei familii de piese
Scenariul: o familie de suporturi prelucrate prin așchiere, toate modelate din același șablon cu aceleași vederi de model, fiecare având nevoie de o primă foaie cu o vedere de bază frontală, două vederi proiectate și un indicator bazat pe atribute. Geometria diferă, tiparul de foaie nu. Vrem un job care deschide fiecare piesă desen, o verifică, actualizează ce este neactualizat, marchează atributul de revizie și salvează.
Exemplul de mai jos este în mod deliberat un job de inspectare și actualizare, nu o plasare de vederi de la zero. Este ceea ce rulăm primul în fiecare pilot, deoarece produce valoare pe desenele existente înainte de a crea vreo vedere nouă. Vederile noi folosesc tiparul de builder prezentat după aceea.
# first_sheet_job.py: verify and refresh the first sheet of a master model
# drawing, then stamp the revision attribute. Runs in batch via run_journal.
# Usage: run_journal.exe first_sheet_job.py -args <drawing.prt> <revision>
import sys
import NXOpen
REQUIRED_ATTRIBUTES = ["PART_NUMBER", "PART_NAME", "REVISION", "MATERIAL"]
# Adjust the names above to the attributes your title block references.
def attribute_titles(nx_object):
"""Return the set of user attribute titles present on an NX object."""
return {info.Title for info in nx_object.GetUserAttributes()}
def check_title_block(drawing_part, lw):
"""Report title block attributes missing on the drawing part."""
present = attribute_titles(drawing_part)
missing = [name for name in REQUIRED_ATTRIBUTES if name not in present]
for name in missing:
lw.WriteLine(" MISSING attribute: " + name)
return not missing
def refresh_first_sheet(drawing_part, lw):
"""Update out-of-date views on the first sheet and report scale."""
sheets = drawing_part.DrawingSheets.ToArray()
if not sheets:
lw.WriteLine(" ERROR: drawing part has no sheets")
return False
first = sheets[0]
lw.WriteLine(" Sheet: " + first.Name)
ok = True
for view in first.SheetDraftingViews:
if view.IsOutOfDate:
lw.WriteLine(" updating view " + view.Name)
view.Update()
lw.WriteLine(" view={0} scale={1}".format(view.Name, view.Scale))
return ok
def main(args):
session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()
path, revision = args[0], args[1]
drawing_part, load_status = session.Parts.OpenActiveDisplay(
path, NXOpen.DisplayPartOption.AllowAdditional)
load_status.Dispose()
lw.WriteLine("Opened " + drawing_part.Leaf)
title_ok = check_title_block(drawing_part, lw)
sheet_ok = refresh_first_sheet(drawing_part, lw)
if title_ok and sheet_ok:
# -1 means a non-array attribute; Update.Option.Now applies it at once.
drawing_part.SetUserAttribute(
"REVISION", -1, revision, NXOpen.Update.Option.Now)
drawing_part.Save(NXOpen.BasePart.SaveComponents.TrueValue,
NXOpen.BasePart.CloseAfterSave.FalseValue)
lw.WriteLine(" saved with REVISION=" + revision)
else:
lw.WriteLine(" NOT saved: fix the reported problems first")
if __name__ == "__main__":
# run_journal passes -args values through sys.argv after the script name.
main(sys.argv[1:])Ce face jobul, în ordine. Deschide piesa desen, ceea ce aduce masterul ca o componentă. Verifică dacă atributele pe care le referențiază indicatorul există pe piesa desen și le listează pe cele lipsă, în loc să ghicească valori. Parcurge vederile de desen de pe prima foaie, le actualizează pe cele pe care NX le-a marcat ca neactualizate și înregistrează numele și scara fiecărei vederi, astfel încât logul să poată fi comparat cu tiparul așteptat. Doar dacă ambele verificări trec, setează atributul de revizie, pe care îl citește indicatorul, și salvează. Un desen cu probleme este lăsat neatins și raportat, ceea ce este comportamentul pe care un manager CAD îl va accepta în batch.
Plasarea unei noi vederi de bază urmează scheletul de builder de mai jos. Punctul de plasare și scara provin de la Placement și Să scaleze ca sub-buildere, iar o înregistrare de jurnal de două minute vă oferă apelurile exacte pentru versiunea dvs.
# Skeleton for placing a base view from a named model view (NXOpen Python).
import NXOpen
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
builder = work_part.DraftingViews.CreateBaseViewBuilder(
NXOpen.Drawings.BaseView.Null)
try:
# The model view lives in the master for normal views and in the
# drawing part for explosions (see chapter 4). Pick accordingly.
front = work_part.ModelingViews.FindObject("Front")
builder.SelectModelView.SelectedView = front
# builder.Placement and builder.Scale mirror the dialog groups;
# take their exact calls from a recorded journal on your NX version.
base_view = builder.Commit()
finally:
builder.Destroy()Driverul din jurul oricăruia dintre scripturi este Python simplu cu biblioteca standard: citește o listă de piese desen din exportul vault-ului sau dintr-un folder, apelează run_journal.exe o dată per piesă cu subprocess, colectează ieșirea de listare per piesă și scrie un rezumat. Fără NXOpen în driver, așa că rulează pe orice mașină și poate fi programat.
Acesta rulează ca un POC. Ce lipsește pentru producție: Șabloane pentru fiecare standard și dimensiune de foaie cerute de clienții dvs., dataset-uri Teamcenter în loc de foldere, batch pe vault cu checkout și check-in, tratarea erorilor pentru piesele care ies din tipar și verificări ale rezultatului generat înainte ca cineva să îl vadă. Închidem distanța de la „rulează pe mașina mea” la „rulează pe vault în fiecare noapte” ca specialiști NXOpen cu livrare nearshore din România, EET, cu o oră înaintea CET. Rezervați o discuție strategică despre automatizarea desenelor NX.
8. Verificări de calitate ale desenelor după generare
Un desen generat pe care nu îl verifică nimeni este o povară cu un indicator mai frumos. Verificările sunt ieftine, sunt în mare parte aceleași pentru fiecare companie și ar trebui să ruleze în același batch care a produs desenul.
| Verificare | Ce prinde | Cum se detectează |
|---|---|---|
| Starea de actualizare a vederilor | Vederi care nu reflectă modelul curent | IsOutOfDate pe fiecare vedere de desen; actualizare sau eșec |
| Alinierea vederilor | Vederi proiectate deplasate față de axele vederii de bază, vederi rotite | Comparați originile vederilor cu părintele; un verificator cu o verificare dedicată de aliniere |
| Vederi orfane și învechite | Vederi a căror vedere de model nu mai există, vederi rămase dintr-un șablon | Listați vederile per foaie și comparați cu tiparul așteptat pentru clasa de piese |
| Completitudinea indicatorului | Atribute lipsă sau nesetate pe care le referențiază indicatorul | GetUserAttributes() față de lista obligatorie, ca în capitolul 7 |
| Să scaleze | O foaie de familie la 1:2 unde tiparul spune 1:1, sau o vedere care nu încape pe foaie | Să scaleze per vedere, dimensiunea foii din DrawingSheet |
| Standard și unghi de proiecție | Foaie ANSI într-un atelier ISO, al treilea diedru unde este cerut primul diedru | ProjectionAngle și Unități pe foaie |
| Foi goale sau duplicate | Joburi batch care au rulat de două ori, șabloane cu o foaie de rezervă | Numărați foile, numărați vederile per foaie |
Două instrumente acoperă terenul de dincolo de ce verifică un job ca cel din capitolul 7. Siemens NX Check-Mate vine cu sute de verificări standard pentru modelare, drafting, PMI, geometrie, routing și alte aplicații, poate fi rulat interactiv sau în batch și are un instrument de creare pentru verificări personalizate; este locul firesc pentru regulile specifice companiei. DOCUFY CAx Quality Manager 2026.1, lansat pe 30 martie 2026, a adăugat o verificare pentru alinierea vederilor de desen, iar produsul are peste 450 de verificări configurabile, un mod batch și healing (corectare automată) pentru verificările suportate, ceea ce transformă „găsit” în „reparat” pentru cazurile pe care le acoperă. inteliScience este partener oficial DOCUFY și configurează DQM alături de Check-Mate acolo unde un client vrea aliniere și healing în aceeași rulare cu generarea. Cum își împart cele două verificatoare munca și unde se opresc verificările native NX este subiectul prezentării noastre generale despre asigurarea calității CAD în Siemens NX.
Oricare ar fi verificatorul, o regulă s-a confirmat în fiecare proiect: verificarea rulează în același pipeline cu generarea, iar o verificare eșuată lasă desenul nesalvat și raportat. Verificările care rulează o săptămână mai târziu, de către o persoană, pe un eșantion, sunt motivul pentru care automatizarea desenelor capătă o reputație proastă.
9. Unde se încadrează AI
Un asistent AI nu desenează. Citește. Rolul util al unui model lingvistic în automatizarea desenelor NX este să se uite la model, la PMI, la atribute și la clasa de piese și să propună documentația: de ce vederi are nevoie această piesă, ce tipar de foaie se aplică, ce câmpuri ale indicatorului sunt nesetate, ce note cere standardul companiei pentru acest material și proces. Propunerea este text și parametri. NXOpen o execută exact prin funcțiile din capitolele 6 și 7, iar un om eliberează rezultatul.
Această împărțire nu este prudență de dragul prudenței. Un model care plasează vederi ghicind coordonate produce desene care arată plauzibil și sunt greșite în moduri pe care un verificator s-ar putea să nu le prindă. Un model care completează un set de parametri pentru o funcție de planșă deterministă produce desene care sunt corecte prin construcție sau eșuează vizibil. Propriul nostru Asistent pentru desene și documentație urmează al doilea tipar: asistentul citește piesa deschisă și propune setul de planșe și notele.
Designcenter Copilot al Siemens, introdus odată cu versiunea din iunie 2026, răspunde la întrebări pe baza documentației și a sarcinii curente, nu plasează vederi. Rezumatul sobru pentru 2026: AI propune, NXOpen execută, un om eliberează. Echipele care se așteaptă ca o fereastră de chat să producă un desen eliberat vor fi dezamăgite; echipele care o folosesc pentru ca prima schiță să nu pornească de la zero nu vor fi.
10. Măsurarea unui pilot și calea de adoptare
Un pilot de automatizare a desenelor este judecat după cifre pe propriile dvs. piese, măsurate înainte și după. Nu publicăm aici procente de benchmark, deoarece rezultatul depinde de câte desene pe săptămână produce echipa dvs. și cât din acestea este muncă de familie. Ce publicăm este planul de măsurare pe care îl convenim cu fiecare client înainte de a scrie o linie de cod.
| Metric | Referință (înainte) | Pilot (după) | Cum se măsoară |
|---|---|---|---|
| Desene eliberate pe săptămână | numărare din vault sau din logul de eliberare | aceeași sursă | Data eliberării pe dataset-ul desenului |
| Timp per prima foaie | timpul desenatorului pe prima foaie a unui membru al familiei | timpul de rulare al jobului plus timpul de revizuire | Urmărirea timpului pe un set definit de piese |
| Bucle de refacere per desen | de câte ori un desen se întoarce de la verificare la desenator | la fel | Istoricul fluxului de lucru din Teamcenter sau logul de verificare |
| Verificări eșuate la o sută de desene | din rularea verificatorului pe stocul curent | din rularea verificatorului pe desenele generate | Raportul batch al verificatorului |
| Ponderea pieselor de familie acoperite de un tipar de foaie | desenele care se potrivesc unui tipar existent împărțite la toate desenele | la fel, după tiparele noi | Clasificarea setului de piese pilot |
| Timp de regenerare după o modificare de șablon | timpul scurs pentru ultima modificare a indicatorului | timpul de rulare batch | Logul proiectului |
Calea de adoptare care a funcționat, în ordinea în care a funcționat:
- Săptămânile 1-2: șabloane și atribute. fișiere PAX curățate la standardele în uz,
UGII_TEMPLATE_DIRsetat, indicator bazat pe atribute, o clasă de piese aleasă pentru pilot, cifre de referință colectate. - Săptămânile 3-5: prima funcție de foaie. Un tipar de foaie pentru o familie de piese, ca jurnal Python cu verificările din capitolul 8 încorporate, rulat de administratorul CAD pe piese reale și revizuit de desenatorii care obișnuiau să le deseneze.
- Săptămânile 5-7: batch pe un folder, apoi pe vault.
run_journalca driver, loguri per piesă, desene eșuate raportate în loc de salvate, verificator integrat. Cifrele pilotului raportate față de referință. - Implementarea extinsă (rollout): alte tipare de foi, integrare Teamcenter, regenerare programată după modificări de șablon și, acolo unde echipa o dorește, asistentul AI din capitolul 9 care propune seturi de foi pentru piese din afara tiparelor cunoscute.
inteliScience livrează asta din România, în EET, cu o oră înaintea CET, cu ingineri seniori NX și NXOpen care au făcut curățarea șabloanelor la fel de des ca și codul, pentru clienți din întreaga regiune DACH. Șabloanele, joburile și verificările sunt ale dvs. la final.
Întrebări frecvente
Ce este automatizarea desenelor NX?
Automatizarea desenelor NX înseamnă producerea desenelor Siemens NX din modelul master prin șabloane, atribute de piesă și programe NXOpen, în loc de manual. Acoperă de la șabloane înregistrate în PAX cu un indicator bazat pe atribute, prin jurnale care plasează vederile recurente ale unei familii de piese, până la generarea batch pe multe piese, cu verificări de calitate ale rezultatului.
Funcționează conceptul model master cu Teamcenter?
Da. În Teamcenter, modelul este stocat ca dataset UGMASTER, iar desenul ca dataset UGPART sub aceeași revizie de item, desenul purtând modelul master ca o componentă. Fluxurile de eliberare pot trata cele două separat, iar un job batch poate regenera dataset-ul desenului fără a modifica modelul. Șabloanele trebuie să folosească variantele PAX gestionate de Teamcenter.
Jurnal NX vs program NXOpen: care dintre ele pentru automatizarea desenelor?
Începeți cu un jurnal Python. Rulează fără pas de build, poate fi întreținut de un administrator CAD și acoperă inspecția, verificarea, actualizările de vederi și marcarea atributelor. Treceți la un program NXOpen compilat atunci când logica de plasare depășește câteva sute de linii, are nevoie de un dialog sau trebuie partajată ca instrument semnat între locații. Driverul batch din jurul oricăruia dintre ele este Python simplu.
Cât costă un pilot de automatizare a desenelor NX?
inteliScience stabilește proiectele pilot la preț fix după o evaluare scurtă a șabloanelor dvs. și a unei familii de piese. Factorul de cost este numărul de standarde de desenare și de tipare de foi distincte, nu numărul de piese, deoarece un tipar scris o dată regenerează oricâte desene. Un pilot care acoperă curățarea șabloanelor, o funcție de foaie și generarea batch cu verificări se încadrează în aproximativ șapte săptămâni.
Pot vederile de desen să moștenească automat PMI din model?
Da, cu opțiunea Inherit PMI pe o vedere de desen. PMI moștenit este redat cu preferințele de adnotare ale desenului, își păstrează poziția față de geometrie și, în conceptul model master, rămâne asociat cu piesa master. Când se adaugă PMI la o vedere de model aflată deja pe desen, NX marchează vederea de desen ca neactualizată și adaugă noul PMI la actualizare.
Pasul următor
Dacă desenatorii dvs. produc aceeași primă foaie pentru al douăzecilea membru al familiei luna aceasta, nivelul de șabloane este demult scadent, iar funcția de foaie este o discuție de scoping.
Discutați cu inginerii noștri despre automatizarea desenelor dvs. NX
Subiecte conexe
- Training Siemens NX pentru echipe de drafting și NXOpen
- PMI generat de AI în Siemens NX
- Automatizarea plasării și numerotării PMI, un studiu de caz
Surse
- Siemens Digital Industries Software, “Welcome to the September 2026 Early Access Program for Designcenter”, https://resources.sw.siemens.com/en-US/presentation-welcome-to-designcenter-early-access-program/ (accesat la 24 septembrie 2026)
- Siemens, “CAD model design validation” (NX Check-Mate), https://www.siemens.com/en-us/products/designcenter/nx-cad-software/mcad/design-validation/ (accesat la 24 septembrie 2026)
- Documentația Siemens NX, “Restrictions and operating characteristics for inherited PMI”, și Siemens Community, “Inherit PMI Dimensions”, https://community.sw.siemens.com/s/article/inherit-pmi-dimensions (accesat la 24 septembrie 2026)
- Siemens Community, “NX Quick Tips: Create an Exploded View in the Master Model Drawing Concept”, https://community.sw.siemens.com/s/article/nx-quick-tips-create-an-exploded-view-in-the-master-model-drawing-concept (accesat la 24 septembrie 2026)
- Siemens Community, “Pax files? NXcustom2206”, https://community.sw.siemens.com/s/question/0D54O000081SFjZSAW/pax-files-nxcustom2206, și Swoosh Technologies, “How to create a custom drafting template in NX”, https://www.swooshtech.com/2022/09/23/how-to-create-a-custom-drafting-template-in-nx/ (accesat la 24 septembrie 2026)
- Siemens Community, “Is it possible to save a UGMASTER as a UGPART of another item?”, https://community.sw.siemens.com/s/question/0D54O00006HAKdXSAX/is-it-possible-to-save-a-ugmaster-as-a-ugpart-of-another-item, și Eng-Tips, “Teamcenter master model drawings”, https://www.eng-tips.com/threads/teamcenter-master-model-drawings.272302/ (accesat la 24 septembrie 2026)
- Referința NXOpen .NET (mirror NX 2022.1): DraftingViewCollection, BaseViewBuilder, SelectModelViewBuilder, DrawingSheet, DraftingView, View, NXObject, https://nxopencsdocumentation.thescriptingengineer.com/NX2022_1/NXOpen.Drawings.DraftingViewCollection.html (accesat la 24 septembrie 2026)
- NX Journaling, “Using Batch file to run recorded journal” și “NX10/NX12 Python NXOpen Batch File Differences?”, https://nxjournaling.com/content/using-batch-file-run-recorded-journal (accesat la 24 septembrie 2026)
- DOCUFY, anunțul de lansare pentru versiunea 2026.1 (“NX-Datenqualität sichern”), 30 martie 2026, https://docufy.de/nx-datenqualitaet-sichern-neue-version-des-docufy-cax-quality-managers/ (accesat la 24 septembrie 2026)