Zgadza się.
Znaleziono 5 wyników
Wróć do „LinuxCNC - czujnik narzędzia - drgania styków”
- 07 mar 2024, 18:49
- Forum: LinuxCNC (dawniej EMC2)
- Temat: LinuxCNC - czujnik narzędzia - drgania styków
- Odpowiedzi: 8
- Odsłony: 1079
- 07 mar 2024, 18:35
- Forum: LinuxCNC (dawniej EMC2)
- Temat: LinuxCNC - czujnik narzędzia - drgania styków
- Odpowiedzi: 8
- Odsłony: 1079
Re: LinuxCNC - czujnik narzędzia - drgania styków
Ale mi nie trzeba tłumaczyć. To tylko ty sobie ubzdurałeś, że wiesz wszystko lepiej i każdego powinieneś pouczać.
Przecież sam znalazłem przyczynę tego problemu - twoje posty jak zwykle nic tutaj nie wniosły.
I jednocześnie opisałem logiczne działanie procedury pomiaru - na logikę błąd ten podczas takiej procedury nie powinien być zgłaszany.
Czujnik owszem nie jest wysokich lotów - ale twórcy linuxcnc nie typują wymagań co do czujnika.
Więc może to być metalowa kostka.
Nie masz racji. Z pomiarem narzędzia akurat występuje wiele problemów.
Ot chociażby taki:
linuxcnc-dziwny-komunikat-po-pomiarze-d ... 11-10.html
gdzie sam stwierdzasz:
Wykryłem i zasygnalizowałem działanie niezgodne z logiką. Zapewne nie jako pierwszy.
Kiepski sprzęt uwidacznia niedociągnięcia programu.
Oczywiście to nie znaczy, że linuxCNC jest spieprzony. To po prostu jeden z wielu błędów/niedopracowań jakie zdarzają się w każdym programie.
Problem nie występuje przy odpowiednio dobrym sprzęcie - co nie znaczy, że nie można problemu zgłosić i przy następnej wersji (o ile będzie wola twórców) poprawić.
- 07 mar 2024, 17:50
- Forum: LinuxCNC (dawniej EMC2)
- Temat: LinuxCNC - czujnik narzędzia - drgania styków
- Odpowiedzi: 8
- Odsłony: 1079
Re: LinuxCNC - czujnik narzędzia - drgania styków
To się zgadza - czujnik jest taki sobie - ale taki tutaj będzie. To jest model stołowy a nie prawdziwa maszyna. Czujnik to kawałek aluminiowej kostki i taki tutaj zostanie bo zostać musi.
Ale dzięki temu, że czujnik jest kiepski, uwidocznił się problem/niedopatrzenie twórców LinuxCnc.
Bo zatrzymywanie się napędu (po wykryciu zadziałania czujnika) jest w dalszym ciągu częścią tej samej procedury G38 - nie jest to kolejna procedura a więc w ramach tej samej procedury nie powinno być to zgłaszane jako błąd czujnika podczas ruchu nie będącego sondowaniem, ponieważ to jest ten sam ruch z tej samej procedury.
- 07 mar 2024, 17:16
- Forum: LinuxCNC (dawniej EMC2)
- Temat: LinuxCNC - czujnik narzędzia - drgania styków
- Odpowiedzi: 8
- Odsłony: 1079
Re: LinuxCNC - czujnik narzędzia - drgania styków
Ale to jest oczywista oczywistość i standardowa twoja odpowiedź.
Wszystko rozumiesz tylko ty, z tym, że jak się ostatnio okazało, wcale nie wszystko.
Tutaj nie jest problem zadziałania od wibracji. To po prostu metalowa kostka którą dotyka narzędzie - zadziałanie czujnika polega na zetknięciu narzędzia z kostką - prąd przepływa od narzędzia do kostki (zwarcie). Ten czujnik nie zadziała od drgań. Tutaj występuje tylko "drganie styku" gdzie stykiem jest narzędzie-kostka.
Narzędzie się zatrzymuje w momencie zetknięcia z materiałem.
Mimo, że nie wykonywany jest w tym momencie żaden ruch, zgłaszany jest błąd.
Chyba, że to jest ten ruch, który występuje od wykrycia czujnika do zatrzymania napędu - ale tak być nie powinno.
Funkcja, a w zasadzie definicja GET_MOTION_INPOS_FLAG() sygnalizuje, czy każdy napęd osiągnął pozycję. Jeśli którykolwiek nie osiągnął, zwraca false. W tym przypadku sprawdzana jest ona z negacją, a więc wygląda na to, że mimo, że żaden napęd nie jest w ruchu, czasami GET_MOTION_INPOS_FLAG() zwraca false.
No ok, tylko jak mogłem stworzyć ten problem?
Nawet jeśli zwyczajnie puszczę jednorazową komendę:
G38.3 X-3 F150
to i tak czasami wyrzuca błąd po zatrzymaniu, co nie powinno się zdarzyć, bo w tej linii nie występuję wywołanie żadnego ruchu nie będącego sondowaniem.
Teraz sprawdziłem z ciekawości i zwiększyłem drastycznie przyspieszenie na osi na której wykonuję sondowanie - i błąd występuje zdecydowanie rzadziej.
To by sugerowało, że ruch wykrywany jest po wykryciu czujnika a przed zatrzymaniem napędu - no bo wiadomo, że napęd nie staje w miejscu tylko z określonym przyspieszeniem.
- 07 mar 2024, 13:49
- Forum: LinuxCNC (dawniej EMC2)
- Temat: LinuxCNC - czujnik narzędzia - drgania styków
- Odpowiedzi: 8
- Odsłony: 1079
LinuxCNC - czujnik narzędzia - drgania styków
Generalnie do tej pory zakładałem zawsze sprzętowy filtr (zazwyczaj kondensator) na wyjście z sondy próbkującej - u mnie to czujnik offsetów narzędzia.
Czujnik stykowy - narzędzie dotykając czujnika zwiera sygnał. Jak wiadomo, wszelkiego rodzaju czujniki mechaniczne powodują powstawanie zjawiska "drgania styków" -
Ale tak zacząłem się zastanawiać, jakby to rozwiązać programowo/systemowo bez konieczności montowania dodatkowych elementów - nie żeby to był jakiś koszt, ale zawsze łatwiej dopisać kilka linijek niż przylutować kondensator.
Problem jest taki, że linuxCNC zgłasza błąd, gdy wystąpi narastające zbocze na pinie sondowania, w momencie, gdy następuje ruch który nie jest ruchem sondowania. Wtedy zgłasza błąd: Probe tripped during non-probe move
Noi w sumie znalazłem podpowiedź na forum linuxcnc
https://forum.linuxcnc.org/38-general-l ... e?start=10
aby podłączyć wejście czujnika przez bramkę and, a drugie wejście bramki sterować z poziomu G-kodu który wykonuje pomiar.
W sumie to proste i działa.
Użyłem pin motion.digital-out-00 którego można sterować za pomocą M-kodów np. M64/M65.
Czyli przykładowe sondowanie wygląda tak:
Wszystko byłoby ok, ale nadal czasami wyskakuje błąd: Probe tripped during non-probe move
Trochę poszukałem, i okazuje się, że on następuje po zakończeniu G38.3 ale jeszcze przed lub w trakcie M65 P00.
Czyli tak naprawdę zgłasza błąd wykrycia sondy podczas ruchu, nawet gdy ruchu nie ma.
Poszperałem w źródłach LinuxCNC i znalazłem moment w którym błąd ten jest wyświetlany:
Niby jest sprawdzanie, czy jest aktualnie ruch ale coś chyba nie działa.
I niby można sobie to w źródłach wykomentować (ale to zwykłe druciarstwo) albo odnaleźć gdzie jest błąd - trzeba by trochę więcej chęci do tego ale da się.
Ktoś ma jakieś doświadczenie ze zgłaszaniem błędów do twórców LinuxCNC?
To nie jest jakiś krytyczny błąd, ale skoro został zauważony to warto by nie zachowywać go tylko dla siebie.
Czujnik stykowy - narzędzie dotykając czujnika zwiera sygnał. Jak wiadomo, wszelkiego rodzaju czujniki mechaniczne powodują powstawanie zjawiska "drgania styków" -
Ale tak zacząłem się zastanawiać, jakby to rozwiązać programowo/systemowo bez konieczności montowania dodatkowych elementów - nie żeby to był jakiś koszt, ale zawsze łatwiej dopisać kilka linijek niż przylutować kondensator.
Problem jest taki, że linuxCNC zgłasza błąd, gdy wystąpi narastające zbocze na pinie sondowania, w momencie, gdy następuje ruch który nie jest ruchem sondowania. Wtedy zgłasza błąd: Probe tripped during non-probe move
Noi w sumie znalazłem podpowiedź na forum linuxcnc
https://forum.linuxcnc.org/38-general-l ... e?start=10
aby podłączyć wejście czujnika przez bramkę and, a drugie wejście bramki sterować z poziomu G-kodu który wykonuje pomiar.
W sumie to proste i działa.
Użyłem pin motion.digital-out-00 którego można sterować za pomocą M-kodów np. M64/M65.
Czyli przykładowe sondowanie wygląda tak:
Kod: Zaznacz cały
M64 P00 (Uruchomienie wejścia sondy)
G38.3 X-3 F150 (Pomiar do kontaktu)
M65 P00 (wyłączenie wejścia sondy)
Trochę poszukałem, i okazuje się, że on następuje po zakończeniu G38.3 ale jeszcze przed lub w trakcie M65 P00.
Czyli tak naprawdę zgłasza błąd wykrycia sondy podczas ruchu, nawet gdy ruchu nie ma.
Poszperałem w źródłach LinuxCNC i znalazłem moment w którym błąd ten jest wyświetlany:
Kod: Zaznacz cały
if (emcmotStatus->probing) {
/* check if the probe has been tripped */
if (emcmotStatus->probeVal ^ probe_whenclears) {
/* remember the current position */
emcmotStatus->probedPos = emcmotStatus->carte_pos_fb;
/* stop! */
emcmotStatus->probing = 0;
emcmotStatus->probeTripped = 1;
tpAbort(&emcmotInternal->coord_tp);
/* check if the probe hasn't tripped, but the move finished */
} else if (GET_MOTION_INPOS_FLAG() && tpQueueDepth(&emcmotInternal->coord_tp) == 0) {
/* we are already stopped, but we need to remember the current
position here, because it will still be queried */
emcmotStatus->probedPos = emcmotStatus->carte_pos_fb;
emcmotStatus->probing = 0;
if (probe_suppress) {
emcmotStatus->probeTripped = 0;
} else if(probe_whenclears) {
reportError(_("G38.4 move finished without breaking contact."));
SET_MOTION_ERROR_FLAG(1);
} else {
reportError(_("G38.2 move finished without making contact."));
SET_MOTION_ERROR_FLAG(1);
}
}
} else if (!old_probeVal && emcmotStatus->probeVal) {
// not probing, but we have a rising edge on the probe.
// this could be expensive if we don't stop.
int i;
int aborted = 0;
if(!GET_MOTION_INPOS_FLAG() && tpQueueDepth(&emcmotInternal->coord_tp)) {
// running an command
tpAbort(&emcmotInternal->coord_tp);
reportError(_("Probe tripped during non-probe move."));
SET_MOTION_ERROR_FLAG(1);
}
I niby można sobie to w źródłach wykomentować (ale to zwykłe druciarstwo) albo odnaleźć gdzie jest błąd - trzeba by trochę więcej chęci do tego ale da się.
Ktoś ma jakieś doświadczenie ze zgłaszaniem błędów do twórców LinuxCNC?
To nie jest jakiś krytyczny błąd, ale skoro został zauważony to warto by nie zachowywać go tylko dla siebie.