Jurnal NX vs NXOpen: versiunea scurtă
Jurnal NX vs NXOpen înseamnă același API în două ambalaje. Un jurnal se compilează din mers în Journal Editor. Un add-in semnat este ceea ce rulează celelalte posturi de lucru. inteliScience le scrie pe ambele pentru echipe din DACH pe Designcenter 2606. Înregistrați ca să învățați. Semnați ca să livrați.
| Jurnal NX | NXOpen compilat | |
|---|---|---|
| Ce este de fapt | Sursă NXOpen, un singur fișier, compilat de NX la momentul rulării | Același API, construit în Visual Studio / csc / python, apoi semnat |
| Licență Author pentru a rula | Nu, pentru un jurnal în editor | Nesemnat: preia Author la rulare. Semnat: alte posturi de lucru rulează pe Gateway |
| Licență Author pentru a livra | Jurnale .NET: nu. Distribuția Python este mai strictă (Python Author sau NX30106) | NX30104 (.NET) sau NX30106 (toolkit-uri C++, .NET, Java, Python) |
| Editor | Journal Editor. Un singur fișier. Listă fixă de assembly-uri | Visual Studio, teste unitare, mai multe proiecte |
| Viteză | JIT la fiecare rulare. Acceptabil pentru un lot de 50 de feature-uri. Dureros pentru un export nocturn de 8.000 de piese | Plătiți o singură dată, la compilare |
| Interfață | Limitat. Salvarea dialogurilor Block Styler necesită feature-ul Dialog Designer | Block Styler, WinForms, meniuri adevărate |
| Când îl folosim | Înregistrare, învățare, curățare punctuală, prima schiță generată de AI | Orice va rula altcineva și în 2027 |
Problema: firul de discuție Siemens are dreptate, dar este incomplet
Primul rezultat Google pentru această întrebare este în continuare un fir de discuție din Siemens Community: un jurnal este un program NXOpen. Propoziția este adevărată și tocmai de aceea lumea rămâne confuză.
Dacă nu există nicio diferență, de ce există licența Author. De ce există SignDotNet.exe atunci. De ce eșuează un DLL nesemnat cu o eroare de licență Author pe postul de lucru al unui coleg și rulează pe al dumneavoastră.
Pentru că diferența este ambalarea, nu API-ul. Jurnal NX vs NXOpen este o întrebare despre livrare. Răspunsul din Community se oprește la Journal Editor. Nu vă spune când să cumpărați NX30104 sau NX30106, nici că Python nu este același lucru ca un jurnal VB înregistrat, nici că Knowledge Fusion este o a treia categorie.
Nu recomandăm să tratați “avem jurnale, nu avem nevoie de NXOpen” ca pe o strategie. Aveți deja NXOpen. Doar nu ați decis cine are voie să îl ruleze.
Un jurnal este NXOpen cu roți ajutătoare, în mod intenționat
Înregistrați (Tools > Automation > Journal > Record) sau scrieți în Journal Editor. NX compilează acel fișier când îl rulați. Nu se consumă niciun feature Author pentru o rulare normală de jurnal .NET. Acesta este tot rostul jurnalizării: automatizare fără un SKU de dezvoltator.
Roțile ajutătoare sunt reale.
- Un singur fișier. Un jurnal de 2.000 de linii care apelează trei helpere lipite la final este felul în care mor aceste lucruri.
- O listă fixă de assembly-uri. Nu puteți adăuga pachetul NuGet al firmei și pretinde că sunteți în Visual Studio.
- Editorul este un notepad cu un buton Play. Suficient pentru un tipar de găuri. Insuficient pentru orice are teste.
- Este mai lent. JIT la fiecare rulare. Nu veți observa pe o singură piesă. Veți observa pe un lot de release.
Limbaje: recorderul poate genera limbajele NXOpen pe care NX le suportă (.NET și, în funcție de versiune și configurare, altele). Un jurnal înregistrat este un tutorial API groaznic și o hartă decentă a builderelor pe care tocmai ați dat clic. Păstrăm înregistrările ca schelet, apoi aruncăm cea mai mare parte din zgomotul de tip FindObject("NO NAME") generat.
Python este capcana anului 2026. Pare un jurnal pentru că puneți un fișier .py lângă piesă. Termenii de licențiere Siemens sunt mai direcți: pentru a scrie și a distribui cod NXOpen în Python aveți nevoie de feature-ul NX Open Python Author sau de pachetul Toolkits (NX30106, care include toolkit-ul Python). “A rulat pe postul meu de lucru” nu este același lucru cu “licențiat pentru a fi predat producției.” Întrebați partenerul dumneavoastră Siemens ce cod de feature figurează pe ofertă.
NXOpen compilat este același API, cu o semnătură
Compilat înseamnă un DLL, EXE sau JAR pe care NX îl încarcă ca aplicație. Pentru a-l construi și semna aveți nevoie de un feature Author. Numele care apar în fișierele de licență:
- NX30104 NX Open for .NET Author: biblioteci C# / VB.NET, documentație,
SignDotNet. - NX30106 NX Open Toolkits Author: C++, .NET, Java, Python într-un singur pachet (module de licență
c_p_p_author,dotnet_author,java_author,ufunc_development). - NX Open Python Author, dacă aveți nevoie doar de Python (feature separat, cereți codul pe ofertă).
- Dialog Designer, dacă veți salva dialoguri Block Styler.
Nu există o licență NXOpen de runtime separată. O aplicație semnată rulează pe un post de lucru Gateway plus licențele de module pe care codul le folosește efectiv. O aplicație nesemnată va prelua Author pentru rulare, dacă Author este disponibil pe acea mașină. Este un mod costisitor de a partaja un instrument. Nu faceți asta intenționat.
Semnarea .NET este mecanică: încorporați UGOPEN\NXSigningResource.res ca resursă Win32, apoi apelați SignDotNet.exe pe rezultat. Omiteți resursa și NX refuză assembly-ul cu o eroare de semnare, chiar dacă nu ați uitat exe-ul. Versiunile curente documentează o cale de build .NET 8 / Visual Studio 2022; verificați NX Open Programmer’s Guide pentru versiunea exactă pentru care construiți. Designcenter 2606 (iunie 2026) nu a schimbat această situație. Designcenter apare în iunie și în decembrie. Planificați următoarea matrice de compilatoare înainte de lansarea din decembrie, nu după.
// Compiled NXOpen, C#, NX 2606. This is not a journal.
// Sign with SignDotNet.exe after build or only Author seats will run it.
using NXOpen;
public class ListSolidBodies
{
public static int Main(string[] args)
{
Session session = Session.GetSession();
Part work = session.Parts.Work;
ListingWindow lw = session.ListingWindow;
lw.Open();
foreach (Body body in work.Bodies)
{
if (!body.IsSolidBody) continue;
lw.WriteLine(body.JournalIdentifier);
}
return 0;
}
public static int GetUnloadOption(string dummy) =>
(int)Session.LibraryUnloadOption.Immediately;
}Aceeași buclă ca într-un jurnal, minus editorul, plus o semnătură. Acesta este upgrade-ul.
Când alegem ce anume
Recomandarea noastră clară: jurnal până când a doua persoană are nevoie de el. Apoi compilați.
Un jurnal înregistrat este artefactul potrivit când învățați un builder, când Claude Code tocmai a generat o primă schiță sau când un inginer îl va rula de două ori și apoi îl va șterge. NXOpen compilat este artefactul potrivit când echipa CAM îl va rula după ce ați plecat, când trebuie să stea într-un meniu, când trebuie să apeleze alte două assembly-uri, când trebuie să supraviețuiască unload-ului din NX 2612.
SNAP și GRIP nu fac obiectul acestei comparații. GRIP este înghețat. SNAP este un strat licențiat. Dacă întrebarea dumneavoastră este despre reguli care trăiesc în interiorul piesei, aceea este Knowledge Fusion: mecanism de actualizare, nu ambalare. Alt articol.
Alegerea limbajului (Python vs C#) este încă o altă axă. Versiunea scurtă: jurnalele Python se scriu rapid și se distribuie greoi. C# este ceea ce semnăm pentru add-in-urile din producție.
Regula inteliScience pentru proiectele NX 2606, din munca NX Open pe care o livrăm efectiv în DACH: dacă după două săptămâni este încă în Journal Editor, este deja o problemă de mentenanță. Fie îl aruncați, fie îl puneți într-un meniu.
Gata de implementare? Cum ducem un jurnal schițat de AI până la ceva care se compilează găsiți în ghidul nostru de generare de cod NX Open cu AI.
La ce să fiți atenți când alegeți
- Cine îl rulează luna viitoare? Doar dumneavoastră: jurnal. Oricine altcineva: NXOpen semnat.
- Aveți Author pe mașina de build? Verificați dacă fișierul de licență conține
dotnet_author(NX30104 sau NX30106). Dacă nu, puteți în continuare înregistra. Nu puteți livra un DLL semnat. - Python sau .NET? Jurnalele VB/C# înregistrate sunt calea cu licențiere ușoară. Distribuția Python cere feature-ul Python Author sau NX30106. Nu presupuneți că sunt echivalente.
- Un singur fișier sau o soluție? În ziua în care aveți nevoie de un al doilea fișier, ați depășit Journal Editor.
- Va rezista până la 2612? Jurnalele se degradează la upgrade-uri pentru că înregistrările codifică fix numele obiectelor. Codul compilat cu teste măcar eșuează în CI.
consultanță Siemens NX la inteliScience înseamnă că decidem ambalarea în prima săptămână, nu după ce jurnalul stagiarului a ajuns pe share-ul fiecărui departament.
Întrebări frecvente
Care este diferența dintre un jurnal NX și NXOpen?
Un jurnal este sursă NXOpen pe care NX o compilează când îl rulați. NXOpen este API-ul de dedesubt, în orice ambalare: jurnal, DLL semnat, JAR Java, Python. Jurnal NX vs NXOpen înseamnă deci “script nesemnat într-un singur fișier” vs “aplicație pe care o puteți livra.” Aceleași apeluri, licență și editor diferite.
Am nevoie de o licență NX Open Author pentru jurnale?
Nu pentru a înregistra și rula un jurnal .NET pe propriul post de lucru. Aveți nevoie de Author (NX30104 sau NX30106) pentru a semna aplicații compilate, astfel încât alte posturi de lucru să le ruleze fără a prelua Author. Distribuția Python este excepția: bugetați feature-ul Python Author sau NX30106 dacă veți distribui fișiere .py colegilor.
Jurnal NX vs NXOpen: care este mai rapid?
DLL-ul compilat, o singură dată. Un jurnal se compilează JIT la fiecare rulare. Pentru o curățare de zece linii nu veți măsura diferența. Pentru o rulare nocturnă pe o întreagă linie de produse, da. Viteza nu este motivul pentru care compilăm. Partajarea este.
Cât costă NX Open Author?
Siemens nu publică prețurile de listă pentru NX30104 / NX30106 pe site-ul de marketing. Sunt add-on-uri, nu fac parte din pachetele Mach obișnuite. Calculați un post de lucru Author pe mașina de build, nu unul per utilizator. Aplicațiile semnate rulează apoi pe Gateway plus licențele de module. Cereți partenerului dumneavoastră Siemens oferta pentru 2026, nu unui blog.
Pot începe cu un jurnal și compila mai târziu?
Da, și exact aceasta este calea pe care o folosim. Înregistrați, eliminați zgomotul FindObject generat, treceți în Visual Studio, încorporați NXSigningResource.res, semnați. API-ul nu se schimbă. Fișierul de proiect, da. Nu așteptați până când jurnalul ajunge la 3.000 de linii.
Pasul următor
Nu sunteți sigur dacă automatizarea dumneavoastră este încă un jurnal sau deja un add-in pe care vă temeți să îl semnați? Rezervați o discuție de strategie gratuită de 60 de minute. Programați o discuție de strategie despre Jurnal NX vs NXOpen
