#4
Post
napisał: lajosz » 16 paź 2016, 13:40
@sempth
Popatrzyłem na DXF-a i G-Code który podesłałaś, i:
DXF --> w miejscu gdzie masz datę, są nakładające się wektory, ale dodatkowo, każdy wektor (chodzi o datę) wygląda na pojedynczy, ale jest podwójny, czyli zamknięty, ale linie właściwie nachodzą na siebie i jest to niestety przypadłość tzw. fontów jednoliniowych CamBam-a, a inaczej pisząc, CAM-Bam nie ma fontów jednoliniowych, a jedynie wyglądające na takie.
W efekcie maszyna frezuje tę datę najpierw w jedną, później w drugą stronę i to dwa razy.
Poza tym, pomijając wektory daty, jest kilka zapętlonych wektorów + takich z nakładającymi się węzłami.
Powyższe, choć nie powinno mieć miejsca, to jednak nie jest przyczyną tego co widzimy na zdjęciu.
Otóż z G-Code wynika, że użyłeś postprocesora generującego G-Code z łukami, czyli to na sterownik lub oprogramowanie maszyny spada obliczanie aproksymacji krzywych.
Jeśli więc coś nie tak ustawione masz w programie sterującym maszyną (np. Mach lub inny), albo sterowniki sobie (bardzo ogólnie pisząc) nie radzą, to będziesz maił takie rzeczy jak na zdjęciu.
Postprocesory używające łuków do generowania G-Code, najczęściej mają dopisek .ARC
Spróbuj wygenerować G-Code bez używania łuków.
Wtedy program sterujący maszyną (tudzież sterownik) ma znacznie mniej "do gadania" i musi sztywno trzymać G-Codu.
Jeśli zrobisz jak wyżej, a mimo to nic się nie zmieni, to możliwe, ze masz zbyt niskie obroty wrzeciona przy szybkim posuwie.
Zwróć uwagę, że akurat w/w data, wygląda najlepiej, a to dlatego, że 4 razy przebiega frezowanie w jedną, a następnie w drugą stronę, więc wszelkie nierówności przy tylu przebiegach zostają prawie wygładzone, nawet jeśli masz zbyt małe obroty czy zbyt szybki posuw.
W załączniku G-Code wygenerowany przez ArtCAM-a na podstawie Twojego DXF-a którego oczyściłem z w/w zbędnych rzeczy.
Całość zapisana do G-Codu bez używania łuków.
