drzasiek90 pisze: ↑

12 cze 2023, 17:40

To (...) jest (...) port lpt dla linuxcnc.

Nie jest i nigdy nie będzie.
To jest proteza portu, która może być wystarczająco użyteczna do określonego zastosowania.
Port LPT w komputerze PC to kilka rejestrów, do których wpisuje się, albo czyta, kilka bajtów, co trwa kilka taktów zegara.
Port LPT w trybie ECP z DMA zapewnia prędkość transmisji rzędu kilku megabajtów na sekundę.
W LinuxCNC to co nazywasz "port LPT" to tylko jedno z wielu zastosowań portu LPT. Są też inne sposoby jego wykorzystania, na przykład karty FPGA podłączane do LPT (zobacz choćby Pluto-P).
Zapewne jest to wiedza niepotrzebna do twojego projektu, ale uważaj na to co mówisz, bo wprowadzasz ludzi w błąd.

drzasiek90 pisze: ↑

10 cze 2023, 08:13

Z tobą jest analogiczna sytuacja.

Nie, tylko tak ci się wydaje, bo masz problemy z elementarną logiką i wyciągasz generalne wnioski na podstawie trzeciorzędnych podobieństw.
Elementarna logika mówi na przykład, że każdy złodziej boi się że go okradną, ale to nie znaczy że każdy kto boi się kradzieży jest złodziejem.
Więcej tłumaczyć nie będę, bo i tak nie zrozumiesz...

tristar0 pisze: ↑

10 cze 2023, 06:59

A czasem nie napisałeś mu w swój specyficzny sposób używając słownictwa na tym forum ? > bo to by tłumaczyło czemu dostałeś bana.

Nie, to po prostu taki typ człowieka, że jak go nie pochwalisz to się obrazi...
Za pierwszym razem na uwagę że program nie działa tak jak powinien dostałem odpowiedź, że powinienem być mu wdzięczny bo on to robi za darmo... No i tłumacz kretynowi, że jak nie działa, to nie ma mowy o żadnych powodach do wdzięczności, bo i niby za co...
Wtedy trochę to przeżyłem, ale teraz nie robi to już na mnie żadnego wrażenia, no bo i cóż z tego że mnie zbanował, skoro jest idiotą, więc i tak nie ma mowy żeby się z nim dogadać...
Wielu ludzi tego nie rozumie, że wiedza i zdolności nie mają nic wspólnego z inteligencją...

drzasiek90 pisze: ↑

09 cze 2023, 22:23

Obecna wersja działa zarówno z USB jak i na ethernet. Testy z gwintowaniem i z opóźnieniami akurat były na USB bo mi tak wygodniej było. Tak, gwintowanie na sztywno było sterowane przez USB, które nie jest RT! A jednak się da.

Ostatnio prześladują mnie ludzie, którzy potrafią napisać skomplikowany program, ale nie potrafią zrozumieć rzeczy podstawowych, a jak im się wytknie kardynalne błędy to się obrażają...
A podstawy to są na przykład takie, że "u mnie działa" to nic nie znaczy i o niczym nie świadczy.
Na odwrót tak, jak nie działa u mnie, to na pewno jest spieprzone, ale tysiące godzin testów na moim komputerze z moim systemem operacyjnym i moim zestawem oprogramowania nie daje pewności że będzie działać u kogoś innego.
Właśnie miałem taki cyrk z geniuszem od LitexCNC. On sobie używa Debiana przez WSL2 na Windows. W sumie nic zdrożnego, ale jakimś dziwnym zbiegiem okoliczności jego kod nie działa na realnym Linuksie. Jak mu napisałem, że pisanie kodu na egzotyczną konfigurację jest stratą czasu, to się obraził i zbanował mnie na swoim Githubie... Cóż, dla zbyt wielu programistów dobre samopoczucie jest ważniejsze od jakości ich pracy...
Wracając do realtime, to ma on taką magiczną właściwość, że zależy wyłącznie od sprzętu. Bierzesz dobry komputer (żadnego laptopa !!!), instalujesz kernel RT, robisz isolcpus i MUSI działać każdemu i zawsze.
Natomiast USB nie jest RT, więc jest uruchamiane przez scheduler systemu z wszelkimi tego konsekwencjami. Możesz sobie testować u siebie do końca świata, a twój klient zainstaluje sobie program o którego istnieniu nawet nie wiesz, i mu się wszystko posypie...
Dlatego USB można sobie stosować do włączania chłodziwa albo lampy, ale nie do procesów krytycznych czasowo.

drzasiek90 pisze: ↑

