LinuxCNC - jak podłączyć wszystkie czujniki bazowania oraz krańcowe do jednego pinu LPT

drzasiek90 pisze: ↑

25 lut 2024, 21:37

Bo ty nie masz skonfigurowanych czujników krańcowych.

Czytaj uważnie, bo drugi raz tłumaczyć nie będę.
Rozmawiamy o sytuacji, gdy wszystkie czujniki są podpięte pod jedno wejście i stanowią jeden sygnał.
Linuxcnc, ani żaden inny program, nie jest w stanie określić, który czujnik zadziałał.
Przy rozpoczęciu procedury bazowania, wszystkie czujniki muszą być nieaktywne.
Potem, po kolei, osie wykonują ruch bazujący, ale tylko jedna oś może być aktywna w danym momencie, więc wiadomo który czujnik zadziałał.
W czasie normalnej pracy maszyny, zadziałanie dowolnego czujnika bazującego powoduje alarm i zatrzymanie programu.
Czegoś nie rozumiesz?

tuxcnc pisze: ↑

25 lut 2024, 21:51

Przy rozpoczęciu procedury bazowania, wszystkie czujniki muszą być nieaktywne.

Ty nie rozumiesz, że to nie ja sobie to wymyśliłem, lecz tak działa LinuxCNC?
Czujniki są nieaktywne, ale w momencie najechania na czujnik bazujący podczas bazowania, linuxcnc wykrywa również na pozostałych (zbazowanych już osiach) zadziałanie czujnika krańcowego - bo to ten sam pin! Dlatego wykrywanie czujnika krańcowego na osi X jest MUSI ZOSTAĆ WYŁĄCZONE podczas bazowania osi Z a wykrywanie czujnika krańcowego osi Z MUSI ZOSTAĆ WYŁĄCZONE podczas bazowania osi X. I do tego służy konfiguracja jaką przedstawiłem.

tuxcnc pisze: ↑

25 lut 2024, 21:51

W czasie normalnej pracy maszyny, zadziałanie dowolnego czujnika bazującego powoduje alarm i zatrzymanie programu.

Dlaczego nie czytasz ze zrozumieniem.
Przecież cały czas rozchodzi się o procedurę bazowania.
Możesz mieć 2 czujniki na osi, z czego jeden jako bazujący i krańcowy a drugi jako krańcowy z drugiej strony.
Użycie jednego pinu uniemożliwia użycie osobno czujnika bazującego pomiędzy czujnikami krańcowymi.


NOTO JESZCZE RAZ OD POCZĄTKU.
Mam maszynę 2 osiową. Mam po 2 czujniki na obu osiach. Czujnik na jednym końcu osi to czujnik krańcowy, czujnik na drugim końcu to czujnik krańcowy oraz bazujący. Na obydwu osiach to samo.

Ta twoja linijka konfiguracji którą podałeś NIE ZADZIAŁA!!! BAZOWANIE SIĘ NIE UDA ZAKOŃCZYĆ POPRAWNIE.
A więc całe twoje zaangażowanie jest tutaj nieuzasadnione.

drzasiek90 pisze:Multiplekserem trzeba sterować. Poza tym, po co dokładać zewnętrzny układ, skoro sprawę załatwia kilka linijek w pliku hal?

Nie trzeba sterować. Wystarczy napisać kilka linijek kodu demultipleksera, zamieniającego daną krańcówkę na wartość bitową albo poziom napięcia i odpalać to razem z całym systemem. Trzeba też napisać drugie kilka linijek, które po stronie LinuxCNC zinterpretują tę wartość jako daną krańcówkę.

Kosztuje to 30-50 złotych a pozwala bazować szybciej. Poza tym są sytuację, gdzie jest to bardzo istotne, która krańcówka daje sygnał. Dlaczego więc nie?

forestgril pisze: ↑

25 lut 2024, 22:29

Nie trzeba sterować. Wystarczy napisać kilka linijek kodu demultipleksera, zamieniającego daną krańcówkę na wartość bitową albo poziom napięcia i odpalać to razem z całym systemem.

LinuxCNC wykrywa stan na wejściu. Jak chcesz za pomocą jednego wyjścia z demultipleksera przesłać który to stan? PWM? Jakieś impulsy?

