linuxCNC obsługuje do 9osi, i jest systemem czasu rzeczywistego, w porównaniu do urzeczywistnianych systemach windows. tumanek, trochę tego liznąłem na zajęciach. Programowanie sferyczne, cylindryczne, przeliczanie pozycji itp robiliśmy na zajęciach. Ba, nawet egzamin z tego miałem, ale na kartce papieru.

www.kimla.pl pisze:Można przegenerować kod w CAM-ie, ale jak np. operatorowi złamie się narzędzie to co?

To i detal uszkodzony jest pewnie też.
Fajnie, że wywinęła się ciekawa dyskusja, gdyż mało jest osób, które się na tym znają (5 osi +), a warto poszerzać horyzonty:)

Dobra, czyli aby dojść do jakiegoś konsensusu:
W przypadku, w którym mówi www.kimla.pl mamy wygenerowaną już wcześniej w CAM ścieżkę dla 5osi i program w przypadku wymiany narzędzia, przebudowuję ścieżkę tak, aby uzyskać zamierzony efekt?

W drugim przypadku mamy tak, że zmianę narzędzia itp uwzględniamy w CAM i on sam wykonuję operacje, których efektem jest gcode, który już ma przebudowaną ścieżkę?

Dobrze rozumiem?Jeżeli tak, to jakie są plusy i minusy danych rozwiązań? Już wiemy, że operator ma łatwiejszą prace w pierwszym przypadku. Coś więcej? Są firmy, w których od pisania gcode są specjalni 'technolodzy' a operatorzy maszyn jedynie nadzorują...

Ale tu chodzi o 'rzeczywistą' długość narzędzia...Co nie bardzo rozumiem, zwłaszcza gdy w automatach są narzędzia z pamięcią. No ale, młody jestem.

www.kimla.pl pisze:Tyle tylko że nie kontroluje prędkości czoła narzędzia i nie przebudowuje ścieżki po zmianie długości narzędzia.

A czy to nie powinno być uwzględnione w napisanym programie w gcode?Np. czy EdgeCAM nie działa w ten sposób? Tak tylko pytam, gdyż spotkałem się, że prosta kompensacja narzędzia niekiedy jest błędnie wykonywana w Machu.

Ja bym popróbował z linuxcnc EMC2. Widziałem frezarki 5osiowe działające na tym systemie. Ale jak to jest w kwestii, o której wspomina www.kimla.pl, to nie wiem. To jest system opensource, więc szybko poprawki wchodzą.