09 cze 2023, 21:16

Ty od początku ten pomysł krytykujesz, dla samej zasady, żeby krytykować jak leci.

Nie pisz bzdur.
W LinuxCNC USB nie jest realtime, nigdy nie będzie, więc budowanie sterownika na USB jest głupotą w samym założeniu.
To są fakty, a nie moja opinia.
Natomiast ethernet jest realtime, więc sterownik oparty o ten sposób komunikacji nie tylko może poprawnie pracować, ale też znane są konstrukcje pracujące dobrze i stabilnie.
Odkąd przeszedłeś na ethernet przestałem ci pisać że to nie ma prawa działać, co najwyżej że możesz to zrobić lepiej.
To tak żeby była jasność.
Natomiast nie mam ani obowiązku, ani ochoty tłumaczyć się komukolwiek z tego co robię jako hobby w swoim wolnym czasie.
Nie ma żadnego powodu żebym się śpieszył z projektem sterownika na Colorlight.
Moje maszyny są skonfigurowane pod LPT i pracują prawidłowo.
Nie jest to rozwiązanie perspektywiczne, jak mi dziesięcioletni komputer padnie ze starości, to nie pójdę kupować dwunastoletniego, ale na razie działa, drugi stoi w rezerwie, więc pośpiechu nie ma.
Jak mam ochotę to coś z Colorlight, robię, a jak nie mam ochoty, to robię coś innego.
Na dzień dzisiejszy mam zainstalowany LinuxCNC 2.10 na Debianie 11, płytkę Colorlight 5a-75b z własnym firmware 24 wejścia, 32 wyjścia, z których część jest na sztywno przypisana do modułów stepgen, pwm, encoder i gpio. Pierwsze testy z analizatorem stanów logicznych wypadły prawidłowo i obiecująco. Jest napisana konfiguracja do frezarki, LinuxCNC uruchamia się prawidłowo, osie "jeżdżą", czyli widać step/dir na analizatorze. Do testów na realnej maszynie zastosuję CNC 3018, która stoi bezużytecznie. Jako drajwer krokowców posłuży CNC Shield od Arduino Uno (ma wyprowadzone wszystkie potrzebne sygnały na goldpiny).
Nie mam zielonego pojęcia kiedy się za to wezmę, ale zapewne zrobię sobie kilka dni przerwy, żeby mózg mi odpoczął, bo zmuszenie do pracy oprogramowania LitexCNC kosztowało mnie bardzo wiele wysiłku. Autor ma w projekcie straszny burdel, brakuje dokumentacji (albo całkiem, albo jest ale przestarzała), a sam ma jakieś problemy z głową i nie jestem w stanie się z nim porozumieć.
Tak więc działać będzie na pewno, ale konkretne parametry poznam dopiero w przyszłości.
To tak żebyś przestał mi wmawiać, że wiesz lepiej ode mnie co myślę i co robię.

A ten twój projekt, to jeśli masz ochotę, to go rób, tylko jak już będziesz go robił, to rób go dobrze.

drzasiek90 pisze: ↑

09 cze 2023, 20:33

Nie ma sensu z tobą rozmowa, bo przyszedłeś trollować z frustracji, że poległeś z colorcnc.
Ja ci pokazałem G33.1 na moim rozwiązaniu, czekam aż pokażesz to samo na colorcnc.

Z niczym nie poległem, a ty robisz z siebie idiotę.
W LinuxCNC to nawet takie cuda są możliwe :

EOT.

drzasiek90 pisze: ↑

09 cze 2023, 19:49

A gwintowanie na sztywno odnosi się do rodzaju ruchu synchronicznego w te i nazad, gdzie narzędzie sztywno prowadzone jest tą samą ścieżką a nie do tego ile linii g-kodu zajmuje.

To są herezje i kompletne bzdury.
Gdyby się dało, toby ludzie tak robili, ale się nie da, bo to jest niemożliwe.
Najwyraźniej nie rozumiesz nie tylko czym jest ruch synchroniczny, ale też nie rozumiesz jak działa g-kod, i pomimo braku wiedzy absolutnie podstawowej, bierzesz się za robienie sterowników CNC...

drzasiek90 pisze: ↑

09 cze 2023, 18:48

A jeśli będzie to taki sterownik, który umożliwia zrobienie to samo ale w 2 liniach G-kodu to już nie będzie na sztywno?
W moim rozumieniu gwintowanie na sztywno polega na tym, że narzędzie porusza się w jedną i drugą stronę po tej samej ścieżce gwintu, czyli gwintowanie i wycofanie po tej samej ścieżce bez względu na to, ile linii g-kodu to zajmuje.

