Pomoc - błąd interpolacji kołowej - PROGMASTER

Dyskusje dotyczące programowania G-Code
Awatar użytkownika

Petroholic
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2688
Rejestracja: 08 gru 2015, 12:23
Lokalizacja: Lublin
Kontakt:

#11

Post napisał: Petroholic » 03 lis 2017, 21:38

kuba716 pisze:zmieniłem na:
G2 X62 Z-70 I6 K0 - bez wywołania G18.
Iii... wyszło wszystko ładnie pięknie.
Dlatego, że wywołałeś przez IJK, a nie samo R...
kuba716 pisze:nie każdy sterownik czy symulator działa na parametrze R, to tylko uproszczenie jeśli pracujemy na jednym sterowniku (tak mi się wydaje)
To bardziej uproszczenie dla operatora jeśli trzeba na szybko napisać z palca łuki w dziwnych wymiarach, a kalkulatora nie ma pod ręką...



Tagi:


Steryd
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 2
Posty: 4140
Rejestracja: 13 lut 2017, 19:34
Lokalizacja: Szczecin

#12

Post napisał: Steryd » 03 lis 2017, 22:14

nie do końca- Funkcja G2 /G3 Z parametrem promieniowym (R, B, C- w zależności od sterowania) jest podstawową wersją interpolacji kołowej. Niestety z racji tego, ze okrąg nie jest funkcją (ma 2 rozwiazania dla każdego argumentu) taki opis ma kilka ograniczeń- pierwsze to dwa rozwiązania dla każdego zestawu parametrów (stąd konieczność podawania wartości promienia ze znakiem) drugie, to w szczególnych przypadkach nieskończenie wiele rozwiązań (choćby w przypadku pokrywania się punktu początkowego i końcowego. Dlatego w układach sterowania opisana została druga metoda definicji łuku - położeniem środka okręgu (w zależności od układu sterowania parametry IJK są współrzędnymi przyrostowymi , bezwzględnymi, lub przyrostowymi liczonymi względem punktu docelowego). Ta metoda też ma ograniczenia. jak widać. W układach sterowania (przynajmniej tych przemysłowych) nie jest błędem zdefiniowanie łuku przy pomocy obu tych metod na raz, ale w przypadku niezgodności danych ignorowana jest ta druga metoda, nawet jeśli dzięki niej możliwe jest wykonanie łuku, a łuk zdefiniowany promieniem jest błędny. To dlatego, że ta pierwsza metoda jest nadrzędna.
Można?
Morzna!!!

Awatar użytkownika

Petroholic
Lider FORUM (min. 2000)
Lider FORUM (min. 2000)
Posty w temacie: 5
Posty: 2688
Rejestracja: 08 gru 2015, 12:23
Lokalizacja: Lublin
Kontakt:

#13

Post napisał: Petroholic » 03 lis 2017, 22:38

Steryd pisze:Niestety z racji tego, ze okrąg nie jest funkcją (ma 2 rozwiazania dla każdego argumentu) taki opis ma kilka ograniczeń- pierwsze to dwa rozwiązania dla każdego zestawu parametrów (stąd konieczność podawania wartości promienia ze znakiem)
Nie do końca się zgodzę (chociaż nie znam dobrze innych systemów poza Machem). W Machu zawsze definiujesz promień "z plusem", a jedno z możliwych rozwiązań łuku określasz poprzez wywołanie G2 lub G3 (wypukły lub wklęsły). Pomiędzy punktem A i B na jednej płaszczyźnie istnieją tylko dwa możliwe łuki o promieniu R...
Steryd pisze:W układach sterowania (przynajmniej tych przemysłowych) nie jest błędem zdefiniowanie łuku przy pomocy obu tych metod na raz, ale w przypadku niezgodności danych ignorowana jest ta druga metoda, nawet jeśli dzięki niej możliwe jest wykonanie łuku, a łuk zdefiniowany promieniem jest błędny. To dlatego, że ta pierwsza metoda jest nadrzędna.
A w przypadku Macha odwrotnie. Metoda IJK jest nadrzędna ale przy użyciu IJKR jeśli jest błąd współrzędnych promieniowych Mach się zatrzyma i wyrzuci błąd... Nie zignoruje jakiegokolwiek błędnego parametru - jeśli parametry sobie zaprzeczają to się zatrzyma...

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „G-CODE - programowanie”