Fanuc jako punkt odniesienia – co naprawdę narzuca sterowanie
Mit „Fanuc jak każdy inny” i realne różnice
Wielu programistów przyjmuje założenie, że „Fanuc to standard, więc każdy postprocesor Fanuc będzie działał”. W praktyce dwa centra z Fanuc 0i mogą zachowywać się inaczej, jeśli różnią się parametrami, opcjami i nakładkami producenta. Postprocesor, który działa na jednej maszynie, na drugiej może generować drobne, ale kosztowne problemy: brak korekcji, inne zachowanie cykli stałych, niespójne makra.
Sterowanie Fanuc definiuje szkielet: dopuszczalne adresy, format liczb, logikę modalności G-kodów, mechanizm korekcji i obsługę makr. Producent maszyny dorzuca własne cykle, przypisania M-kodów, czasem zmienia parametry dotyczące np. zaokrąglania, aktywnych płaszczyzn czy zachowania przy pauzach. Postprocesor musi zgrać się właśnie z tym duetem – nie z „książkowym Fanukiem”.
Mit „postprocesor Fanuc z CAM zawsze będzie pasował” rozjeżdża się z rzeczywistością w kilku typowych miejscach: cykle wiercenia Fanuc vs cykle OEM, korekcja promienia G41/G42 w innym trybie, brak obsługi makr użytkownika (#100+), inny format czasu lub posuwu (G94/G95). Z tego powodu gotowy post „Fanuc 3X Mill” z CAM-a traktuje się raczej jako szablon wyjściowy niż produkt finalny. Prawdziwe przygotowanie pod konkretną maszynę zaczyna się od analizy parametrów sterowania i instrukcji producenta obrabiarki.
Rodziny sterowań Fanuc a G‑code z CAM
W zakładach produkcyjnych najczęściej spotyka się sterowania Fanuc 0i (różne generacje), starsze serie 16/18/21, a w nowszych i bardziej rozbudowanych centrach – 30i/31i. Do tego dochodzą wersje specjalne opisane nazwą producenta maszyny, np. „Mazak with Fanuc”, „Doosan Fanuc i-Series”, gdzie część funkcji jest mocno „obudowana” softkeyami i makrami OEM.
Na poziomie G‑code podstawy są podobne: G0/G1, G2/G3, G81–G89, M03/M05, T/H/D. Różnice zaczynają się na szczegółach:
- obsługa formatów liczbowych (ilość miejsc po przecinku, zakresy, współpraca z parametrami sterowania),
- dostępność standardowych cykli stałych (np. G73, G83, G84) i ich dokładna semantyka,
- makra użytkownika (zmienne #100+), możliwość wywołania przez G65/G66, zakres numerów O dla makr,
- opcje wysokiej prędkości (AI Contour, G5.1/G08), 5-osi, TCP, sond i paletyzacji.
Postprocesor musi być świadomy, na jaką rodzinę sterowań jest przygotowywany. Przykład: ten sam program z ruchami w 4 osiach może działać bez błędu na 31i z aktywnym TCP i wywalać alarmy na starym 0i bez tej opcji. Dlatego konfiguracja postprocesora pod Fanuc powinna zaczynać się od zgrania listy opcjonalnych funkcji, a dopiero potem z formatem G‑code.
Fanuc, maszyna i postprocesor jako jeden system
Stabilny, powtarzalny postprocesor pod Fanuc powstaje dopiero wtedy, gdy uwzględni się współpracę trzech elementów:
- Sterowanie Fanuc – definiuje język (G/M, modalność, format liczb, makra).
- Maszyna – dodaje mechanikę (zakresy osi, konfigurację, głowice kątowe, magazyny, sondy) i własne cykle OEM.
- Postprocesor CAM – tłumaczy ścieżki CAM na konkretny dialekt G‑code, zgodny ze sterowaniem i „kulturą” firmy.
Ignorowanie któregoś z tych poziomów prowadzi do typowych niespodzianek: np. post generuje G81, a producent maszyny zaleca własne makro wiercenia z dynamicznym posuwem; albo CAM wypuszcza G41 z korekcją promienia, ale operatorzy pracują od lat z trajektorią „bez korekcji” i wpisują offsety ręcznie. Świadomie przygotowany postprocesor pod Fanuc uwzględnia zarówno twarde ograniczenia sterowania, jak i przyzwyczajenia oraz standardy warsztatu.
Fundamenty dobrego postprocesora pod Fanuc
Od wymagań firmy i maszyny do specyfikacji postprocesora
Bez spisanych wymagań postprocesor zwykle staje się zlepkiem doraźnych poprawek. Zamiast tego warto zacząć od krótkiej, ale konkretnej specyfikacji. Pierwszy krok to lista sterowań i maszyn: Fanuc 0i-T na tokarkach, 0i-M/31i na centrach 3- i 5-osiowych, ewentualnie starsze 16/18/21. Do tego typy maszyn: tokarka 2-osiowa, z osią Y, z przeciwwrzecionem, centra pionowe, poziome, stoły uchylne, głowice kątowe, magazyny palet.
Następnie spisuje się, jakie tryby i funkcje mają być obsługiwane z CAM, a co zostaje w rękach operatora. Typowy podział wygląda tak:
- CAM + post: wszystkie ruchy obróbcze, większość przejazdów, zmiany narzędzi, podstawowe cykle wiercenia, korekcje długości i promienia, standardowe powroty na poziomy bezpieczeństwa.
- Operator / procedury warsztatowe: mocowanie, bazowanie pierwszej sztuki, uruchomienie sondy ustawiającej, sprawdzenie pierwszego przejścia na podwyższonym Z, specyficzne „obejścia” maszyn.
Na tej podstawie tworzy się specyfikację postprocesora: jakie G-kody i M-kody musi generować, jakie cykle ma wspierać, czy używa makr użytkownika, jak wygląda standardowy nagłówek, jak zachowują się powroty na koniec narzędzia i programu. Taki dokument, nawet w formie jednej strony A4, drastycznie przyspiesza dalszą konfigurację i testy.
Standard firmowy i konsekwencje dla CAM
Standard firmowy kodu NC pod Fanuc często istnieje nieformalnie: „u nas zawsze jest G54”, „program zaczyna się od O5000” itd. Warto to skodyfikować i przełożyć na ustawienia postprocesora. Kluczowe elementy to:
- nazewnictwo programów (Oxxxx) – zakres numerów na części seryjne, prototypy, makra użytkownika, procedury z sondą,
- struktura nagłówka – dane części, numer rysunku, materiał, baza, uchwyt, wersja programu, autor, data,
- komentarze i sekcje – logiczny podział programu na mocowanie, zgrubna, wykańczająca, gwinty, kontrola,
- numeracja bloków – z N lub bez, inkrementacja (N10, N20) lub bez numerów w ruchach interpolowanych.
Postprocesor powinien generować ten standard automatycznie, aby operator nie musiał ręcznie dopisywać na maszynie nagłówków, sekcji i komentarzy typu „T1 – frez palcowy fi10, zgrubne”. W nowoczesnych CAM-ach większość informacji (materiał, numer zlecenia, opis operacji) jest dostępna i można ją wstrzyknąć w komentarze i nagłówek.
Bezpieczeństwo: bazy, poziomy i płaszczyzny
Format G‑code Fanuc pozwala na wiele skrótów, ale to właśnie „inteligentne skróty” generują potem zderzenia. W dobrze przygotowanym postprocesorze bezpieczeństwo jest twardszym priorytetem niż minimalizacja liczby linii. Kilka zasad praktycznych:
- Start programu: reset modalności – np. G17 G21 G40 G49 G80 G90, odwołanie G94/G95 zgodnie ze standardem firmy, aktywacja właściwego G54–G59.
- Poziom bezpieczeństwa: każde przejście między obszarami obróbki powinno przebiegać na zdefiniowanym Z-safe, przypisanym do operacji w CAM, i wygenerowanym w postprocesorze przed ruchem XY.
- Płaszczyzny G17/G18/G19: postprocesor powinien jawnie aktywować płaszczyznę przed interpolacją łukową, zamiast zakładać, że sterowanie „pamięta poprzednie ustawienie”.
Mit, że „sterowanie samo pilnuje bezpieczeństwa, bo jest G28” jest prosty do obalenia: kilka błędnych nawyków (np. ruch G28 Z0 bez wcześniejszego podniesienia Z) i stół pokazuje, jak wygląda kolizja w realu. Postprocesor powinien generować bezpieczne sekwencje G28/G30, uwzględniając specyfikę maszyny i ustalony poziom bezpieczeństwa.
Format G‑code pod Fanuc – liczby, adresy, struktura programu
Adresy i konwencja zapisu bloków
Fanuc ma prostą, ale wymagającą dyscypliny składnię. Standardowe adresy to m.in. N (numer bloku), G (funkcja przygotowawcza), X/Y/Z (pozycje liniowe), A/B/C (osie obrotowe), F (posuw), S (obroty), T (numer narzędzia), H (korekcja długości), D (korekcja promienia), M (funkcja pomocnicza). Postprocesor musi zdecydować, jaką kolejność i które adresy generować domyślnie.
Dobra praktyka to stosowanie stałej kolejności, np.: N – G – X/Y/Z – A/B/C – F – S – T – H/D – M – komentarz. Dzięki temu programy są czytelniejsze, łatwiej porównywać różne wersje, a debugowanie staje się szybsze. Część zakładów rezygnuje z numeracji N, aby skrócić linie, ale numeracja bloków (N10, N20…) bardzo pomaga przy opisywaniu błędów i przekazywaniu uwag operator–programista.
Przykładowy blok z sensowną strukturą:
N100 G1 X-25.150 Y40.320 Z-2.000 F300. (ROWKOWANIE BOK PRAWE)
Kluczowe jest to, aby postprocesor nie „mieszał” modalności bez potrzeby: nie ma sensu powtarzać F lub S w każdym bloku, jeśli nie zmieniają się między liniami. Zbyt rozbudowany, modalnie „przegadany” program spowalnia bufor sterowania i zwiększa ryzyko błędów przy ręcznej edycji.
Ustawienia zaokrągleń, jednostek i miejsc po przecinku
Format liczb to jedno z najważniejszych ustawień w postprocesorze pod Fanuc. Typowe ustawienia:
- jednostki: milimetry (G21) lub cale (G20),
- liczba miejsc po przecinku dla osi liniowych: 3 lub 4,
- dla osi obrotowych: 3 miejsc (np. A45.123),
- posuwy: 1–3 miejsc po przecinku, zależnie od skali (F150., F0.05).
Mit, że „sterowanie samo zrozumie format” jest powodem wielu subtelnych problemów: zbyt agresywne zaokrąglanie (np. do 2 miejsc) potrafi zepsuć płynność ścieżek HSM, spłaszczyć łuki i spowodować nienaturalne zatrzymania. Z kolei zbyt wiele miejsc po przecinku może przekraczać możliwości sterowania i generować alarmy formatu.
Konieczne jest sprawdzenie parametrów sterowania Fanuc: ile miejsc po przecinku może przyjąć dana oś, jaki jest format wewnętrzny (np. ustawienia „input unit”). Na tej podstawie ustawia się w postprocesorze reguły zaokrągleń, tak aby generowany G‑code był:
- wystarczająco dokładny dla obróbki (szczególnie przy HSM i 5D),
- akceptowalny przez sterowanie (bez alarmów i obcięć),
- nieprzeładowany niepotrzebną liczbą znaków.
Jednostki, posuwy i format czasu
Postprocesor pod Fanuc musi jasno określić, w jakich jednostkach pracuje program i jak są interpretowane posuwy. Kluczowe decyzje:
- G21 vs G20 – jawna aktywacja jednostek na początku programu, nawet jeśli w parametrach sterowania ustawiono domyślnie mm.
- G94/G95 – posuw na minutę (G94) lub na obrót (G95). Tokarki często używają G95 przy toczeniu, ale cykle gwintowania mają już własną logikę.
- Format czasu – jeśli postprocesor generuje M-kody zależne od czasu (np. timery chłodziwa czy wyrzutników, o ile takie istnieją), musi uwzględnić format i możliwości sterowania.
W postprocesorze warto przewidzieć możliwość przełączania między G94 i G95 na poziomie operacji CAM, zamiast globalnie w całym programie. Dzięki temu cykle gwintowania, toczenia z posuwem na obrót i gwintowania z głowicą synchroniczną można obsłużyć jednym, spójnym szablonem.
Rola komentarzy i wpływ na wydajność
Fanuc obsługuje komentarze w nawiasach okrągłych, np. (FREZ FI10 ZGRUBNY). Komentarze są nieocenione dla operatora, ale zbyt „rozmowny” postprocesor potrafi wyraźnie spowolnić transmisję i bufor, szczególnie przy DNC i długich programach HSM.
Najlepsza praktyka to stosowanie komentarzy tam, gdzie wnoszą realną wartość:
- początek programu – informacje o części, materiale, bazie,
- początek narzędzia – opis narzędzia, przeznaczenie (zgrubna/wykańczająca),
- przejścia między sekcjami – „POCZĄTEK OBRÓBKI OTWORÓW”, „KONTROLA WYMIARU X50”.
Struktura programu głównego i podprogramów
Fanuc daje dużą swobodę w organizacji programów, ale swoboda bez porządku kończy się „makaronem G-kodów”. Postprocesor powinien mieć jasno zdefiniowaną strategię użycia programów głównych, podprogramów i ewentualnych procedur pomocniczych.
Typowy, zdrowy układ na frezarce 3–5-osiowej to:
- program główny – nagłówek, ustawienie baz (G54–G59 lub G54.1 Px), wywołania narzędzi, globalne bezpieczeństwo, kolejność mocowań,
- podprogramy technologiczne – powtarzalne operacje: wzory otworów, kontury na wielu gniazdach, sekwencje w 4D/5D,
- procedury warsztatowe – oddzielne programy O9xxx dla sondy, testów kolizji, rutyn bezpieczeństwa.
Mit, że „Fanuc gorzej chodzi na podprogramach, lepiej lać wszystko w jednym O” bierze się zwykle z chaotycznego użycia M98/M99 i braku kontroli nad adresami L (liczba powtórzeń). Dobrze zrobiony postprocesor generuje wywołania podprogramów w sposób przewidywalny, z parametrycznymi przesunięciami baz lub offsetów.
Przykład czytelnego wywołania podprogramu z powtórzeniami:
O5100 (KORPUS LEWY) ... N300 G54 X0. Y0. N310 M98 P7000 L4 (GNIAZDO POWTARZANE 4 RAZY) ... M30 O7000 (OBRÓBKA GNIAZDA) N10 G0 Z100. N20 G1 Z-12. F200. ... N90 M99
Postprocesor musi pilnować, aby numery Oxxxx nie nachodziły na używane już makra, cykle producenta maszyny czy procedury sondy. W specyfikacji warto zarezerwować np. O1–O4999 na programy CAM, O5000–O7999 na podprogramy i O8000–O8999 na makra producenta, O9000–O9999 na „święte” makra serwisowe i sondę (z blokadą edycji w parametrach).
Organizacja wielu mocowań i baz w jednym programie
W produkcji seryjnej postprocesor pod Fanuc musi sensownie ogarniać sytuacje z wieloma bazami i zamocowaniami w jednym programie. Najczęstsze scenariusze to:
- kilka stron detalu na jednym uchwycie (G54, G55, G56…),
- kilka detali w jednym zamocowaniu (G54 + przesunięcia lub G54.1 P1–P10),
- obróbka z różnych kątów na stole uchylnym (G54 z różnymi G68.2 / cyklami rotacji).
Dobry postprocesor segmentuje program wg baz i mocowań, a nie tylko wg narzędzi. Na ekranie operatora powinny być czytelne sekcje typu:
(MOCOWANIE 1 – BAZA G54 – STRONA A) ... (MOCOWANIE 2 – BAZA G55 – STRONA B)
Rzeczywistość vs mit: „wystarczy zmieniać wartości G54 ręcznie na maszynie, po co komplikować postprocesor”. Ręczne przepisywanie offsetów działa dopóki pracuje jedna zmiana i jeden operator. Przy kilku brygadach i kilkudziesięciu programach ryzyko pomyłki rośnie wykładniczo. Lepiej trzymać się zasady: każdy fizyczny detal na stole ma swoją zdefiniowaną bazę w programie, z komentarzem co gdzie jest.
Fanuc a 4. i 5. oś – rotacje i systemy współrzędnych
Przy maszynach 4D/5D planowanie postprocesora staje się krytyczne. Ten sam Fanuc może pracować z różnymi kinematykami (stół obrotowy, głowica uchylna, stół-stół, głowica-głowica), a producent maszyny narzuca własne konwencje w G54.4, G68.2, cyklach TCP i RTCP.
Podstawowe kwestia to sposób definiowania orientacji obrabianej płaszczyzny:
- proste 4D – indeksacja osi A/B/C (np. A90.) i praca w G17 jak na 3D,
- 5D z RTCP – sterowanie liczy kompensację długości narzędzia w przestrzeni (G43.4 / G43.5 w zależności od opcji),
- rotacja układów – G68 / G68.2 z zadaniem płaszczyzny i punktu obrotu.
Postprocesor musi mieć wbudowany model kinematyki konkretnej maszyny (lub rodzin kinematyk), inaczej pojawi się klasyczny problem: „na symulacji w CAM pięknie, na maszynie wchodzi w stół przy A90”. Symulator CAM liczy geometrię względem czystej matematyki, a sterowanie Fanuc – względem konkretnej implementacji osi obrotowych, punktów zerowych i sposobu liczenia RTCP.
Mit, który regularnie wraca: „jak masz RTCP, to wszystko jedno jak zdefiniujesz długości narzędzi”. Nie jest wszystko jedno. Fanuc w RTCP opiera się właśnie na poprawnych długościach i korekcji H; przekłamana długość powoduje ruchy kompensacyjne w nieoczekiwanych kierunkach i pozornie „niewytłumaczalne” wejścia w detal.
Standardy firmowe i porządek w programach NC
Sam Fanuc narzuca tylko zasady składniowe. To, czy programy będą spójne i czytelne, zależy wyłącznie od standardu przyjętego w zakładzie i od tego, czy postprocesor ten standard egzekwuje automatycznie. Standard firmowy nie powinien żyć tylko w głowie jednego „mistrza CNC”, ale mieć przełożenie na konkretne reguły generowania kodu.
Kluczowe elementy standardu firmowego
Na poziomie praktycznych ustaleń standard obejmuje kilka obszarów. Jeśli nie trafią one do postprocesora, wrócą w postaci ręcznych poprawek na maszynie.
- Schemat nazewnictwa plików i O-numerów – np. numer zlecenia + indeks operacji, zakresy O-numerów rezerwowane pod konkretne typy programów (sztuka seryjna, prototyp, podprogramy),
- szablon nagłówka – stałe pola: nazwa części, numer detalu, rysunek, rewizja, materiał, baza, numer imadła lub uchwytu, autor i data wygenerowania,
- konwencja komentarzy – w jakim formacie opisujemy narzędzia, sekcje, kontrolę wymiarów, przerwy na pomiar,
- schemat przejść między narzędziami – np. zawsze powrót na Z-safe lokalny, potem G28 Z0, potem zmiana narzędzia i aktywacja korekcji.
Postprocesor powinien zawierać te reguły „zaszyte” w skrypcie, tak aby użytkownik CAM nie musiał za każdym razem pamiętać, co w danym zakładzie oznacza T10, jak formatować komentarz narzędzia i od czego zaczyna się blok bezpieczeństwa.
Automatyzacja opisu narzędzi i operacji
Operator nie ma czasu zgadywać, co kryje się pod T7. Dlatego standard firmowy powinien precyzować, jak postprocesor buduje opis narzędzia. Najlepiej, gdy w CAM-ie nazwy narzędzi i operacji są już wprowadzone sensownie, a post tylko przenosi je do G-kodu.
Przykładowy, czytelny opis narzędzia:
N120 T7 M6 (T7 FREZ FI12 R0.5 – ZGRUBNE KONTUR ZEWN.) N130 G0 G90 G54 X0. Y0. S6500 M3 N140 G43 H7 Z100. (DLUGOSC T7 H7)
Postprocesor może łączyć informacje z biblioteki narzędzi CAM (średnica, promień naroża, długość, typ) z opisem operacji („zgrubne”, „wykańczające”, „dno”, „ścianki”) i generować spójne komentarze. Ręczne dopisywanie takich opisów na maszynie prowadzi do klasycznych błędów: zmieniono narzędzie, ale nie zmieniono komentarza, a operator uruchamia program „na pamięć”.
Segmentacja programu na sekcje technologiczne
Program z CAM można rozciąć na logiczne kawałki. Postprocesor powinien umieć rozpoznać typ operacji i wygenerować nagłówki sekcji, bez potrzeby ręcznego wstawiania makr.
Przykładowy układ:
(MOCOWANIE 1 – KORPUS LEWY) (OBRÓBKA ZGRUBNA – FREZOWANIE) ... (OBRÓBKA WYKAŃCZAJĄCA – ŚCIANY ZEW.) ... (OBRÓBKA OTWORÓW – WIERCENIE/GWINTY) ...
Za tą „kosmetyką” stoi konkretna korzyść: gdy pojawia się problem wymiaru lub jakości powierzchni, operator i programista mówią tym samym językiem. Zamiast: „na końcu coś przytarło”, jest: „w sekcji OBRÓBKA WYKAŃCZAJĄCA – ŚCIANY ZEW. narzędzie T5 idzie za nisko na ostatniej warstwie”. Taką strukturę można potem łatwo wykorzystać w raportach czasu cyklu czy analizie OEE.
Polityka użycia cykli stałych vs ścieżki rozwinięte
Wielu użytkowników Fanuca wpada w skrajności: albo wszystko w cyklach G81–G89, albo wszystko „na piechotę” jako G1/G0. Dobry standard firmowy określa, gdzie cykle stałe są korzystne, a gdzie szkodzą przejrzystości lub wydajności.
Sensowne podejście wygląda tak:
- proste wiercenia, pogłębiania, rozwiercania – użycie G81/G82/G83 z jasno zdefiniowanym R, Q, F,
- obróbki złożone (np. łamane dno, stopnie, nietypowe podejścia) – trajektoria rozwinięta z CAM, bez pakowania w cudaczne kombinacje cykli,
- gwintowanie – według możliwości napędu wrzeciona: G84/G74, ewentualnie specjalne cykle producenta,
- wiercenie 5D – z ostrożnym użyciem cykli, jeśli producent maszyny gwarantuje poprawną współpracę z RTCP.
Mit, że „cykle oszczędzają pamięć, więc zawsze są lepsze” przestał być aktualny przy dzisiejszych sterowaniach. Zasób, którego realnie brakuje, to nie kilobajty pamięci, tylko przejrzystość programów i czas uruchomienia pierwszej sztuki. Jeżeli cykl G83 w kombinacji z nietypową geometrią powoduje, że nikt nie rozumie ruchu narzędzia, lepiej generować jawne G1 z kontrolą na ekranie.
Korekcje długości i promienia – spójny model w firmie
Fanuc jest elastyczny: pozwala używać niezależnych tabel korekcji długości (H) i promienia (D), powiązań T–H–D 1:1, ale też egzotycznych układów, gdzie T5 używa H15 i D25. Im bardziej skomplikowany model, tym więcej pola do pomyłek przy przezbrajaniu.
Standard firmowy powinien zamknąć ten temat w kilku jasnych zasadach:
- powiązanie T–H: 1:1 (T7 zawsze z H7) lub kontrolowana wariacja (np. H=100+T dla głowic o stałej długości),
- powiązanie T–D: 1:1 lub osobne zakresy D dla wykończeń (np. D1–D50 zgrubne, D51–D99 wykańczające),
- miejsce korekcji: w kodzie CAM dopuszczamy tylko minimalne offsety (np. korekcja promienia +/-0.2), korekcje większe wykonuje się w procesie przygotowania narzędzia (presetter, pomiar),
- typ kompensacji: stałe użycie G41/G42 z określoną stroną dla typowych konturów, unikanie sytuacji, w których kompensacja „przeskakuje” w połowie ścieżki.
Postprocesor powinien egzekwować te zasady: np. wymuszać T=H, zakazywać generowania G41/G42 bez poprzedzającego ruchu na wejście w kompensację w linii prostej i pilnować, by wyjście z korekcji (G40) było zawsze w bezpiecznym miejscu, najlepiej poza detalem.
Makra użytkownika – kiedy mają sens, a kiedy szkodzą
Fanuc z opcją makr (Macro B) kusi, żeby każdy problem rozwiązać parametrami # i programem O90xx. Makra są potężne, ale łatwo nimi stworzyć „lokalny język programowania”, którego rozumie tylko autor. W kontekście postprocesora trzeba zdecydować: które zachowania przenieść do makr, a które generować explicite z CAM.
Makra mają sens, gdy:
- operacja jest powtarzalna i trudna do odwzorowania w CAM (np. skomplikowane czyszczenie naroży, adaptacyjne podejścia pod konkretną głowicę),
- chcemy oddzielić logikę warsztatową od geometrii (np. makro sondy, makro testu prześwitu),
- producent maszyny dostarcza sprawdzone makra (sonda, kompensacje termiczne, specjalne cykle wiercenia).
Rzeczywistość vs mit: parametr #100 niczym nie różni się od liczby wpisanej na sztywno. Różni się tym, że po roku nikt nie pamięta, skąd pochodzi #100 i co wpływa na jego wartość. Jeżeli postprocesor opiera się o makra, dokumentacja powinna opisywać zarówno interfejs (jak wywołać), jak i założenia (jakie mają być ustawione parametry globalne, jakie offsety baz wykorzystujemy).
Prosty, kontrolowany przykład użycia makra z CAM:
Przykładowe makro pod postprocesor – sonda i ustawianie bazy
Jednym z najczęstszych pól do integracji CAM + Fanuc Macro B jest obsługa sondy. Zamiast generować z CAM każdorazowo złożone sekwencje pomiarowe, wygodniej oprzeć się o jedno, dobrze opisane makro warsztatowe, do którego postprocesor tylko „podstawia” współrzędne i parametry.
Przykładowy, uproszczony interfejs makra sondy może wyglądać tak:
O9001 (POMIAR WYSOKOSCI – USTAWIENIE G54 Z) (WEJSCIE: #100 – X POMIARU #101 – Y POMIARU #102 – BEZPIECZNE Z START #103 – GLEBOKOSC POMIARU WYJSCIE: G54Z USTAWIONE NA ZM.
Wywołanie z programu z CAM:
N500 (POMIAR BAZY Z – MOCOWANIE 1) N510 G0 G90 G54 X120. Y-80. N520 #100=120. (X POMIARU) N530 #101=-80. (Y POMIARU) N540 #102=50. (Z START) N550 #103=-5. (GLEBOKOSC PROBU) N560 M98 P9001 N570 G0 Z100.
Postprocesor może generować takie wywołania automatycznie na podstawie „operacji pomiarowych” w CAM. Warunek: interfejs makra (jak parametry #100–#103) musi być ustalony i niezmienny. Jeżeli ktoś na maszynie „podrasuje” O9001 bez wiedzy programistów CAM, cała automatyzacja traci sens.
Rzeczywistość vs mit: makro sondy nie musi być „inteligentne” i rozpoznawać wszystkiego. Wystarczy, że jest powtarzalne, przewidywalne i dobrze udokumentowane, a całą „inteligencję” – gdzie mierzyć, ile punktów, po jakiej stronie – przejmuje CAM i post.
Makra parametryczne do powtarzalnych wzorów otworów
Drugi naturalny kandydat na makra zintegrowane z postprocesorem to wzory otworów: kołowe, prostokątne, łuki, nietypowe rozstawy. Można je za każdym razem rozwinąć w CAM jako osobne współrzędne, ale często wygodniej wysłać do sterowania zestaw parametrów, a same ruchy zlecić makru.
Przykład prostego makra dla rozstawu prostokątnego:
O9100 (WZOR PROSTOKATNY XY) (#100 – X START #101 – Y START #102 – LICZBA OTWOROW W X #103 – LICZBA OTWOROW W Y #104 – KROK X #105 – KROK Y #106 – GLEBOKOSC Z #107 – BEZPIECZNE Z-R UZYWA CYKLU G81)
Przy takim interfejsie wywołanie z programu CAM może wyglądać następująco:
N600 (OTWORY MOCUJACE – WZOR PROSTOKATNY) N610 T12 M6 (WIERTLO FI8 – OTWORY MOCUJACE) N620 G0 G90 G54 X0. Y0. S2500 M3 N630 G43 H12 Z100. N640 #100=50. (X START) N650 #101=30. (Y START) N660 #102=4 (ILOSC X) N670 #103=3 (ILOSC Y) N680 #104=40. (KROK X) N690 #105=35. (KROK Y) N700 #106=-25. (GLEBOKOSC) N710 #107=3. (R-PLANE) N720 M98 P9100 N730 G0 Z100.
CAM może udostępniać takie wzory jako osobny typ operacji („pattern”/„array”), ale część producentów systemów CAM robi to niewygodnie w 5-osi – wtedy proste, parametryczne makro i jego obsługa w poście pozwalają zachować porządek. Różnica między „dziurą w aluminium” a „dziurą w stalowej płycie przy czwartej zmianie” polega na tym, czy w razie problemu operator i programista są w stanie zrozumieć, co „siedzi” w O9100 bez wertowania 20 stron kodu.
Integracja postprocesora z makrami producenta maszyny
Większość obrabiarek z Fanucem przychodzi z zestawem gotowych makr: obsługa sond Renishaw/Blum, kompensacje geometrii, specjalne wiercenia, czasami cykle toczenia czy frezowania wieloosiowego. Zamiast je ignorować lub przepisywać „po swojemu”, lepiej włączyć je w standard firmowy i postprocesor.
Kilka zasad, które ułatwiają życie:
- jedno źródło prawdy – jeżeli producent dostarcza makra z dokumentacją, nie tworzona jest druga, „firmowa” wersja o tym samym numerze O9001–O90xx; zmiany robi się w ostateczności i z pełnym opisem,
- opis interfejsu w poście – postprocesor powinien mieć jasno zdefiniowane pola konfiguracyjne dla parametrów makra: np. który parametr oznacza głębokość, który stronę pomiaru, jakie są domyślne prędkości,
- kontrolowane zakresy numerów – zakres O9000–O9099 zarezerwowany dla makr producenta, O9100–O9199 dla makr firmowych, O9200+ dla eksperymentów/testów, których post nie używa.
Mit, który regularnie wraca: „makra producenta są zbyt skomplikowane, lepiej napisać swoje, prostsze”. Po kilku latach okazuje się, że „prostsze” makro nie wspiera nowych opcji, nie ma kontroli błędów ani zabezpieczeń, a nikt nie pamięta, dlaczego nie użyto gotowych rozwiązań. Dobrze przygotowany post potrafi ukryć tę złożoność za przyjaznym interfejsem w CAM.
Bezpieczeństwo ruchów przy korzystaniu z makr
Makro nie „widzi” kontekstu CAM – nie wie, co jest w modelu 3D, gdzie są zaciski, czy głowica zmieści się przy aktualnym obrocie osi obrotowych. W tym miejscu rola postprocesora jest kluczowa: wszystkie wejścia i wyjścia z makr muszą być generowane tak, jakby programista CAM nic później ręcznie nie poprawiał.
Praktyczne reguły, które dobrze „zaszyć” w poście:
- wejście do makra zawsze z bezpiecznego Z (np. lokalny Z-safe powiązany z uchwytem i mocowaniem),
- wyjście z makra na zdefiniowany poziom bezpieczeństwa (np. Z100. w układzie roboczym lub płaszczyznę lokalnej referencji),
- brak zmiany aktywnego układu współrzędnych (G54–G59, G54.1 P…) wewnątrz makra – zmiana bazy jest skutkiem, nie środkiem; środki (ruchy) generuje post i CAM,
- jednoznaczne komentarze otwierające i zamykające sekcję, tak by operator widział, w którym miejscu programu „wchodzi w logikę warsztatu”.
Rzeczywistość vs mit: samo makro „sondy” nie gwarantuje bezkolizyjności. Gwarantuje ją dopiero połączenie rozsądnych parametrów ruchu, poprawnego ustawienia uchwytu oraz konsekwentnego sposobu generowania ruchów dojścia i odejścia w poście.
Struktura pliku NC – numeracja bloków, podprogramy, podział na pliki
Fanuc jest bardzo liberalny, jeśli chodzi o strukturę pliku: linie mogą być numerowane lub nie, komentarze mogą być wszędzie, podprogramy da się zagnieżdżać do kilku poziomów. To daje swobodę, ale w firmie szybko prowadzi do chaosu: każdy programista ma „swój styl”, operatorzy przestają rozpoznawać schemat, a analiza problemów staje się udręką.
Postprocesor jest najlepszym miejscem, by ten chaos uporządkować. Kilka aspektów, które warto zdefiniować:
- numeracja bloków (N) – czy używamy jej wszędzie, tylko w nagłówkach sekcji, czy wcale; jakim krokiem (N10, N20… czy N100, N200…); czy pozostaje stała przy ponownej generacji,
- podział na pliki – jeden duży program na całą część, czy osobne pliki na mocowania/operacje; czy używamy podprogramów dla powtarzalnych detali w serii,
- konwencja O-numerów – np. O1xxx dla operacji głównych na konkretnym detalu, O7xxx dla podprogramów technologicznych, O9xxx dla makr,
- standardowe komentarze sekcji – przy rozpoczęciu i zakończeniu obróbki, przy zmianach strony/mocowania, przy ważnych przejściach technologicznych.
Mit: „numeracja bloków to przeżytek, bo i tak wszystkiego szukamy po komentarzach”. Dopóki programy są krótkie – faktycznie mało kto zwraca uwagę na N-numer. Przy skomplikowanych częściach, serwisie, analizie logów alarmów (często zawierają N-blok) numeracja staje się bardzo konkretnym narzędziem diagnostycznym.
Spójność formatów liczb i adresów
Fanuc akceptuje różne formaty: z kropką lub bez, ze znakiem „+” lub bez, z zerem wiodącym lub nie. CAM-y też mają swoje przyzwyczajenia. Bez jasnego standardu w poście programy wyglądają jak patchwork: raz X10, innym razem X10., gdzie indziej X10.000 – teoretycznie to bez znaczenia, praktycznie utrudnia wzrokowe skanowanie kodu i porównywanie wersji.
Postprocesor powinien wymuszać m.in.:
- ustaloną ilość miejsc po przecinku dla osi liniowych (np. 3 miejsca do mm, 4 do anglosaskiego),
- konsekwentny zapis prędkości i posuwów (S bez miejsc po przecinku, F z jednym lub dwoma),
- zapis promieni łuków (R) lub centrów (I, J, K) w jednym stylu, najlepiej bez przełączania się między absolutnym i przyrostowym w zależności od operacji,
- reguły zaokrąglania – czy CAM przekazuje 6 miejsc po przecinku, a post obcina, czy zaokrągla, czy ogranicza niektóre osie do mniejszej precyzji (np. C do 4 miejsc).
Rzeczywistość vs mit: „sterowanie samo zaokrągli, więc nie ma się czym przejmować”. Sterowanie faktycznie zaokrągla, ale każde zaokrąglenie dzieje się już po stronie maszyny, poza kontrolą CAM i postu. Przy delikatnych 5-osiowych wykończeniach lub przy dużych promieniach, małe różnice w formatowaniu potrafią się zsumować w postaci „szumu” na powierzchni.
Obsługa G-kodów i M-kodów specyficznych dla danej maszyny
Samo „Fanuc” niewiele mówi o tym, jakich kodów G/M można użyć. Różni producenci maszyn stosują własne rozszerzenia: G5.1, G8, G12.1, M128/M129, kombinacje cykli, funkcje synchronizacji wrzecion. Jeżeli postprocesor ma być „uniwersalny fanucowy”, kończy się to listą wyjątków i zakazów, które każdy programista i tak obchodzi po swojemu.
Skuteczniejsze podejście jest inne: postpisany konkretnie „pod tę maszynę z tym Fanucem” i opisane wyraźnie, co jest opcją producenta, a co „gołym” Fanucem. Przykłady:
- uruchamianie funkcji wysokiej jakości trajektorii (AI Contour Control, HPCC): czy włącza się ją G5.1 Q1, G08 P1, czy dedykowanym M-kodem; czy ma znaczenie, kiedy ją wyłączać,
- funkcje dynamiczne osi obrotowych (np. obróbka na walcu, obróbka w układzie polarnym): czy stosujemy G112/G113, G12.1/G13.1, czy ruchy rozwinięte z CAM,
- specjalne M-kody hydrauliki, podpór, konika, przystawek – które można automatyzować z CAM, a które muszą pozostać w gestii operatora.
Mit: „jak zrobimy jednego posta pod Fanuca, to będzie działał na wszystkich maszynach z Fanucem”. Poziom różnic między konfiguracjami (parametry, opcje, dodatkowe kanały, napęd osi) jest taki, że „uniwersalny post fanucowy” najczęściej staje się zbiorem ograniczeń do najniższego wspólnego mianownika. Lepiej mieć kilka spójnych postów pod konkretne typy maszyn niż jednego, który nikogo nie wykorzystuje w pełni.
Reakcja postprocesora na braki opcji w sterowaniu
Częsta sytuacja w warsztacie: program wygenerowany z CAM zakłada, że jest G43.4 (RTCP), G68.2 (przestrzenne obracanie układu) albo G5.1 Q1 (wysoka jakość trajektorii), a na konkretnej maszynie tych opcji po prostu nie ma. Jeżeli post nie jest tego świadomy, to operator poznaje prawdę dopiero na czerwonym alarmie.
Tu widać różnicę między „postem generującym kod” a „postem pilnującym standardu zakładu”:
- post powinien mieć model konkretnego sterowania: jakie funkcje są dostępne, jakie numery G/M są zarezerwowane pod opcje producenta,
- jeżeli CAM użyje funkcji, której sterowanie nie obsługuje, post nie generuje „najlepszego możliwego przybliżenia”, tylko raportuje błąd lub ostrzeżenie,
- dla niektórych funkcji można przewidzieć tryb awaryjny (np. zamiast G68.2 rozwinąć ruchy w bazie głównej), ale musi to być świadoma decyzja zespołu technologicznego, a nie „automatyczna magia” w poście.
Rzeczywistość vs mit: postprocesor nie jest „tłumaczem wszystkiego na wszystko”. To filtr bezpieczeństwa między abstrakcyjną ścieżką CAM a twardymi ograniczeniami konkretnego Fanuca i konkretnej maszyny. Jeżeli filtr przepuszcza wszystko, bo „jakoś to będzie”, to nie jest to post, tylko generator losowych przygód na hali.
Diagnostyka i logowanie w kodzie NC
Co warto zapamiętać
- „Postprocesor Fanuc” nie jest uniwersalny – dwa centra z tym samym 0i mogą wymagać zupełnie innego kodu, jeśli różnią się parametrami, opcjami i nakładkami OEM; mit „Fanuc jak każdy inny” kończy się alarmami, brakiem korekcji lub dziwnie działającymi cyklami.
- Sterowanie Fanuc definiuje tylko szkielet (adresy, modalność G‑kodów, format liczb, makra), a realne zachowanie programu wynika z połączenia Fanuca z konkretną maszyną i jej dodatkowymi cyklami, M‑kodami oraz parametrami producenta.
- Postprocesor musi być świadomie dopasowany do rodziny sterowań (0i, 16/18/21, 30i/31i itd.) i dostępnych opcji, bo to samo CAM‑owe 4‑osiowe czy makra G65 może działać idealnie na 31i, a na starszym 0i bez opcji TCP czy makr użytkownika wywoła serię alarmów.
- Gotowy post „Fanuc Mill/Turn” z CAM‑a to tylko punkt startu – w praktyce trzeba go skroić pod konkretne: cykle wiercenia (Fanuc vs OEM), sposób korekcji G41/G42, obsługę zmiennych #100+ oraz format posuwu i czasu (G94/G95).
- Skuteczny postprocesor powstaje dopiero wtedy, gdy traktuje się Fanuca, maszynę i CAM jako jeden system: CAM generuje ruchy i standardowe cykle, sterowanie narzuca logikę G/M, a maszyna „dokłada” mechanikę, sondy, palety i własne procedury.
