Usunąłem nawias "}" w linii 5301 z poziomu pliku tcl, ale błąd nadal występuje, tym razem linijkę wcześniej w 5300.

Nawias o którym wspomniałeś jest dodawany z automatu przez postbuilder (czerwona strzałka na dole zdjęcia), więc na dłuższą metę przy dalszej rozbudowie posta, każdy "save" wiązałby się z ręcznym usuwaniem omawianego nawiasu, o ile ten trick usunąłby pojawianie się błędu. Próbowałem również z nawiasami przy MOM helix_move oraz uplevel, ale krzaczyło nadal. Szukam dalej...

Skopiowałem to co zamieściłeś, sprawdziłem i jak się okazuje gdzieś przedobrzyłem ponieważ przy generowaniu wyrzuca mi błąd:




w pliku TCL wygląda to tak:



Ogarnę jeszcze plik pui do sim08 z wersji NX8.0 i w nim poszperam. Niemniej jednak "FTW" dzięki za odpowiedź!

nxcam za odpowiedź!

Jakiś pomysł jak to poprawić? Rozumiem, że problem leży w składni procedury PB_CMD_init_helix i rozwiązaniem jest dopisanie wymuszenia wyjazdu do poziomu bezpiecznego po zakończeniu pierwszej helisy? Jeśli tak, w miarę możliwości proszę o udostępnienie składni do dopisania. Próbowałem znaleźć rozwiązanie w postach zamieszczonych w GTAC, ale wszystkie dostępne na sterowanie HH iTNC 530 generują helisę interpolowaną liniowo, a nie kołowo jaką chcę uzyskać. Próbowałem również zaimportować procedurę set_helix_move zastępując pb_cmd_helix, ale wyrzuca mi błąd w trakcie generowania G_kodu i jak dotąd nie ogarnąłem gdzie leży przyczyna. Any ideas?

Witam,

podstawowe informacje o problemie:

NX 10
Operacja - Hole Milling
Maszyna - HERMLE C400 (5axis table-table)
Sterownik - HEIDENHAIN iTNC 530 HSCI

kolejny problem z postprocesorem który zakupiła firma w której pracuję dał o sobie znać dosyć boleśnie. Z mojego niedopatrzenia w trakcie frezowania otworu przelotowego operacją Hole milling narzędzie zakaleczyło stół obrotowy w maszynie... Szczęście w nieszczęściu było takie, że średnica otworu pokryła się z średnicą otworu centrującego w stole nie uszkadzając jego pasowanego wymiaru, a jedynie kalecząc dno. Oczywiście nakrętka + tulejka oprawki ER32 i narzędzie na złom. Po wnikliwym sprawdzeni programu w NX CAM wyszło, że jest poprawny - bezkolizyjny. Gdy w CIMCO odpaliłem G-kod zobaczyłem, że ścieżki po spirali ułożyły się poziomami. Poniżej zamieszczam print screen z przykładowego detalu, w którym jest identyczny problem.


Po przegenerowaniu przez postprocesor ścieżka w CIMCO wygląda jak poniżej. Podzieliła się na dwa poziomy, z których drugi frezował podkład aluminiowy a następnie stół.


Do tej pory stworzyłem kilka pomyślnie działających postów na maszyny 3axis. Od kilku miesięcy odbudowuję postprocesor 5osi na podstawie postprocesora sim08_mill_5ax dodanego do NX. Pominę już fakt, że ten który zakupiła firma za kilkanaście tys PLN bazuje w 100% na sim08_mill_5ax a wprowadzono jedynie kilka zmian. Przesiedziałm już nad tą kwestą kilkanaście godzin, ale efekt nadal mizerny. Poniżej zamieszczam zdjęcie z składni ruchu helikalnego z mojego posta.



Problem polega na tym, że narzędzie po dejechaniu do końca pierwszej helisy nie powraca na w osi Z do płaszczyzny bezpiecznej, aby ponownie zacząć obróbkę od górnej płaszczyzny otworu, ale traktuje koniec I helisy jako początek II. Moim zdaniem brakuje wymuszenia wyjazdu do płaszczyzny bezpiecznej. Dziwna sprawa, którą wyhaczyłem - w G-code brakuje wiersza nr 120, w pliku *review.out (Review Tool) podobnie, brakuje wartości do wyjazdu w osi Z do płaszczyzny bezpiecznej.



Po przegenerowaniu omawianej operacji przez post na Fanuc 3axis wszystko działa poprawnie. Porównywałem pliki z narzędzia Review Tool ale moja biegłość w zmiennych z NX jak również programowaniu w TCL jeszcze kuleje. Zamieszczę plik z Review Tool oraz G-code, może znawcy tematu coś znajdą. Dzięki za wszelką pomoc i wskazówki!