Co się tak uparłeś wyjść na idiotę?

Mam wrażenie, że niczego nie rozumiecie i mylicie pojęcia.
Gwintowanie na sztywno polega na tym, że jedna linia g-kodu powoduje ruch narzędzia w jedną stronę, zatrzymanie wrzeciona i powrót narzędzia z powrotem na przeciwnych obrotach.
Tyle i tylko tyle !
Natomiast gwintowanie jako takie, to ruch synchronizowany, czyli określone położenie kątowe wrzeciona odpowiada ściśle określonemu położeniu suportu. na przykład jeśli nacinamy gwint o skoku 1,5 mm to 1000 stopni obrotu wrzeciona odpowiada zmianie pozycji narzędzia o 4,166666667 mm.
Ma się o tyle przesunąć, a nie jechać z wyliczoną prędkością.
Nie ma znaczenia czym obracamy wrzeciono (można silnikiem, można korbą, można ręką, itd.), oraz w jakim kierunku obracamy wrzeciono. Można sobie kręcić w te i wewte, a synchronizacja ma zostać zachowana.
Tak działa G33 i oparte na nim cykle.
Natomiast w amatorskich maszynach, pozbawionych odpowiednich narzędzi pomiarowych i wystarczającej mocy obliczeniowej, stosuje się różne, mniej czy bardziej udane protezy, które mają zastąpić brakujące narządy.
Taką podstawową protezą jest jeden impuls na jeden obrót wrzeciona. To może działać nawet dość dokładnie, kiedy wrzeciono ma dużą inercję a napęd duży moment. Jest jednak oczywiste, że to nie jest ruch synchronizowany, bo tak naprawdę to sterowanie nie wie w jakim położeniu jest wrzeciono, tylko się tego domyśla...
Zwiększając ilość impulsów na obrót zwiększamy dokładność pomiaru i sterowanie coraz więcej wie, a coraz mniej musi się domyślać, aż dojdziemy do momentu, gdy ruch jest faktycznie synchronizowany, z teoretyczną dokładnością wyższą od możliwej faktycznie dokładności obróbki.
Programowa kompensacja opóźnień w transmisji sygnału jest także protezą, która może działać wystarczająco dobrze, ale nie ma nic wspólnego z gwintowaniem na sztywno jako takim.

drzasiek90 pisze: ↑

08 cze 2023, 20:46

troll pisze: ↑

17 lip 2020, 21:03

A da się tym twoim pudełkiem zrobić G33.1 ?

Trollem to jest pajac, który wypowiedź z 17 lipca 2020 roku (prawie trzy lata temu) cytuje tak, jakby była powiedziana wczoraj i dotyczyła obecnego projektu...
Pomijając zupełnie fakt, że za takie chamstwo jak zastąpienie nicka inwektywą, to na porządnych forach dostaje się bana...

drzasiek90 pisze: ↑

10 lut 2022, 19:03

Tux nie wiem skąd u ciebie przekonanie, że jak wpadniesz na jakiś pomysł to on od razu jest genialny i należy każdy inny skrytykować a tylko twój jest jedynie słuszny i poprawny.

Moje pomysły nie mają tu nic do rzeczy, bo ja bym takiego gówna nigdy nie wymyślił.
Podsystem USB w Linuksie NIE JEST real time i to zamyka temat.
Natomiast jak ktoś chce to twoje cudo kupić, to niech sobie kupi, nie moja sprawa.

Po prostu nie rozumiem twojego uporu.
Napisałem Ci tylko, że zamiast kombinować jakieś idiotyzmy znane tylko z Windowsa, możesz napisać jeden program (nawet skrypt powłoki) na swój jeden komputer i wysyłać klientowi skompilowany program.
W dzisiejszych czasach, czy wysyłasz mailem 128 bajtów czy 128 kilobajtów, to niewielka różnica.
Przecież to Ty płaczesz że nie chcesz się użerać z klientami, no to daje Ci rozwiązanie, które możesz sobie nawet tak zautomatyzować, żeby za jednym kliknięciem wysyłać nową jeszcze lepszą wersję do wszystkich klientów.
Chyba sprzedajesz swój produkt za całkiem spore pieniądze?
No to jaki masz problem powiedzieć klientowi, że jak chce mieć aktualizacje, to niech sobie kupi ST-Link za pięć dolarów?

Wiesz, jak czytam jakie sztuczne problemy sobie robisz, to coraz bardziej wątpię w jakość twojego kodu...