I teraz jak przekonasz LinuxCNC aby to tak dekodował. Oczywiście można, bo źródła są dostępne. Tylko to zupełnie bez sensu.

forestgril pisze: ↑

25 lut 2024, 22:29

Poza tym są sytuację, gdzie jest to bardzo istotne, która krańcówka daje sygnał. Dlaczego więc nie?

Jakie np?
Jeśli zadziała którakolwiek krańcówka, maszyna ma się zatrzymać.

dodaj jeszcze programowe przesunięcie od zejścia z krańcówki tak aby zbazowana oś była wystarczająco daleko od zluzowanej krańcówki. Przy wolnym i dokładnym wymacaniu pozycji i fizycznych warunków - zimno/ciepło, różne opory smaru wózków stop osi nastąpić może na granicy rozwarcia styków i pomimo zatrzymania po pierwszej przerwie krańcówka w niepełnym zluzowaniu nadal będzie mogła szumieć i dawać sygnał.

Bezpieczną odległość od krańcówki ustawia się w ini: HOME_OFFSET i HOME.

qqaz pisze: ↑

26 lut 2024, 00:54

dodaj jeszcze programowe przesunięcie od zejścia z krańcówki tak aby zbazowana oś była wystarczająco daleko od zluzowanej krańcówki.

Tak jest, w każdej maszynie to mam.

tuxcnc pisze: ↑

25 lut 2024, 21:51

W czasie normalnej pracy maszyny, zadziałanie dowolnego czujnika bazującego powoduje alarm i zatrzymanie programu.

I tutaj faktycznie popełniłem błąd.
Pojęcia nie mam skąd mi się to wzięło, ale krańcówka bazująca poza cyklem bazowania jest ignorowana i nie powoduje żadnego alarmu.
Zupełnym przypadkiem byłem dzisiaj przy tokarce i to sprawdziłem.
Natomiast w niczym nie zmienia to faktu, że zaprezentowany przez autora wątku kod jest przekombinowany i po prostu straszny...
Linuxcnc nie rozpozna który switch zadziałał, żaden program tego nie rozpozna, bo to jest jedno wejście i jeden bit.
Tak więc sygnał powodujący alarm można podać na jednen dowolny pin HAL bo liczy się tylko jego zadziałanie, a wyświetlony komunikat może być, czyli często będzie, dowolnie mylący...
Właściwym rozwiązaniem wydaje się więc użycie komponentu LUT5 https://linuxcnc.org/docs/html/man/man9/lut5.9.html
Może nie jest to specjalnie czytelne dla początkujących, ale też nie jest ponad możliwości zrozumienia przeciętnego użytkownika Linuxcnc....

drzasiek90 pisze:Jakie np?
Jeśli zadziała którakolwiek krańcówka, maszyna ma się zatrzymać.

Chyba niekoniecznie. Mogę sobie wyobrazić, że od tego, która krańcówka zadziałała, może zależeć strategia automatycznego wyjścia z materiału. Choć pewnie to nieczęsta sytuacja, gdy chcemy wykorzystać 100% pola roboczego.

forestgril pisze: ↑

26 lut 2024, 15:40

drzasiek90 pisze:Jakie np?
Jeśli zadziała którakolwiek krańcówka, maszyna ma się zatrzymać.

Chyba niekoniecznie. Mogę sobie wyobrazić, że od tego, która krańcówka zadziałała, może zależeć strategia automatycznego wyjścia z materiału. Choć pewnie to nieczęsta sytuacja, gdy chcemy wykorzystać 100% pola roboczego.

Tutaj akurat sprawa jest jasna.
Zgłoszenie sytuacji awaryjnej musi natychmiast zatrzymać maszynę.
Po prostu zakłada się, że kontynuowanie obróbki gdy którykolwiek z parametrów jest niepewny, nie prowadzi do oczekiwanych efektów.
Tutaj kłania się jedno z podstawowych praw informatyki, że przetwarzanie błędnych danych daje błędne wyniki…
To co kombinujesz może mieć sens w specyficznych sytuacjach, ale nie może być rozwiązaniem o charakterze uniwersalnym.