Automatizare de proiectare NX & cod vechi
Cea mai bună automatizare a dumneavoastră a scris-o cineva care a plecat în 2019. De atunci nimeni nu a îndrăznit să o atingă.
Aproape orice atelier NX cu istorie le are: journal-urile VB care completează indicatoarele, macrourile C# NXOpen care generează carcasele standard, uneori un program GRIP care a supraviețuit discret la trei generații de CAD de pe vremea Unigraphics. Cândva au fost avantajul de productivitate al departamentului. Apoi autorul a plecat, NX a continuat să scoată versiuni, iar astăzi automatizarea rulează “cumva” — nedocumentată, netestată, pe o versiune NX pe care nu îndrăzniți să o actualizați, făcând ceva ce nimeni nu poate explica pe deplin.
Această stare are un preț pe care îl plătiți de două ori. O dată în frică: fiecare upgrade NX devine un pariu împotriva propriilor dumneavoastră instrumente, așa că upgrade-urile se amână, iar întreaga instalare îmbătrânește. Și o dată în pierdere: logica de proiectare codificată în acel macro — cunoaștere inginerească reală, câștigată greu — este la un apel de API stricat distanță de a dispărea.
Exact acest gol nu îl ating copiloții de la Siemens: asistă generic în interiorul NX, dar nu vă cunosc codul propriu, API-urile nedocumentate sau logica fabricii. Noi facem asta ca meserie — iar modelele lingvistice mari au schimbat fundamental economia acestei munci. Arheologia de cod care cerea săptămâni de reverse engineering durează acum zile: înțelegere, portare pe API-uri NXOpen suportate, testare pe modele reale. Iar pe aceeași fundație construim automatizarea nouă pentru care nu ați avut niciodată capacitate.
// Automatizare orfană, în cifre
Upgrade-uri înghețate, cunoaștere ținută ostatică
Întrebați un administrator NX de ce instalarea este încă cu două versiuni în urmă și undeva în răspuns veți găsi un macro. Nu sistemul CAD, nu utilizatorii — automatizarea proprie pe care nimeni nu o poate testa în siguranță, pentru că nimeni nu știe exact ce face. Așa că upgrade-ul așteaptă, apoi mai așteaptă o dată, iar distanța dintre instalarea dumneavoastră și NX-ul curent crește: funcții lipsă pe care concurenții le folosesc, patch-uri de securitate neaplicate, ferestre de suport care se închid.
Problema mai profundă este ce conține acel cod. Un macro care generează corect componentele dumneavoastră standard nu este doar un instrument — este forma executabilă a unor decizii de proiectare: ce distanțe, ce logică de denumire, ce convenții de desen. Când autorul a plecat, departamentul a pierdut capacitatea de a-l modifica; când se strică definitiv, pierde însăși cunoașterea. O rescriere de la zero înseamnă să rededuci reguli care fuseseră deja rezolvate o dată.
Ieșirea nu este nici “să nu-l atingem niciodată”, nici “să rescriem tot”. Este salvare sistematică: să faci codul din nou inteligibil, să documentezi ce face de fapt, să-l portezi pe API-uri NXOpen suportate, să-l pui sub control de versiune și teste — iar apoi, pe această fundație sănătoasă, să-l extinzi. Acum doi ani era un proiect de lux. Cu asistență LLM care citește, redactează și traduce, în timp ce inginerii verifică și validează, este acum muncă de rutină cu preț fix.
// Salvarea în practică — aceeași rutină, înainte și după
Sub M3() Dim s As Session = Session.GetSession() Dim wp As Part = s.Parts.Work ' fără comentarii, urmează numere magice Dim h As Double = 12.5 * f1 + 3 Call DoIt(wp, h, 4, True, False, 2) uf.Modl.CreateFixedDplane(...) ' old UF callEnd Sub
/// Generează semifabricatul de flanșă pentru/// familia de carcase H3. Regula de înălțime conform/// standardului intern: h = 12,5·sizeFactor + 3.public void CreateFlangeBlank(Part work, H3Config cfg){ var height = FlangeRules.Height(cfg); FlangeRules.CreateDatum(work, cfg); // via DatumPlaneBuilder}
Salvăm. Construim. Împuternicim.
Oferta are trei straturi care se construiesc unul pe altul — majoritatea clienților încep cu Salvarea, pentru că acolo stă frica, și folosesc apoi fundația sănătoasă ca să construiască ce nu a fost niciodată posibil:
Cod orfan, din nou sub control
Inventarul peisajului dumneavoastră de macro-uri — ce există, ce rulează, de ce depinde activitatea. Analiza asistată de LLM arată ce face de fapt fiecare rutină (verificat de ingineri pe modele reale), apoi rutinele critice sunt portate pe API-uri NXOpen suportate, puse sub control de versiune și testate. Următorul upgrade NX nu mai este un joc de noroc.
Automatizare nouă, în ritm de LLM
Automatizarea modelării, derivarea desenelor, procesarea în lot, fluxuri integrate cu Teamcenter — descrise în limbajul dumneavoastră, redactate de LLM, dezvoltate și testate de noi. Dezvoltarea care înainte se excludea singură prin preț încape acum în bugete de firmă mijlocie, iar totul se livrează determinist: aceeași intrare produce de fiecare dată același rezultat eliberat.
Echipa dumneavoastră păstrează cheile
Rostul salvării este ca situația să nu se mai repete niciodată. Codul este versionat, power userii dumneavoastră învață să îl citească și să îl extindă cu asistență LLM — o competență care nu mai necesită un dezvoltator dedicat —, iar ghidurile de mentenanță definesc cum sunt testate și aprobate modificările. Rămânem disponibili pentru cazurile dificile; refuzăm să devenim următorul single point of failure.
Când se justifică asta?
Sunteți un candidat dacă majoritatea punctelor de mai jos vă sună cunoscut:
- Există automatizare NX proprie — journal-uri, macrouri NXOpen, reguli Knowledge Fusion — iar autorii ei au plecat sau sunt pe cale să plece.
- Upgrade-urile NX sunt amânate de frică din cauza codului propriu, iar instalarea îmbătrânește odată cu ele.
- Nimeni nu poate spune ce fac exact macrourile critice — nu există documentație, nu există teste, nu există control de versiune.
- Munca repetitivă de modelare și de desenare se face manual pentru că automatizarea nouă a fost întotdeauna prea scumpă ca să fie comandată.
- Familiile de produse bogate în variante cer automatizare — exact cazul pe care oferta noastră de proiectare pe variante îl acoperă de la un capăt la altul.
- Folosiți Siemens NX (orice versiune recentă — tocmai despre asta e vorba) și vreți instrumente pe puncte de extensie suportate.
Stack-ul nostru de automatizare NX
Dezvoltare NX full-stack pe tehnologiile pe care rulează automatizarea dumneavoastră — vechi și noi.
Înainte și după: ziua upgrade-ului NX
Cel mai clar test pentru sănătatea automatizării dumneavoastră este ziua în care apare o versiune NX nouă. Iată cum arată acea zi de o parte și de alta a schimbării:
Înainte — pariul
- Upgrade amânat de două ori — „din cauza macrourilor“
- Plan de test: rulezi tot o dată și speri
- Journal-ul pentru indicator eșuează în tăcere — descoperit de un client
- Singurul coleg care cunoaște codul „cam așa“ este în concediu
- Rollback. Următoarea încercare: la anul
După — rutina
- Automatizarea rulează pe versiunea nouă într-un mediu de test — înainte de rollout
- Suita de teste raportează două API-uri depreciate — rezolvate într-o după-amiază
- Fiecare rutină documentată — niciun coleg nu este punct unic de eșec
- Upgrade-ul iese la termen — utilizatorii primesc NX curent, IT-ul își primește weekendul
- Macrourile sunt din nou un activ — și o fundație pe care se poate construi
De ce inteliScience — și cum folosim AI fără să pariem
Această pagină descrie disciplina noastră de bază. Construim zilnic customizări NX și Teamcenter pe punctele de extensie suportate de Siemens — aceeași filosofie sigură la upgrade din spatele practicii noastre de programare Teamcenter se aplică fiecărei linii de NXOpen pe care o atingem. Și vorbim ambele limbi de care are nevoie treaba: codul și proiectarea. Un inginer care nu a stat niciodată lângă un proiectant va porta sintaxa macroului dumneavoastră și îi va rata intenția; oamenii noștri recunosc că numărul magic 12,5 este un standard intern, nu un capriciu.
La AI, împărțirea muncii este strictă, pentru că instrumentele CAD de producție nu sunt un loc pentru improvizație. LLM-urile citesc, redactează, traduc și explică — sunt spectaculoase la digerarea unei baze de cod nedocumentate și la propunerea unui echivalent modern. Inginerii verifică, testează și eliberează — fiecare rutină portată este validată pe modele de referință reale înainte să ajungă măcar în apropierea producției, iar totul se livrează determinist și sub control de versiune. LLM-ul nu rulează în NX-ul dumneavoastră; rezultatul lui rulează, după ce și-a câștigat dreptul.
O notă onestă despre GRIP și despre ce e cu adevărat vechi: nu tot se poate porta unu la unu, iar a pretinde altceva ar însemna să vă vindem arheologie drept magie. Acolo unde migrarea directă nu are sens, extragem logica — regulile pe care le codifică programul — și o reconstruim curat pe NXOpen. Cunoașterea supraviețuiește; datoria tehnică nu.
Preț fix — fără tarife pe zi, fără surprize
Pilot de salvare a automatizării
- Inventar complet al peisajului dumneavoastră de automatizare — ce există, ce rulează, ce este critic
- Analiza asistată de LLM a principalelor rutine — verificată de ingineri
- Cel mai critic macro pentru afacere, modernizat, portat și testat pe NX curent
- Control de versiune, configurație de test și proces de eliberare, stabilite ca șablon
- Foaie de parcurs pentru modernizarea restului — prioritizată după riscul pentru afacere
2–3 săptămâni · pe instalarea dumneavoastră NX · tot codul, documentația și roadmap-ul vă aparțin, indiferent ce decideți după.
Pentru comparație
Costul stării înghețate
- Rescrierea de la zero a macrourilor critice când se strică definitiv — sub presiunea timpului
- Ani de funcții și corecții NX pe care utilizatorii dumneavoastră nu le primesc cât timp upgrade-urile așteaptă
- Și riscul neinclus în preț: cunoaștere de proiectare care există doar sub formă de cod ilizibil
Întrebări frecvente
Cod generat de LLM în instrumente CAD de producție — este sigur?
Încă rulăm programe GRIP. Chiar pot fi migrate?
Autorul macrourilor noastre este încă aici. Chiar avem nevoie de asta?
Pot propriii noștri oameni să întrețină ulterior automatizarea?
Nu face asta oricum copilotul NX de la Siemens?
Cum se raportează asta la oferta dumneavoastră de proiectare pe variante?
Undeva în NX-ul dumneavoastră rulează un macro pe care nimeni nu îl înțelege. Hai să-l facem din nou al dumneavoastră.
Trimiteți-ne cea mai înfricoșătoare rutină a dumneavoastră — cea pe care nimeni nu îndrăznește să o atingă — și vă arătăm ce găsește în ea analiza asistată de LLM, verificată de un inginer care vorbește NXOpen.
Discutați cu un inginer de automatizare NXSuntem întotdeauna aici pentru a vă sprijini - contactați-ne cu întrebările dvs. și vă vom ghida la fiecare pas.
- Telefon
- +40 774 463 429
- Locația noastră
- Str. Ploiești 9, 400157
Cluj-Napoca, România - info@inteliscience.net
- inteliScience pe LinkedIn
- YouTube
- inteliScience pe YouTube