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

drzasiek90 · Post napisał: **drzasiek90** » 26 lut 2024, 21:19

tuxcnc pisze: ↑
26 lut 2024, 14:49
Natomiast w niczym nie zmienia to faktu, że zaprezentowany przez autora wątku kod jest przekombinowany

Możliwe, że jest przekombinowany - wspominałem o tym już w pierwszym poście. Ale działa dokładnie tak jak powinien.
Możliwe, że można prościej, śmiało można zaprezentować "konkurencyjne" rozwiązania.

tuxcnc pisze: ↑
26 lut 2024, 14:49
Linuxcnc nie rozpozna który switch zadziałał, żaden program tego nie rozpozna, bo to jest jedno wejście i jeden bit.

Ale rzecz w tym, że podłączając wszystkie czujniki pod jeden pin nikt nie oczekuje rozpoznania który to sygnał.
I LinuxCNC nie rozpoznaje który, więc w momencie wykrycia stanu aktywnego na tym pinie, zgłasza zadziałanie wszystkich czujników które zostały pod ten pon skonfigurowane (również czujniki krańcowe), co powoduje zatrzymanie procedury bazowania.

tuxcnc pisze: ↑
26 lut 2024, 14:49
Właściwym rozwiązaniem wydaje się więc użycie komponentu LUT5

W jaki sposób klasyfikujesz które rozwiązanie jest właściwe a które niewłaściwe?

Jeśli istnieją np. dwa rozwiązania i obydwa spełniają swoją funkcję i działają tak jak powinny, to które z nich jest właściwe a które nie?
Rozumiem, że może być rozwiązanie lepsze i gorsze, bardziej optymalne i mniej optymalne.
Ale jeśli jest właściwe i niewłaściwe, to to niewłaściwe powinno dawać niewłaściwe/nieprawidłowe efekty.
Natomiast rozwiązanie które zaprezentowałem (może i nie jest optymalne - zapraszam do podania bardziej optymalnego) ale nie można nazwać niewłaściwym, ponieważ działa dokładnie tak jak powinno.
Niewłaściwym rozwiązaniem do tego problemu natomiast jest to:

tuxcnc pisze: ↑
25 lut 2024, 19:47
Sprawę załatwia następujący wpis w pliku hal:
Kod: Zaznacz cały
net min-home joint.0.home-sw-in joint.1.home-sw-in parport.0.pin-15-in-not

Czy rozwiązanie z komponentem LUT5 jest właściwe będzie można ocenić, gdy zostanie przygotowane i sprawdzone.

Robert_K · Post napisał: **Robert_K** » 26 lut 2024, 21:50

Ja pi***ole, jak Lidl i Biedronka

Z tą różnicą że jeden robi coś i chce się tym podzielić, a drugi się pr***ierdala nie pokazując niczego konkurencyjnego stworzonego przez siebie.

Pozdrawiam.

tuxcnc · Post napisał: **tuxcnc** » 27 lut 2024, 08:55

drzasiek90 pisze: ↑
26 lut 2024, 21:19
Czy rozwiązanie z komponentem LUT5 jest właściwe będzie można ocenić, gdy zostanie przygotowane i sprawdzone.

No to je przygotuj i sprawdź, bo to Tobie jest ono potrzebne, a mi nie.
Natomiast co do poprawności rozwiązania, to czy gwoździe da się wbijać kombinerkami?
Jeżeli niektórzy to robią, to należy przyjąć że się da, ale jednak powszechnie się uważa, że kombinerki do tego celu nie służą i nie powinno się tego tak robić...
Wracając do twojego kodu, to jest on błędny w samym założeniu.
Tak naprawdę, to sygnał bazujący może być podłączony na stałe do odpowiednich pinów HAL od bazowania osi, a odcinać na czas bazowania trzeba sygnał podłączony do pinów HAL od limitów.
Czyli mój kod, do którego się tak uczepiłeś, jest prawidłowy, z tym, że załatwia on tylko bazowanie, więc potrzebujesz dopisać kod blokujący zadziałanie limitów, wszystkich na raz, bo one i tak nie biorą udziału w bazowaniu.
Mówiąc inaczej:
1. sygnał wejściowy jest na stałe podłączony do pinów HAL od bazowania.
2. sygnał wejściowy jest odłączany od pinów HAL od limitów, na czas bazowania dowolnej osi.
Teraz kilka słów o elemencie LUT5.
Nie podoba mi się wytłumaczenie na stronie https://linuxcnc.org/docs/html/man/man9/lut5.9.html
Dla mnie ono bardziej ściemnia niż wyjaśnia, choć formalnie jest poprawne.
Ja wolę uważać element LUT5 za pamięć o pięciu wejściach adresowych i jednobitowym wyjściu.
Czyli kiedy podłączymy do wejść dowolną kombinację sygnałów, to zaadresujemy jedną z 32 (2^5) komórek pamięci i dostaniemy jej wartość na wyjściu.
Komu które tłumaczenie bardziej odpowiada, to kwestia gustu, a o gustach się nie dyskutuje.
Tak, czy inaczej, 32 jednobitowe wartości da się zapisać jako 32-bitową liczbę binarną, i taki sposób przyjęto dla wygody, a odpowiednią wartość można wyliczyć z tablicy na linkowanej stronie.
Element LUT5 jest nie tylko elegancki, ale i wygodny, bo nie trzeba niczego negować, ani w inny sposób kombinować z bramkami logicznymi.
Spróbuj swój kod przepisać na cztery bazowane osie, to zrozumiesz...
I to by było na tyle.

drzasiek90 · Post napisał: **drzasiek90** » 27 lut 2024, 09:29

