Migrare API NXOpen: Versiunea scurtă
Migrarea API NXOpen este munca de a muta journal-uri și biblioteci NX Open compilate pe următorul release Siemens NX (Designcenter) fără a opri uneltele de producție. inteliScience, un partener de engineering nearshore din România, cu o oră înainte față de CET, tratează fiecare drop de șase luni ca o treabă de compile-and-diff. Rezultatul este automatizare care rulează în continuare pe Designcenter 2606.
Problema: unelte care rulează doar pe NX-ul de anul trecut
Migrarea API NXOpen eșuează când IT-ul actualizează seat-ul CAD și journal-ul de noapte sau add-in-ul semnat nu pornește. Siemens NX nu este problema. Seat-urile care nu au fost recompilate niciodată pe noile NXBIN assembly-uri sunt. Named drop-urile sosesc cam la fiecare șase luni. Actualizările lunare nu sunt o scuză să săriți recompilarea.
Vedem același blocaj în programele DACH. Un journal din 2019 a devenit DLL în 2021. NX s-a mutat de două ori. Nimeni nu a rețintit proiectul. În ziua în care aterizează Designcenter 2606, elementul de meniu a dispărut.
Recomandarea noastră: țineți NX la zi și tratați migrarea API NXOpen ca engineering planificat. Empachetarea (journal versus bibliotecă semnată) este în journal versus NXOpen compilat. Acest articol rămâne la defectele de la o versiune la alta.
Ce se strică cu adevărat între release-urile NX
Referințele binare, punctele de intrare Open C retrase și identificatorii de journal dintr-o înregistrare veche sunt ce se strică. Modelul de obiecte NXOpen rămâne. Tratați fiecare release de șase luni ca o nouă țintă de compilator, nu ca o rescriere a regulilor de design pe care le-ați codificat deja.
Siemens a început Continuous Release în 2019. Numele an-lună au început cu NX 2206 în iunie 2022. În ianuarie 2025 suita a fost etichetată Designcenter NX. Pe 23 iunie 2026 Siemens a anunțat că release-ul din iunie 2026 este disponibil la descărcare, cu numele CAD Designcenter (familia 2606). Următoarea familie numită este 2612. Siemens a derulat un Early Access Program Designcenter 2612 în septembrie 2026, inclusiv o săptămână virtuală 31 august–4 septembrie și săptămâni on-site în Mason, Ohio.
| Strat | Pentru ce bugetăm timp | Ce supraviețuiește de obicei |
|---|---|---|
| NXOpen .NET / Python | Session, Piesă, majoritatea builderelor | Membri marcați obsolete, apoi eliminați ulterior |
Open C / NXOpen.UF | Apeluri cu un succesor documentat | UF_* nume fără succesor |
| Fișier de proiect | Sursa pe care o dețineți | Vechi NXOpen.dll, NXOpen.UF.dll, NXOpen.Utilities.dll, NXOpenUI.dll referințe |
| Journal | Algoritmul | FindObject("...") șiruri dintr-o sesiune |
| Semnare | Author pe seat-ul de build | Resursă de semnare reconstruită pentru kit-ul nou |
Rebranding-ul ecranului de start nu este o ruptură de API. Binding-urile rămân C++, C# și VB.NET, Java și Python. Siemens documentează “NX Open differences between releases” în notele de lansare NX 2206. Citiți același subiect pentru versiunea în care intrați.
Depreciat nu înseamnă șters. O tăiere poate dura mai mult de un drop. Am prefera să corectăm avertismentul pe familia numită anterioară decât să depanăm un export lipsă pe 2606, cu atelierul deja actualizat.
Cum găsim un API NX Open depreciat
Găsiți un API NX Open depreciat îndreptând compilatorul spre noile biblioteci NX și parcurgând fiecare membru obsolete pe care IDE-ul îl semnalează. Mai întâi notele de lansare. Apoi Grep. O listă de forum din 2014 e felul în care “reparați” apeluri care nici nu sunt în arborele dvs.
Notele de lansare, apoi kit-ul Open
Deschideți “NX Open differences between releases” pentru versiunea țintă. Notele 2206 arată tiparul public. Copia dvs. din Support Center pentru 2606 este cea care contează. Un journal care acționează o comandă NX retrasă eșuează chiar dacă C# compilează. Kit-urile Open C livră uf_legacy_header.txt, uf_legacy_source.txt, și uf_ui_legacy_source.txt pentru nume vechi din era FORTRAN. Folosiți acele fișiere sau înlocuiți apelul. Nu inventați o semnătură.
Rețintiți NXBIN și recompilați
Pentru .NET, scoateți vechile referințe NXBIN și adăugați NXOpen.dll, NXOpen.UF.dll, NXOpen.Utilities.dll, NXOpen.Guide.dll, și NXOpenUI.dll din noua instalare. Recompilați. Tăierea plus tooltip-ul sunt specificația când Siemens a numit un succesor. Tooltip gol: opriți-vă și citiți lista de diferențe.
Journal-urile Python sar peste acea tăiere. Rulați-le pe un seat sandbox 2606. Eșecurile vin ca excepții, mai târziu decât un rebuild C#. Recomandarea noastră clară: dacă există un proiect Visual Studio, migrați mai întâi pe acela, apoi journal-ul.
- Comparați ultimul build verde cu noile
NXBINdate. - Recompilați cu membrii NXOpen obsoleți ca erori pe calea critică.
- Căutați în repo după
UF_,uc, șiFindObject(. - Rulați fiecare journal pe un seat sandbox, un folder pe rând.
- Comparați ieșirea listing-window cu un golden part.
Săriți pasul 2 și veți “termina” o migrare de journal care încă leagă DLL-urile vechi.
O ordine de migrare care ține automatizarea în funcțiune
Migrați ținta de compilator, apoi cele de pe calea critică UF_* apeluri, apoi journal-urile, apoi seat-urile. Niciodată invers. Userii mai întâi înseamnă un meniu întunecat și o cameră de criză. inteliScience rulează rebuild-ul ca engineering nearshore din România (EET, CET+1, nu ceasul DACH).
- Inventar. Fiecare
.vb,.cs,.py,.cpp,.dll, și fișier de meniu, plus cine îl lansează. - Sandbox NX. Instalați ținta lângă seat-ul curent. Nu suprascrieți
UGII_BASE_DIRde producție până când suita e verde. - Rebuild gol. Doar referințe NXBIN noi. Reparați erorile de compilare, fără modificări de logică.
- Cale critică. Apeluri obsolete pe job-ul nightly. Journal-uri cosmetice mai târziu.
- Golden part. Un
.prtși o ieșire pe care o puteți compara. - Semnați și lansați. Resursă de semnare nouă, grup pilot, apoi hala.
- Abia atunci lăsați IT-ul să retragă NX-ul anterior.
Faceți smoke-test pe sandbox cu session, work part și listing window.
# Sandbox smoke test, Designcenter 2606. Recorded-journal shape.
import NXOpen
theSession = NXOpen.Session.GetSession()
workPart = theSession.Parts.Work
lw = theSession.ListingWindow
lw.Open()
if workPart is None:
lw.WriteLine("FAIL: no work part")
else:
lw.WriteLine("OK: work part is loaded")
lw.Close()Dacă acel bloc nu poate printa OK pe 2606, reparați instalarea înainte să atingeți feature builder-ele. Cincizeci de journal-uri și trei DLL-uri sunt atunci mentenanță software, nu o după-amiază de CAD-admin.
Asta rulează ca POC. Ce lipsește pentru producție: pin-uire de versiune, un al doilea inginer care poate recompila, diff-uri golden-part în CI și un calendar la fiecare drop NX de șase luni în loc de o goană de weekend. Luăm journal-uri și DLL-uri care încă rulează doar pe seat-ul de anul trecut și le ținem în viață pe release-ul Designcenter curent: Modernizarea codului legacy NX Open.
Ce supraviețuiește de obicei și ce refuzăm să reparam pe fugă
Intenție parametrică, Block UI Styler .dlx fișiere pe care le mai aveți, iar testele golden-part supraviețuiesc unui upgrade NX Open. Înregistrate FindObject șiruri și Open C copiat din 2004 nu. Refuzăm scurtătura “împachetezi DLL-ul vechi și speri”.
FindObject este un instantaneu al unei sesiuni. Reluați-l pe un part restructurat și identificatorul a dispărut. În timpul migrării de journal, selectați după tip, atribut sau un builder pe care îl dețineți.
NXOpen.UF rămâne pentru că estate-urile mari încă îl apelează. Puneți un buget de avertismente pe calea critică, apoi consumați restul pe parcursul a două cicluri Continuous Release (douăsprezece luni). Un purge UF complet într-un weekend e felul în care aterizează regresii CAM. Cuplați NX cu această practică. Nu înghețați seat-ul în schimb.
Cost și calendar: două named release-uri pe an
Bugetăți migrarea API NXOpen ca linie recurentă, nu ca proiect unic. Două familii numite pe an (2206 apoi 2212, acum 2606 cu 2612 deja în EAP) sunt ceasul. Actualizările lunare sunt săptămâna greșită pentru a reținti DLL-uri.
Pagina de produs NX CAD a Siemens menționează Continuous Release la fiecare șase luni din 2019, cu nume an-lună de la NX 2206 (iunie 2022). Ținem actualizările lunare pe un seat pilot și rețintim NXBIN pe familia numită.
Nu inventăm o cifră în euro pe care Siemens nu o tipărește. Un rebuild gol al unui add-in C# care compilează înseamnă ore. Un folder de journal-uri nesemnate, fără repo, înseamnă săptămâni. Semnarea Author este o ofertă Siemens. Puneți rebuild-ul gol în calendar înainte de EAP. Echipele de la EAP Designcenter 2612 din septembrie 2026 aveau deja un sandbox.
Modificările de API sunt o parte dintr-o schimbare de versiune. Serviciul nostru de upgrade de versiune NX planifică și testează întreaga trecere, inclusiv șabloanele, customer defaults și postprocesoarele CAM.
Întrebări frecvente
Întrebările administratorilor CAD despre migrarea API NXOpen se grupează pe timing, cost, journal-uri versus DLL-uri și dacă o rescriere ar fi mai ieftină. Răspunsurile de mai jos stau singure. Dacă estate-ul e mai mult decât un add-in, următorul pas este un inventar delimitat, nu încă un fir de forum.
Ce se strică primul într-o migrare API NXOpen?
Referințe compilate către copii NXBIN anterioare ale NXOpen.dll, apoi membri obsoleți care erau avertismente la release-ul trecut, apoi FindObject șiruri. Modelul de obiecte al sesiunii nu este ce cedează în prima zi. Fișierul de proiect da.
Cum găsesc un apel API NX Open depreciat fără să ghicesc numele?
Rețintiți Visual Studio pe noile binare NX și citiți fiecare tooltip obsolete. Verificați “NX Open differences between releases” pentru acea versiune. Pentru Python, rulați journal-ul pe un seat sandbox. Dacă documentația Siemens nu numește un succesor, lăsați apelul.
Cât costă migrarea API NXOpen?
Siemens nu publică un preț de listă pentru migrarea NX Open. Numărați Author pe seat-ul de build, NX-ul sandbox pe care îl aveți deja și timpul de engineering. Un add-in C# curat înseamnă ore. Un folder de journal-uri nesemnate, fără teste, este un inventar de mai multe săptămâni. Cereți partenerului Siemens numerele de licență pentru 2026.
Este migrarea API NXOpen mai bună decât rescrierea automatizării?
Da, când automatizarea încă se potrivește procesului. Recompilați, înlocuiți apelurile obsolete, adăugați un diff pe golden-part. O rescriere câștigă când journal-ul codifică un proces mort sau sursa lipsește. Am descuraja o rescriere ca reacție implicită la un drop NX de șase luni.
Ar trebui să sărim actualizările lunare NX până la următorul named release?
Nu. Actualizările lunare sunt calea de soak a Siemens pentru remedieri. Țineți-le pe un seat pilot. Faceți migrarea API NXOpen pe familia numită (2606 acum, 2612 urmează).
Pasul următor
Dacă journal-urile încă rulează doar pe instalarea NX pe care IT-ul vrea să o retragă, programați o trecere de 60 de minute peste inventar, sandbox și DLL-ul de pe calea critică. inteliScience face asta ca engineering NX Open din România, pe ceasul EET, nu ca pitch de staffing.
Subiecte conexe
Munca Siemens NX pe care o luăm începe la hub-ul de soluții. Lângă el stau seat-ul Python pentru journal-uri și programarea NX Open personalizată, când un folder de scripturi trebuie să devină un add-in întreținut pe care încă îl puteți livra.