Akurat. Ty się przypieprzasz nawet do rzeczy których nie ma.
Np. często piszesz autorom tematów, po tym jak odpowie im kilka osób: "nie słuchaj głupot".
Ale jak się dopytujemy gdzie te głupoty napisaliśmy, to stwierdzasz że nikomu głupot nie zarzucałeś, a jedynie uprzedzasz autora żeby głupot nie słuchał. Czyli niby piszesz prawdę, tylko na cholerę (skoro głupoty się nie pojawiały w temacie) to nie wiadomo. Równie dobrze mógłbyś pisać żeby nie wlewać benzyny do diesla. Racja, ale jaki to ma związek z tematami tu na forum?

Mało jest maszyn 5-osiowychj na LinuxCNC, bo taka maszyna jest trudna do zbudowania mechanicznie.
Ale nie ma żadnych przeszkód żeby LinuxCNC czy dowolny inny amatorski program obsługiwał więcej jak 3 osie.
Taki program tylko wykonuje g-kod, a nie generuje go.
W 5-ciu osiach problemem jest wygenerowanie ścieżki, a nie jej wykonanie.
Inna sprawa czy tak wiele osi jest w ogóle zaimplementowane. No bo jak nie, to nie można ich tylu użyć.

tuxcnc pisze: ↑

15 wrz 2024, 21:17

atom1477 pisze: ↑

15 wrz 2024, 20:45

Pamiętaj że majsterkowicz niekoniecznie będzie przestrzegał procedur czy przepisów BHP.

Mylisz pojęcia.
Majsterkowicz, to ktoś, kto ma satysfakcję z własnoręcznego wykonania czegoś.
Majsterkowicz nie znaczy partacz, druciarz, czy też po prostu debil.

Nic nie mylę. Napisałem "niekoniecznie", a nie "nigdy".

drzasiek90 pisze: ↑

15 wrz 2024, 21:18

No ale co konkretnie tracę?

Zabezpieczenie przez ruchem w złą stronę po wyłączeniu krańcówek w celu zjechania. Pamiętaj że krańcówki programowe (nazwijmy je robocze) wtedy nie działają (skoro maszyna utraciła współrzędne bazowe).
Nie ma co dalej bić piany. Każdy przedstawił swoją opinię i oczekiwane funkcjonalności. I tyle.

drzasiek90 pisze: ↑

15 wrz 2024, 21:05

Ja mam tak zrobione i żadnej funkcjonalności nie tracę.

Tracisz, tylko nie uznajesz tej funkcjonalności za istotną. Albo nawet w ogóle jej nie widzisz.

drzasiek90 pisze: ↑

15 wrz 2024, 20:44

Nie sądzę, aby o to mu chodziło.

Takie są fakty, a z faktami się nie dyskutuje

tuxcnc pisze: ↑

25 wrz 2023, 15:07

atom1477 pisze: ↑

25 wrz 2023, 14:49

Rozmawiamy o tym co ma się dziać podczas ręcznego wyjeżdżania z tego najechania, w trybie serwisowym. Tu ma być zablokowany ruch w kierunku kolizji. Aby możliwy był wyłącznie zjazd, a nie dalszy najazd.

Dlaczego zakładasz że serwisant jest debilem i nie będzie wiedział w którym kierunku pojechać?
Serwisant odetnie/zewrze krańcówki, albo uruchomi maszynę z innym plikiem konfiguracyjnym.
Ty natomiast ewidentnie chcesz przekombinować, tak żeby to samo połączenie z tą samą konfiguracją, raz działało tak, a raz inaczej. No po prostu tak się nie da.

I jeszcze to:

tuxcnc pisze: ↑

26 wrz 2023, 05:49

Najprościej będzie chwilowo odłączyć jeden kabelek żeby zjechać z krańcówki, albo maszynę wyłączyć i włączyć ponownie, ale z innym plikiem konfiguracyjnym, gdzie nie będzie wpisów dotyczących krańcówek.

A tego nie negowałem:

drzasiek90 pisze: ↑

15 wrz 2024, 20:49

Mi chodziło tylko o pokazanie, nie ma potrzeby marnowania aż tylu wejść na krańcówki, nawet jeśli dostępnych jest wiele.

Mówiłem tylko że to się odbywa pewnym kosztem (zmniejszeniem funkcjonalności).

Pamiętaj że majsterkowicz niekoniecznie będzie przestrzegał procedur czy przepisów BHP.
Więc to czy zrobi analizę po awarii, zależy tylko od jego widzimisię. I jakbyś krańcówek nie podłączył, to i tak może zjechać bez analizy (przekabelkować i zjechać). Ale też może zrobić analizę mimo że krańcówki będą kierunkowe i nieblokujące.

drzasiek90 pisze: ↑

15 wrz 2024, 20:33

Nie chodzi o blokowanie zjazdu z krańcówki.

tux-owi właśnie o to chodziło.
Tak to opisywał w poprzednim temacie (zjazd miał być możliwy dopiero po tymczasowym przerobieniu kabelkologii, i jednocześnie nie zapewniał bezpiecznego zjazdu).
Nie nie tego że maszyna ma się zatrzymać do zadziałaniu którejkolwiek z krańcówek. Użycie niezależnych krańcówek zamiast sześciu podpiętych pod to samo wejście nie zmienia przecież tej sytuacji. Nadal maszyna może się zatrzymywać trwale. To co sterownik z tym zrobi to przecież już tylko sprawa programowa.

A miałem napisać że zaraz się odezwie ten co skrytykuje takie rozwiązanie (już w innym temacie krytykował). Jak widać nie zdążyłem.
A prawda jest inna. Takie coś co opisał tux może i ma sens w maszynie profesjonalnej używanej w firmie. Gdzie po awarii zjazdu będzie dokonywała inna osoba.
Ale tu mówimy o sterowniku dla majsterkowiczów, którzy będą tego używali na samodzielnie zbudowanej maszynie (a przynajmniej samodzielnie zCNCowanej).
W takim przypadku majsterkowicz jest jednocześnie konstruktorem, użytkownikiem jak i serwisantem.
A co za tym idzie nie ma powodów żeby mu blokować możliwość łatwego zjazdu z krańcówki. I to jeszcze w taki sposób który zwiększa zagrożenie dla maszyny (wprawdzie blokuje zjazd od razu, ale po odblokowaniu pozwala jednak jechać w dwie strony). Jakby nie można było zrobić jednocześnie jednego i drugiego (gdzie maszyna po awarii się blokuje i wymaga "wezwania serwisanta", ale po odblokowaniu pozwala zjechać jedynie w prawidłową stronę).

drzasiek90 pisze: ↑

13 wrz 2024, 20:50

Ja mam komputer, na którym ustawiam okres bazowy 30 us, czyli sygnał kroku z okresem 60us (30 góra, 30 dół)

Pytanie z ciekawości: czy LinuxCNC przesyła informację o okresie bazowym do tego kontrolera?
Tak żeby kontroler potem mógł sam się taktować wiedząc jaki jest okres?

Jakiej szybkości można się spodziewać po takim kontrolerze? (STEP/DIR)
Bo z tego co rozumiem, jest to kontroler, ale nie "kontroler ruchu".
Czyli nie wykonuje komend ruchu, tylko przekierowuje stany pinów generowane na CPU kompa.