tuxcnc pisze: ↑
27 lut 2024, 08:55
No to je przygotuj i sprawdź, bo to Tobie jest ono potrzebne, a mi nie.

Nie jest mi potrzebne, ponieważ działające rozwiązanie już mam.
To ty chciałeś pokazać rozwiązanie "właściwsze".
Najpierw pokazałeś niewłaściwe rozwiązanie.
Szkoda, że dopiero na 3 stronie zrozumiałeś o co chodzi w problemie z bazowaniem.
Mógłbyś zaoszczędzić nam kupę złośliwości, jaką wylałeś tu od początku.

tuxcnc pisze: ↑
27 lut 2024, 08:55
Wracając do twojego kodu, to jest on błędny w samym założeniu.
Tak naprawdę, to sygnał bazujący może być podłączony na stałe do odpowiednich pinów HAL od bazowania osi, a odcinać na czas bazowania trzeba sygnał podłączony do pinów HAL od limitów.

Zgadza się.
Ale to nijak nie upraszcza tego rozwiązania. Nawet kod konfiguracji nie będzie krótszy.
Jedynie linia:

Kod: Zaznacz cały

net and2_1_out =>  joint.0.home-sw-in

zamieniona zostanie na:

Kod: Zaznacz cały

net both-home-xz =>  joint.0.home-sw-in

a linia:

Kod: Zaznacz cały

net and2_0_out =>  joint.1.home-sw-in

zamieniona zostanie na:

Kod: Zaznacz cały

net both-home-xz =>  joint.1.home-sw-in

tuxcnc pisze: ↑
27 lut 2024, 08:55
Czyli mój kod, do którego się tak uczepiłeś, jest prawidłowy, z tym, że załatwia on tylko bazowanie

A więc nie jest prawidłowy.
Albo inaczej, nie jesk kompletny. A nieprawidłowe jest stwierdzenie:

tuxcnc pisze: ↑
25 lut 2024, 19:47
Sprawę załatwia następujący wpis w pliku hal:

Bo nie załatwia. Co najwyżej częściowo.

Jeśli potrzebujesz program, który będzie otwierał klapę, wysuwał prowdnicę i zaświecał światło a dostaniesz program który tylko wysuwa prowadnicę, nie otwierając klapy i nie zaświecając światła, to czy jest on prawdiłowy?

Tak więc nadal jedyny zaprezentowanym tutaj działającym rozwiązaniem jest to, które przedstawiłem w pierwszym poście.

tuxcnc pisze: ↑
27 lut 2024, 08:55
więc potrzebujesz dopisać kod blokujący zadziałanie limitów, wszystkich na raz, bo one i tak nie biorą udziału w bazowaniu.

Ale co to zaoszczędzi?
Teraz używam 2 komponenty and2 blokując działanie limitów w przypadku bazowania innej osi.
Jeśli użyję jednego komponentu and2 blokując limity nielależnie która oś się bazuje, to będę musiał i tak użyć komponent or2 aby podłączyć sygnały informujące o trwającym bazowaniu na jedno wejście and2 (to dla 2 osi)

tuxcnc pisze: ↑
27 lut 2024, 08:55
sygnał wejściowy jest odłączany od pinów HAL od limitów, na czas bazowania dowolnej osi.

To jest tak włanie napisane.

tuxcnc pisze: ↑
27 lut 2024, 08:55
Spróbuj swój kod przepisać na cztery bazowane osie, to zrozumiesz...

Ale ja to bez tego rozumiem.
Natomiast zaproponowałem rozwiązanie dla konkretnego problemu, nigdzie nie twierdziłem, że jest uniwersalne.

forestgril · Post napisał: **forestgril** » 27 lut 2024, 19:44

tuxcnc pisze: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.

Myślę, że To zasadniczo jest prawdą, natomiast jeśli wiemy, że wywaliła na przykład krańcówka osi X lub Y i nasz drogocenny frez jeszcze się obraca głęboko w materiale, to może wypadałoby szybko z niego wyjść (oś Z szybko w górę albo w dół), żeby go nie wypaczyć albo nie złamać. Może są też inne sytuacje, ale nie chce mi się kombinować

drzasiek90 · Post napisał: **drzasiek90** » 27 lut 2024, 20:04

Natychmiastowe zatrzymanie maszyny to najlepsze co można zrobić. I to także zazwyczaj uratuje "drogocenny" frez

Jeśli którakolwiek z osi znajduje się w sytuacji awaryjnej, trzeba sprawdzić co się stało a nie pozwolić maszynie ruszać innymi osiami.
Nie kombinuj

qqaz · Post napisał: **qqaz** » 28 lut 2024, 00:15

drzasiek90 pisze: ↑
27 lut 2024, 20:04
Nie kombinuj

kombinuj, kombinuj tylko z tuxkiem się nie wdawaj w przepychanki.
jednym z oczywistych ruchów jest programowy zjazd na "bazę" G53. Gdy za blisko to wpakuje się na limity.

drzasiek90 · Post napisał: **drzasiek90** » 28 lut 2024, 07:31

qqaz pisze: ↑
28 lut 2024, 00:15
jednym z oczywistych ruchów jest programowy zjazd na "bazę" G53. Gdy za blisko to wpakuje się na limity.

Nie zrozumiałem o co w tych 2 zdaniach ci chodziło.
Mam je interpretować jako jedną wypowiedź, czy każde zdanie osobno? Bo nie mogę sensu złapać

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

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

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

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

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

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

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

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

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

Lampka projekcyjna STARRY SKY USB

Adapter przedłużka ER16-ER16

Lampka projekcyjna STARRY SKY USB

Adapter przedłużka ER16-ER16

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej