MlKl pisze:Kotku - a kogo obchodzi, co ciebie akurat interesuje, a co nie? Ważne jest to, że ani Piko, ani Mach ani żaden inny znany mi program na gołym PC nie dorównuje LinuxCNC. Już wcześniej pisałem, że porównywać można tylko porównywalne.

Jak miło...
Jeśli Ciebie nie obchodzi, to po co się do mnie odzywasz? Na dodatek nie potrafiąc udzielić odpowiedzi?
Wszystko jest porównywalne, co zostało użyte do tego samego celu. Nie ma sensu porównywać możliwości terenówki ze stałym napędem na 4 koła do Golfa. Ale jeśli ktoś zada pytanie, o właściwości trakcyjne na asfalcie, spalanie na autostradzie przy 120km/h, czy pojemność kufra, to jak najbardziej można porównywać

MlKl pisze:Drwina z kogoś, czyją jedyną winą jest to, że jest od ciebie uboższy, i radzi sobie przy użyciu dostępnych mu środków, zamiast oczekiwać na twoją łaskę, nie jest w żadnym przypadku godna pochwały. Dumny jesteś z siebie?

Widzę że już sobie wypracowałeś bardzo konkretny profil mojej osoby. Tyle zachodu... Jestes go absolutnie pewien?

MlKl pisze:LinuxCNC jest jedynym programem, który bez żadnej zewnętrznej protezy potrafi obsługiwać maszynę CNC w czasie rzeczywistym.

A mach 3 nie?

Panowie, trochę zrozumienia dla tego co piszecie. Jeśli jitter, czyli DRŻENIE sygnału taktującego wysuw danych do portu ma 50us, to znaczy że maksymalna i to teoretyczna częstotliwość wysuwu danych wynosi ZALEDWIE 20kHz. A to z kolei oznacza możliwość wysyłania impulsów co najwyżej 10kHz.

Sam sterownik portu typowego równoległego, nie powoduje fluktuacji czasu na tak dużym poziomie. Najprostszy sterownik LPT to zwykła brama cyfrowa. Tam rządzą sygnały sterujące na poziomie pojedynczych nanoseund. Nie ma bufora typu FIFO jak na porcie szeregowym.
Dalej, port LPT podpięty jest bezpośrednio pod magistralę systemową I/O, np przez złącze PCI. Tam też fruwają megaherce a nie kiloherce. Wcześniej podawałem przykład sprzed lat, pecet 486 czytający port prawie 500kHz REAL TME bez problemu w przedpotopowym środowisku windows, z działającymi aplikacjami, ekranem, myszą, klawiaturą i wszystkim pozostałym.
Jeśli LinuxCNC jest w stanie pisać i czytać porty w takim żółwim tempie, to żadna magiczna karta tu nie pomoże. Może ew "wygładzić" ten nieszczęsny jitter i rozdzielić szeroką magistralę PCI na więcej linii I/O. Ale jeśli to ma być system czasu rzeczywistego, czyli bez buforowania, to PRĘDZEJ DZIAŁAĆ PRZEZ TO NIE BĘDZIE. Nie róbcie ludziom wody z mózgu.
Jeśli Linux CNC jest kompletnym zmodyfikowanym systemem operacyjnym a nie aplikacją, to ma pod sobą tylko BIOS-a. Czyli "rządzi sprzętem". Ba, nawet może BIOS-a zmodyfikować żeby wycisnąć z hardware dużo więcej w pewnych pożądanych kierunkach.
Prawda jest inna - TO JEST BADZIEW jeśli chodzi o prędkość. Nie dorasta parametrami do pięt ogólnodostępnym driverom osi po 200zł. Owszem, w tokarce się sprawdzi.
Mógłby być znacznie lepszy i nie byłoby tej głupiej dyskusji, i udowadniania jakie to gumofilce są eleganckie (bo tylko to mam, a to co mam JEST eleganckie, i basta). Tylko musieliby się zająć jego poprawieniem zawodowcy a nie amatorzy. To Wy macie problem. Prze gardło Wam nie chce przejść stwierdzenie "tak, to jest bardzo wolny system i choć w pewnych zastosowaniach się sprawdza, to do wielu rzeczy się raczej nie nadaje". Nic do tego nie ma co kto ma i na co go stać. Rozmawiamy o technice a nie o pieniądzach.
Z mojej strony to tyle w tym temacie

Miki, Piko nie jest moim ulubionym. Kupiłem go bo podobało mi się podejście autora do projektu, interfejs, 4 osie, i ogólnie to, że ma dokładnie to co potrzebuję. Ani mniej ani więcej, zasadniczo. Zastanawiałem się nad produktami z Białegostoku, ale były znacznie, znacznie droższe i nie dawały mi nic ponad to co było mi potrzebne. A jeszcze trzeba by było za Macha dopłacić. Za Piko, czyli fajny program z gotowym sprzętem i izolowanym portem komunikacyjnym USB, który ma KAŻDY pecet w odróżnieniu od LPT, zapłaciłem tyle co za samą licencję do Macha. Gdybym potrzebował czegoś "lepszego" do lepszej maszyny nie plotera za mniej niż 20 tysięcy złotych, bardziej wymagającej dla sterownika, to pewnie bym Piko nie kupił. Ale nie potrzebowałem, więc...
Tyle w kwestii wyjaśnienia.

Ja zadałem proste pytanie. Nie interesuje mnie ani co może linuxCNC sterować przez rs-a ani co może zrobić gdy go położyć na jakimś ew dedykowanym pod niego sprzęcie czy z kartami kosztującymi tyle co używany pecet. Chociaż czemu nie, też się chętnie dowiem (i na pewno inni też będą niejednokrotnie tym zainteresowani). Ale przede wszystkim, co może linuxCNC na "zwykłym" współczesno-starym pececie z magistralą "tylko" 100MHz. Ktoś mi odpowie?

P.S.
Cały czas jestem częstowany epitetami, też, UWAŻAM, sobie mogę sobie pozwolić na drwinę z tego co mnie nie od dziś i nie od miesiąca bawi, chyba?

Ha, ha, koła do samochodu bez samochodu to tylko 4 żałosne kawałki gumy naciągniętej na metalowe foremki.
Miki, miej litość nade mną i szacunek do siebie. Piko to program + sterownik, RAZEM. To że program działa bez sterownika, to ma służyć dla ewentualnych nowych klientów, żeby mogli pomacać. Nie używaj argumentów rodem z przedszkola, grupa maluchy.

Markcomp, tux, mnie nie interesował w pytaniu powód czy uzasadnienie (dlaczego jest marnie), tylko właściwość końcowa. Ani też dodatkowe możliwości, bo te się zmieniają z wersji na wersję, ani porównanie z innymi systemami bazującymi na tym samym sprzęcie.
Rozumiem, że potwierdzacie, że gwarantowana częstotliwość step to 5kHz a uzyskiwalna to 12kHz? Czy jednak druga opcja: 10kHz i 50kHz? Pytam, bo Wy wiecie a ja nie.
czy po zainstalowaniu tych super portów częstotliwość step wzrośnie? Ile razy?

Kamar, Ty już napisałeś wcześniej, że się nie znasz, więc Ciebie nie pytam

251, co pokręciłem? Opieram się na tym co napisał markcomp77 a potem tux. Któryś ściemniał? Obaj?
Wytłumacz mi to jak elektronikowi, bez zbędnych słów, w jednej linijce, oszczędzając naftę. Z jaką gwarantowaną częstotliwością i z jaką maksymalna częstotliwością linuxCNC potrafi zmienić stany na portach pecetów. Oraz odczytać stany na portach
Bardo proste pytanie chyba? Z odpowiedzi wyniknie wszystko.

markcomp77 pisze:

tuxcnc pisze:około 12 mm.

.... jak to założyć na wałek 14mm?

czy linuxCNC nie potyrafi obsłużyć enkoderów innych niż kwadraturowe? Przecież można zwiększyć średnicę. Nawet na upartego można nie robić symetrycznych otworów i przerw.
Tux, w kwestii prędkości portu. To wcale nie usprawiedliwia linuxaCNC. Co to jest za średniowieczne ograniczenie, do 50 kHz. Najpopularniejszy w świecie M542 można ustawić na 25000 impulsów na obrót. To daje 250k impulsów/sek przy 10obr/s czyli konieczność aktualizacji wyjść portu 500kHz.
A jeśli linuxcnc zapewnia zmiany stanów na porcie nie mniej niż 10kHz, czyli nawet 50 razy mniej, to znaczy że dla maszyny która może szybko jeździć w G0 nie można ustawić mikrokroku z podziałem mniejszym niż... 2, bo 4 może być już za dużo! Chyba że jednak w specyfikacji jest niedopowiedzenie, i 10kHz to minimalna gwarantowana prędkość STEP. Ale to i tak STRASZNIE MAŁO i bezpieczny mikrokrok można ustawić na zaledwie 5.

Tylko nie pisz, że trzeba kupić szybszy komputer, bo każdy pecet młodszy niż 15-letni jest sprzętowo aż nadto szybki. Ani tym bardziej że po co podział kroku większy niż 2 czy 5. Podział kroku dużo większy niż 2 jest bardzo wskazany i im większy tym lepszy. 8 to absolutne minimum, żeby nie MUSIEĆ walczyć z rezonansami silników.

"Głupi" PikoCNC napędzany jednoukładowcem za 3$, jest w stanie kontrolować 4 silniki z prędkością step 120kHz. A słynny linuxCNC, owoc zwojów mózgowych genialnych (choć nie zaakceptowanych przez świat i często otoczenie) internautów, mający do dyspozycji złożony system i procesor ze potężnym rdzeniem, ledwie dycha?

