Gkod generowany przy okręgach

Cześć!
Czy to normalne, że ArtCAM przy generowaniu gkodów z okręgów zapisuje je jako zestaw ruchów prostych, tzn używa tylko polecenia G1? Z tego co wiem do łuków wykorzystuje się G2 i G3.

W ten sposób niewielkie kółko zajmuje 600 linii kodu a można by je zapisać spokojnie w 2.

Może to kwestia jakiś ustawień?
Używałem ArtCAMa Premium 2018.

Pozdrawiam!

Tak masz rację ale interpolacja kołową proste sterowania odpracowywać umieją tylko na płaszczyźnie XY czyli strategii 2.5 osi. Pozostałe ruchy jak wierszowanie po kształcie 3D są to odcinki prosie. No chyba, że sterowanie rozwiązuje wielomiany to wtedy do programu trafiają nurbsy (spline). Za to odpowiada postprocesor dedykowany do sterowania. Czyli tę samą ścieżkę możemy postwoać w różnych językach na różna sterowania. I jeden blok programu wygląda nap tak:
17 L Z128.597 F800
18 L X163.678 Y2.896 Z128.22
19 SPL X163.3 Y2.309 Z127.834 ~
K3X-3.5078E-02 K2X8.1825E-02 K1X3.3161E-01 K3Y-8.0839E-02 K2Y-4.4934E-02 K1Y7.1242E-01 K3Z9.7588E-02 K2Z7.8374E-02 K1Z2.0983E-01
20 SPL X162.884 Y-.061 Z127.633 ~
K3X1.6008E-01 K2X2.6389E-01 K1X-7.9975E-03 K3Y-1.8698E-01 K2Y1.5230E-01 K1Y2.4048E+00 K3Z2.8139E-01 K2Z-1.3142E-01 K1Z5.1447E-02
21 SPL X163.037 Y-.888 ~
K3X-5.1833E-02 K2X2.8708E-01 K1X-3.8895E-01 K3Y-8.7192E-02 K2Y1.6791E-01 K1Y7.4582E-01 K3Z7.3991E-13 K2Z-5.0468E-13 K1Z-3.5773E-13
22 SPL X163.332 Y-1.279 ~
K3X2.8457E-02 K2X1.1833E-02 K1X-3.3537E-01 K3Y1.4605E-02 K2Y1.3042E-02 K1Y3.6409E-01 K3Z-5.5870E-14 K2Z-3.2800E-15 K1Z-3.3990E-14
23 SPL X163.973 Y-1.934 ~
K3X2.2874E-02 K2X-2.7865E-02 K1X-6.3531E-01 K3Y2.4179E-02 K2Y-2.7615E-02 K1Y6.5842E-01 K3Z1.0400E-15 K2Z-1.4440E-14 K1Z-3.7340E-14
24 SPL X167.004 Y-8.778 ~
K3X3.2964E-01 K2X-2.9278E+00 K1X-4.3273E-01 K3Y-5.7021E-01 K2Y-2.1088E-01 K1Y7.6246E+00 K3Z-3.6092E-13 K2Z7.8360E-14 K1Z6.1454E-13
25 SPL X167.027 Y-9.623 ~
K3X-1.1386E-02 K2X-1.7016E-03 K1X-1.0329E-02 K3Y-9.1862E-04 K2Y1.7310E-04 K1Y8.4622E-01 K3Z-2.7000E-16 K2Z1.7800E-15 K1Z6.5270E-14
26 SPL X167.037 Y-18.344 ~
K3X-8.4177E-02 K2X7.1647E-02 K1X2.7403E-03 K3Y1.4459E-02 K2Y-2.4975E-02 K1Y8.7313E+00 K3Z-3.8473E-13 K2Z1.3436E-12 K1Z-8.6010E-13
27 SPL X166.91 Y-21.07 ~
K3X1.3344E-01 K2X-3.9325E-01 K1X3.8706E-01 K3Y-1.5618E-02 K2Y4.4394E-02 K1Y2.6976E+00 K3Z8.0680E-14 K2Z-1.0977E-13 K1Z-2.9236E-13
28 SPL X164.485 Y-26.427 ~
K3X-2.7539E-01 K2X-1.0322E+00 K1X3.7319E+00 K3Y-2.9813E-01 K2Y1.1042E+00 K1Y4.5501E+00 K3Z2.0708E-13 K2Z-1.1400E-12 K1Z1.0232E-12
29 L X164.262 Y-26.772 Z127.632
30 L X164.094 Y-27.14 Z127.63
31 L X163.971 Y-27.519 Z127.627

Nie znam ArtCAM, ale w ESTLCAM w ustawieniach jest ptaszek przy "użyj poleceń łuku G02/G03". Jego odznaczenie powoduje właśnie generowanie bardzo krótkich linii zamiast okręgów.

Seneszal pisze: ↑

20 lut 2020, 21:20

Czy to normalne, że ArtCAM przy generowaniu gkodów z okręgów zapisuje je jako zestaw ruchów prostych ........ Może to kwestia jakiś ustawień?

Temat dosyć złożony, ale .... :

--- Artcam, ale również zdecydowana większość oprogramowania CNC które generuje jakiś G-Code, pozwala wybrać postprocesor który generuje określony rodzaj G-Code. ..... i tak np. w Artcamie możesz wygenerować G-Code składający się tylko z lini prostych jak również taki który zawiera komendy do generowania łuków jeśli oczywiście rysunek zawiera jakieś łuki.
Taki postprocesor który generuje łuki, najczęściej ma w nazwie dopisek ARC, czyli skrót od angielskiego "łuk" lub z łaciny arcus, czyli .. też "łuk".

Jednak .... nie zawsze krótszy G-code , czyli .... ten z łukami (a więc mniej ważący) jest lepszy.

Generując G-Code z komendami do łuków, co prawda radykalnie zmniejszamy wagę pliku, szczególnie jeśli rysunek jest skomplikowany, ale ..... wtedy mogą pojawić się kłopoty przy interpretacji komend łukowych przez program sterujący maszyną, albo .... bywa ze program sterujący maszyną jest na tyle prosty (lub archaiczny) , że zwyczajnie nie obsłuży G-Codu zawierającego komendy łukowe.

Poza tym, wtedy to sterownik maszyny i/lub program sterujący decydują jaka będzie aproksymacja krzywej.
Natomiast w przypadku prostych odcinków (czyli bez łuków) to program generujący G-Code (w tym przypadku akurat Artcam) decydije o aproksymacji krzywej i maszyna tylko "odtwarza" to co widać w wygenerowanym G-Code, czyli niczego nie interpretuje.

Co prawda w niektórych programach sterujących maszynami, można sterować dokładnością dopasowania do ścieżki (czyli pośrednio aproksymacją) , ale .... zazwyczaj nie przynosi to oczekiwanych rezultatów.

===========
Reasumując, jeśli w Artcamie wybierzesz postprocesor który wnazwie ma ARC, to wygenerowany G-Code będzie zawierał komendy łukowe.
Oczywiście nie dotyczy to (jak słusznie zauważył zibi) G-Codu generowanego dla modelu 2.5D, czyli w tym przypadku ZAWSZE będą to proste odcinki.

Zresztą, ..... KAŻDE CNC i tak pracuje TYLKO na odcinkach prostych (stąd pojęcie aproksymacji krzywej), bo łuk tak naprawdę dla maszyn CNC nie istnieje.

Jeśli wykonujemy ruch bez zatrzymania dwema lub więcej osiami ze zmienna prędkością to śmiem twierdzić, że uzyskamy krzywą gładką.

Rozumiem.
Temat przyszedł mi do głowy ze względu na problem z maszyną, właśnie na łukach, których ścieżkę generuję w ArtCAMie.

maszyna-gubi-koordynaty-w-czasie-pracy-t104080.html


Pokrótce chodzi o to, że przy ciasnych łukach (czyli okręgach o średnicy ok. 30mm lub mniej) maszyna jakby przeskakuje przy kolejnych liniach kodu, co objawia się tym, że całe wrzeciono drży. Taki sam okrąg zapisany przy użyciu funkcji G3 idzie zupełnie płynnie.

Pewnie jest to kwestia jakiś ustawień Macha3 lub problemów z maszyną, ale jak spojrzałem na gkod, to wydało mi się dziwne, że wszystko jest prostymi - robione ruchem G1.

Dzięki za wyjaśnienie.

Seneszal pisze: ↑

20 lut 2020, 22:25

Pokrótce chodzi o to, że przy ciasnych łukach (czyli okręgach o średnicy ok. 30mm lub mniej) maszyna jakby przeskakuje przy kolejnych liniach kodu, co objawia się tym, że całe wrzeciono drży. Taki sam okrąg zapisany przy użyciu funkcji G3 idzie zupełnie płynnie.

Jeśli tak, to na 98% obstawiam, że coś jest nie tak przy ustawieniach Macha.

Dlaczego ?

Otóż w naszej firmie robimy rzeczy, gdzie CODZIENNIE zdarzają się okręgi o średnicy np. 0.3mm .... tak, to nie pomyłka .... 3 dziesiąte milimetra i .... wszystko idzie płynnie, a korzystamy TYLKO z Artcama który generuje G-Code złożony TYLKO z odcinków prostych.

Maszyny to Kimla z programem sterującym PC-CAM, przy czym NIE KORZYSTAMY z dedykowanego postprocesora do maszyn Kimli.
Inaczej pisząc, Artcam generuje najprostszy możliwy G-Code i taki trafia do w/w maszyn/oprogramowania.

=======
Jeszcze jedno.
Zanim wrzucisz G-Code do frezowania, sprawdź w Artcamie symulację obróbki.
Jeśli po "wyfrezowaniu" łuk jest nadal łukiem, to NIE MA MOŻLIWOŚCI żeby Artcam wygenerował niewłaściwy G-Code.

Jeśli ja chcę sprawdzić jak po kolei (krok po kroku) idzie G-Code, to wrzucam taki G-Code (oczwyiście generowany przez Artcama) do Pico CNC i tam idealnie widać jak to wszystko wygląda i jak pracuje z podglądem każdej aktualnie wykonywanej komendy.

To samo jest na w/w PC-CAM, ale ..... w PC-CAM nie sprawdzam bo nie mam dostępu do tego oprogramowania, tzn. ..... musiałbym pójść do frezerów i zawracać im d_pę, a tak otworzę sobie w Pico CNC i ..... już wszystko wiadomo.

Zresztą, takie "kwiatki" o kótrych piszesz, wynikają najcześciej z niewłaściwie ustawionego proramu sterującego, albo (znacznie rzadziej) z budowy maszyny, czyli zastosowanego sterownika lub silników.

lajosz pisze: ↑

21 lut 2020, 00:08

Zresztą, takie "kwiatki" o kótrych piszesz, wynikają najcześciej z niewłaściwie ustawionego proramu sterującego, albo (znacznie rzadziej) z budowy maszyny, czyli zastosowanego sterownika lub silników.

Znalazłem opcję w Machu3 "Constant Velocity"



Polega ona na tym, że przy kodzie napisanym na ruchach prostych program zaokrągla łączenia odcinków i dzięki temu nie zwalnia przy każdej kolejnej linii kodu i nie szarpie w związku z tym. Można na przykład ustalić kąt przy jakim zacznie zaokrąglać.

Zdaje się, że w G-kodzie jest to G61 i G64.
Czy w ArtCAMie jest jakaś opcja dokładająca te komendy w odpowiednich miejscach? Na przykład na okręgach właśnie.

Dzięki i pozdrawiam!

Seneszal pisze: ↑

07 mar 2020, 20:46

Czy w ArtCAMie jest jakaś opcja dokładająca te komendy w odpowiednich miejscach? Na przykład na okręgach właśnie.

Nie ma i ..... podejrzewam, że w żadnym CAM-ie takiej opcji nie ma.

Takie sprawy załatwia postprocesor, czyli trzeba wybrać postprocesor generujący komendy dla łuków.
W Artcamie, takie postprocesory mają w nazwie ARC.

Właśnie po to w Machu (i innych programach sterujących maszynami) są odpowiednie opcje żeby je ustawić w razie konieczności.
W różnych programach sterujących maszynami różnie się ta opcja nazywa, a w niektórych nie ma jej wcale, bo np. jest włączona domyślnie.

lajosz pisze: ↑

21 lut 2020, 00:08

Otóż w naszej firmie robimy rzeczy, gdzie CODZIENNIE zdarzają się okręgi o średnicy np. 0.3mm .... tak, to nie pomyłka .... 3 dziesiąte milimetra i .... wszystko idzie płynnie, a korzystamy TYLKO z Artcama który generuje G-Code złożony TYLKO z odcinków prostych.


Maszyny to Kimla z programem sterującym PC-CAM, przy czym NIE KORZYSTAMY z dedykowanego postprocesora do maszyn Kimli.
Inaczej pisząc, Artcam generuje najprostszy możliwy G-Code i taki trafia do w/w maszyn/oprogramowania.

Jak wygląda w takim razie praca na tych prostych odcinkach? Mówisz, że to wszystko działa płynnie. Czy dlatego, że PC-CAM to wygładza czy dlatego, że serwa w Kimli są bardziej wydajne od moich silników krokowych albo ze względu na jakieś inne różnice konstrukcyjne maszyny?