NXOpen Python vs. C#: pe scurt
NXOpen Python vs. C# este o decizie de implementare, nu o preferință de limbaj. Python rulează ca journal nesemnat pe orice stație NX și nu are nevoie de compilator; C# se compilează într-un add-in semnat, cu interfață proprie și performanță mai bună pe ansambluri mari. inteliScience livrează ambele variante, iar alegerea urmează modul în care automatizarea trebuie să ajungă la ingineri.
| Journal Python | Add-in C# compilat | |
|---|---|---|
| Ajunge pe stația inginerului prin | Copierea unui singur fișier | Build, semnare, implementare |
| Licență suplimentară pentru distribuire | Niciunul | Licență Author pentru semnare |
| Potrivit pentru | Iterație, echipe mici, procesare în lot | Dialoguri, ansambluri mari, infrastructuri .NET |
Problema: alegeți o singură dată și trăiți ani de zile cu alegerea
Aproape nimeni nu rescrie o automatizare NX în celălalt limbaj. Primul journal pe care cineva îl înregistrează și îl modifică stabilește limbajul pentru tot ce urmează, pentru că al doilea script împrumută din primul, al treilea din al doilea, iar trei ani mai târziu există patruzeci de fișiere și o pipeline de build pe care nimeni nu vrea să o atingă.
De aceea întrebarea merită douăzeci de minute la început. Online este însă prost tratată. Dacă o căutați, găsiți discuții din 2014 despre VB.NET și colecții de tutoriale pentru începători. Cea mai apreciată colecție Python a comunității, Foadsf/NXOpen_Python_tutorials, are 104 stele și 13 fork-uri, ultima actualizare la 19 februarie 2026 (consultat la 18 august 2026). Acesta este întregul semnal public pentru o suprafață de API cu câteva mii de clase — și totodată motivul pentru care asistenții de cod se descurcă vizibil mai bine cu varianta Python decât cu cea C#.
Ambele limbaje se adresează aceleiași API. NX Open oferă legături pentru C++, C# și VB.NET, Java și Python, iar tot ce puteți face interactiv în NX puteți face din cod în oricare dintre ele. Diferențele care contează stau în jurul codului: licențe, semnare, implementare, depanare și cine din echipă mai poate schimba ceva peste doi ani.
NXOpen Python vs. C#: nouă criterii care chiar diferă
Ignorați comparațiile de sintaxă. Acestea sunt criteriile care schimbă rezultatele proiectelor, pe baza NX 2506 — versiunea din iunie 2026 pe care Siemens o denumește acum Designcenter, disponibilă general din 23 iunie 2026.
| Criteriu | Python | C# |
|---|---|---|
| Rulează ca journal nesemnat | Da | Da |
| Necesită compilator pe mașina țintă | Nu | Da, pentru a construi add-in-ul |
| Licență de semnare pentru distribuire | Nu pentru journal-uri | Licență Author pentru cod compilat |
| Dialoguri proprii și integrare în ribbon | Fezabil, dar traseul .NET este mai bine documentat | Suport complet Block UI Styler și WinForms |
| Biblioteci terțe | Doar printr-un interpretor extern | NuGet în proiecte compilate; restricționat în journal-uri |
| Performanță pe ansambluri mari | Interpretat — suficient pentru I/O, mai lent în bucle geometrice strânse | Compilat, măsurabil mai rapid |
| Depanare | Fereastra Listing, instrucțiuni print, IDE extern cu efort de configurare | Visual Studio atașat la procesul NX |
| Cine îl poate întreține | Orice inginer care poate citi cod | Un dezvoltator .NET plus o pipeline de build |
| Distribuire | Copiați un fișier .py | Build, semnare, livrare DLL și fișiere de meniu |
Citiți tabelul ca două grupuri, nu ca nouă puncte separate. Rândurile unu până la trei și rândul nouă sunt despre cum ajunge lucrul pe o stație. Rândurile patru, șase și șapte sunt despre cât de departe poate crește. Primul grup îl câștigă clar Python. Pe al doilea îl câștigă C#.
Aceeași automatizare, scrisă de două ori
Iată o sarcină pe care o recunoaște orice echipă de proiectare pe variante: setați o expresie denumită, reconstruiți modelul, raportați rezultatul. Mai întâi în Python, ca journal pe care îl puteți rula direct din Tools → Journal → Play.
import NXOpen
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
# Undo mark first — without it a failed update leaves the part dirty
mark = session.SetUndoMark(NXOpen.Session.MarkVisibility.Visible, "Set width")
width = work_part.Expressions.FindObject("width")
work_part.Expressions.Edit(width, "180")
session.UpdateManager.DoUpdate(mark)
lw.WriteLine(f"width is now {width.RightHandSide}")
if __name__ == "__main__":
main()Aceeași logică în C#. Observați GetUnloadOption la final — codul NX Open gestionat are nevoie de el pentru a-i spune NX când să elibereze assembly-ul, iar omiterea lui este motivul clasic pentru care un DLL reconstruit pare să nu se actualizeze până la repornirea NX.
using NXOpen;
public class Program
{
public static void Main(string[] args)
{
Session session = Session.GetSession();
Part workPart = session.Parts.Work;
ListingWindow lw = session.ListingWindow;
lw.Open();
// Undo mark first — same reason as the Python version
Session.UndoMarkId mark =
session.SetUndoMark(Session.MarkVisibility.Visible, "Set width");
Expression width = (Expression)workPart.Expressions.FindObject("width");
workPart.Expressions.Edit(width, "180");
session.UpdateManager.DoUpdate(mark);
lw.WriteLine("width is now " + width.RightHandSide);
}
// Tells NX when to unload the assembly; omit it and stale code keeps running
public static int GetUnloadOption(string dummy)
{
return (int)Session.LibraryUnloadOption.Immediately;
}
}Paisprezece linii față de douăzeci și șase, iar cele douăsprezece în plus sunt ceremonie, nu logică. Diferența rămâne aproximativ constantă indiferent cât de mare devine automatizarea, motiv pentru care argumentul numărului de linii este cel mai slab din întreaga comparație — și motivul pentru care nu am recomanda o decizie bazată pe el.
Licențierea și implementarea decid mai mult decât sintaxa
Aceasta este secțiunea care decide majoritatea proiectelor și cea despre care se discută cel mai puțin în tutoriale.
Atât codul Python, cât și cel .NET pot rula ca journal-uri fără licență de dezvoltator. Acesta este avantajul discret: un inginer înregistrează un journal, dumneavoastră îl modificați și rulează pe stația lui chiar în această după-amiază. C, C++ și Java nu beneficiază de asta — compilarea și rularea lor necesită o licență de dezvoltator.
Journal-urile vin cu două limite dure. Trebuie să existe într-un singur fișier și nu pot referi biblioteci în afara celor permise de NX — NXOpen.dll, NXOpen.Utilities.dll, NXOpenUI.dll, NXOpen.UF.dll și o scurtă listă de assembly-uri .NET de bază. În momentul în care aveți nevoie de o structură reală de proiect sau de o dependență externă, compilați.
Iar compilarea schimbă situația licenței. Codul .NET compilat trebuie semnat cu licența Author înainte ca NX să îl execute. Aceasta este o discuție de achiziții, nu una tehnică, și merită purtată cu distribuitorul Siemens înainte de fixarea arhitecturii, nu după — condițiile de licențiere variază în funcție de contract și de regiune.
Încă două detalii de implementare din versiunile actuale. NX 2412 necesită .NET Framework 4.8 pe mașină pentru a executa aplicații .NET proprii și pentru a reda journal-uri .NET. Odată cu NX 2506, Siemens documentează trecerea Microsoft de la .NET Framework la .NET (Core), versiunea certificată fiind indicată în Programming Tools Product Notes — fixați deci framework-ul țintă la ce spun notele pentru versiunea dumneavoastră exactă, nu la ce propune implicit Visual Studio.
În privința Python, interpretorul livrat în NX este intenționat minimal. Dacă aveți nevoie de numpy, pandas sau orice altceva din PyPI, indicați NX către o distribuție instalată separat prin UGII_PYTHON_LIBRARY_DIR și UGII_PYTHONPATH. Funcționează și devine o dependență reală pe care trebuie să o gestionați pe fiecare stație — ceea ce anulează discret o parte din avantajul de implementare al Python. Verificați versiunea pe care o rulați efectiv înainte de a dezvolta pentru ea:
import sys, NXOpen
session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()
lw.WriteLine(sys.version) # the shipped version changes between NX releasesVreți să aprofundați? Ce fac bine și ce greșesc modelele lingvistice când scriu acest cod — și bucla de verificare care ține journal-urile generate departe de stațiile de producție — se află în ghidul nostru practic despre generarea de cod NX Open.
Unde câștigă fiecare
Alegeți Python pentru journal-uri, explorare, procesare în lot, actualizări de desene și PMI, extragere de date și orice va fi întreținut de o echipă mică de inginerie. Cea mai mare parte a muncii de programare NX pe care o livrăm începe aici, dintr-un motiv mai important decât toate celelalte: pe mașina țintă nu este nevoie de compilator. Când ținta se află într-un mediu validat sau într-o rețea de apărare izolată (air-gapped) unde instalarea unui set de instrumente înseamnă o cerere de schimbare, acest lucru încetează să fie o comoditate și devine factorul decisiv.
Alegeți C# atunci când automatizarea are nevoie de un dialog pe care inginerii îl folosesc zilnic, când trebuie să se integreze într-o infrastructură .NET existentă cu biblioteci comune și pipeline CI, când rulați bucle geometrice strânse peste ansambluri mari sau când vreți să o livrați ca artefact compilat, nu ca sursă lizibilă. Instrumentele de tip configurator care generează variante dintr-o specificație a clientului ajung de obicei aici, odată ce au utilizatori reali.
Recomandarea noastră clară: realizați prototipul în Python, indiferent de situație. Puneți la punct apelurile de API acolo unde bucla de feedback durează secunde și portați în C# doar dacă criteriile de mai sus o impun. Portarea unui journal funcțional de 200 de linii este muncă de o zi. Descoperirea, după trei săptămâni de C#, că API-ul nu face ce ați presupus, nu este.
Tiparul pe care l-am contesta este cel în care o echipă alege C# din prima zi pentru că pare mai profesionist, apoi petrece proiectul luptându-se cu infrastructura de build și de semnare pentru o automatizare pe care patru oameni o rulează de două ori pe lună.
Ce să verificați înainte de a vă decide
Cinci întrebări, în ordinea în care de obicei decid:
- Are nevoie de un dialog? Unul real, cu câmpuri și validare, nu o fereastră Listing. Da → C#.
- Cine îl întreține peste doi ani? Dacă răspunsul este “echipa de proiectare”, atunci Python. Dacă este “grupul nostru software”, atunci oricare.
- Unde rulează? Stațiile blocate, validate sau offline favorizează journal-urile Python — nimic de instalat, nimic de semnat.
- Atinge ansambluri mari într-o buclă? Măsurați un prototip Python înainte de a presupune C#. Majoritatea automatizărilor sunt limitate de I/O pe fișiere și pe operații Teamcenter, nu de procesor.
- Aveți licența Author? Dacă nu și achizițiile sunt lente, doar acest lucru poate decide întrebarea pentru următoarele șase luni.
Dacă primele patru răspunsuri indică într-o direcție, iar al cincilea în alta, urmați-l pe al cincilea. Licențele sunt constrângerea în jurul căreia nu puteți proiecta.
Întrebări frecvente
Este NXOpen Python mai lent decât C#?
Da, dar de obicei nu acolo unde contează. C# este compilat și câștigă la bucle geometrice strânse și la parcurgerea ansamblurilor mari. Majoritatea automatizărilor reale își petrec timpul cu I/O pe fișiere, cu accesări Teamcenter și cu actualizări de model, unde ambele limbaje așteaptă aceleași operații NX. Măsurați sarcina reală înainte de a trata performanța drept criteriu decisiv.
Am nevoie de o licență pentru a rula NXOpen Python sau C#?
Journal-urile în Python sau .NET rulează fără licență de dezvoltator, motiv pentru care sunt cea mai rapidă cale către ceva funcțional. Codul .NET compilat este diferit: trebuie semnat cu licența Author înainte ca NX să îl execute, iar C++ sau Java au nevoie de o licență de dezvoltator pentru a fi compilate și rulate. Confirmați condițiile exacte cu distribuitorul dumneavoastră Siemens, deoarece variază în funcție de contract.
Cât costă mutarea unui journal Python într-un add-in C# compilat?
Pentru un journal de sine stătător de câteva sute de linii, socotiți una până la trei zile de portare plus configurarea unei pipeline de build și de semnare — pipeline-ul este partea pe care echipele o subestimează. Apelurile de API se traduc aproape unu la unu; efortul stă în structura proiectului, GetUnloadOption, implementare și integrarea în meniuri. Dacă licența Author nu există deja, achiziția va dura mai mult decât codul.
Pot folosi numpy sau pandas într-un journal NXOpen Python?
Nu cu interpretorul livrat în NX, care este intenționat minimal. Instalați o distribuție Python separată, de versiune potrivită, și indicați NX către ea prin variabilele de mediu UGII_PYTHON_LIBRARY_DIR și UGII_PYTHONPATH . Funcționează bine, dar devine o dependență pe care trebuie să o întrețineți pe fiecare stație care rulează automatizarea.
NXOpen Python vs. C# — ce ar trebui să învețe mai întâi o echipă nouă?
Python, în aproape toate cazurile. Journal-urile înregistrate vă oferă cod funcțional de modificat din prima zi, bucla de feedback durează secunde în loc de un ciclu de build, iar exemplele publice existente sunt majoritar în Python. Treceți la C# atunci când o cerință concretă o impune — un dialog, o infrastructură .NET, o limită de performanță.
Pasul următor
inteliScience construiește automatizări NX în ambele limbaje, de la journal-uri Python individuale până la add-in-uri C# semnate, cu ingineri seniori care livrează din România, cu doar o oră înaintea clienților noștri din DACH. Dacă vă aflați în fața acestei decizii cu o automatizare reală în spate, o discuție scurtă economisește de obicei mai mult timp decât încă o săptămână de evaluare.