Kicha straszna. Do tej pory uważałem linuxaCNC za ciekawe alternatywne, choć upierdliwe i trudne do zaakceptowania przez kogoś kto ma nawyk stosowania dedykowanych układów rozwiązanie. Ale inność trzeba akceptować. Teraz jednak widzę, że to po prostu rozwiązanie popularne na sposób typowo polski - bo tanie. I to tyle. Jak buty z tektury z supermarketu.
Nie pisze złośliwie, jestem zupełnie szczerze rozczarowany tym, czego się dowiedziałem dzisiaj.
Nie da się czegoś z tym zrobić? czy ta żenada wynika po prostu z właściwości "jądra"?

W porywach 50kHz czytania na porcie równoległym??? Co to ma w ogóle być?

Nie święci garnki lepią, ale od tego wymyśliliśmy postęp techniczny, żeby się nie cofać do lat 80-tych czy wcześniej. W żaden sposób nie zmajstrujesz domowymi metodami sensorów do enkodera o klasie choćby zbliżonej do tego scalonego A przy tym urobisz się po łokcie. Za 15zł. Ech.
W mechanice to różnie bywa. Ale w elektronice pewnych rzeczy nie robi się "na piechotę" bo nie warto a nawet w absolutnie żaden sposób nie da się zrobić. I wcale nie mówię tu o okładach wielkiej skali integracji, bo to wówczas oczywiste.

Najprościej to jest kupić gotowe rozwiązanie, dostępne za niewygórowaną cenę, a nie rzeźbić ułomne substytuty jak w sąsiednim wątku.

Kilkanaście lat temu miałem taki program do peceta pod windows, który był analizatorem stanów logicznych. Taka zabawka radioamatorska, ale użyteczna w prostych sprawach. Wejściem był port równoległy. Z wtyczki LPT wychodził kabelek rozdzielający się na 4 sondy i masę do nich. Na pececie 486, bodaj pod win95 prędkość próbkowania była prawie 500kHz. Do próbkowania wspomnianego enkodera optycznego na pełnej jego prędkości wystarczy 80kHz a nawet mniej.

Oczywiście miało być "z kontrolą kierunku".
Ja nic innego nie napisałem. Enkoder zaprojektowany na wejściowe 150lpi daje na wyjściu 600ppi. Czyli przy katalogowo zalecanej tarczy 11mm i 360 liniach na obwodzie daje fizyczną rozdzielczość 1/4 stopnia kątowego.
Przy niepoprawnym formacie wejściowym, istotnie różnym od zalecanego, enkoder można wykorzystać praktycznie tylko jako źródło 2 sygnałów kodujących ilość impulsów (lub zmian gdy okna i przesłony są jednakowe) i kierunek. Jeden sygnał traktuje się jako źródło impulsów zliczanych, a fazowe przesunięcie (dowolne, byle znak był poprawny) jest sygnałem uzupełniającym dla określenia kierunku. Bo oczywiście nie jest to już enkoder kwadraturowy. Ale nadal jest to działający enkoder. Zależy co jest potrzebne i co jest wykorzystywane przez współpracujący układ.
Mówimy tym samym.

Raczej się opłaci kupić pojedynczy gotowy układ niż kombinować z instalowaniem szczelinowców, ich wzajemnym położeniem itd. nawet za 25. Co to jest 25zł gdy przyniesie oszczędność co najmniej godziny pracy i dodatkowo zagwarantuje pewność działania? Nie uzyskasz odpowiednika 150lpi (kwardaturowo 600ppi) ręcznie rzeźbionym układem, chyba że będzie przeskalowany kilkakrotnie.

Jeśli chodzi o sam sygnał kwadraturowy, to jego dokładność fazowa jest wymagana wtedy, gdy chcemy wykorzystać również stany pośrednie albo jeszcze dokładniej - momenty wystąpienia zboczy. Albo dynamicznie, przy stałej prędkości ruchu, jeszcze bardziej podnieść rozdzielczość.
W przypadku zwykłego zliczania z kontrolą prędkości, to nie ma znaczenia czy offset kątowy będzioe 90 stopni czy 5 stopni, byle miał zawsze ten sam znak. Czyli mniej lpi niż 150 może bezpiecznie być.

To prawda.
Aczkolwiek przesunięcie fazowe nadal powinno działać i powinno dać się spokojnie odczytać kierunek z tego. Kwestia urządzenia które będzie interpretowało sygnały.
Niebezpieczeństwo jest inne. Przesłona powinna być bardzo cienka. Albo fotoklisza albo (lepiej, bo trwałe w trudnych warunkach) z kolorowej blachy fototrawionej czy jeszcze lepiej wypalane laserem z cienkiej sprężystej nierdzewki. W każdym radzie bardzo równe. Bo w przeciwnym przypadku może pojawić się błąd fazy, czyli błąd kierunku.

Jeszcze na jedno trzeba uważać. jeśli maksymalna obroty silnika wyniosą 10/sekundę a zalecana częstotliwość maksymalna pracy enkodera wynosi 20kHz, to znaczy że na jeden obrót nie może przypadać więcej niż 2000 impulsów. Z kolei 2000 impulsów można zrobić na tarczy o średnicy nie mniejszej niż 10cm, żeby czujnik działał