LinuxCNC na USB - Poszukiwane chętne osoby do testu

drzasiek90 pisze: A więc możesz mieć do 12 wyjść i/lub do 17 wejść.

czyli jakaś optoizolacja we własnym zakresie skoro wejście może być wyjściem .

No port lpt. To nie jest płyta główna tylko port lpt dla linuxcnc.

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.

Frustracja cię ogarnia?
Napisałem dokładnie to, co to oznacza.
To nie jest port LPT dla systemu, to jest port lpt dla konkretnego oprogramowania, dla konkretnej konfiguracji.
Z punktu widzenia linuxcnc to urządzenie widoczne jest jako port równoległy i obsługiwane jako port równoległy.
Obsługiwane jest bezpośrednio z drivera hal portu równoległego.

tuxcnc pisze:To jest proteza portu, która może być wystarczająco użyteczna do określonego zastosowania

Tux czy tobie to się coś porobiło po tym własnym a właściwie ściąganym pomyśle . Jak już plujesz jadem do rób to chociaż w słoik można by z tego zrobić surowicę Większość użytkowników nie wie i nawet nie chce wiedzieć jak to działa ma spełniać warunek , zastąpić port lpt gdy go nie ma tylko i wyłącznie dla linuxcnc !.Lepiej pisz co z tym twoim Colorcnc brak czasu czy pomysłu jak to ruszyć dalej

Dodane 1 minuta 1 sekunda:

tuxcnc pisze: karty FPGA podłączane do LPT (zobacz choćby Pluto-P).

tylko się o tym nie rozpisuj bo znów temat utknie

Po zaciętej walce, rozważam rezygnację z interfejsu ethernet w tym urządzeniu.
Podczas, gdy na USB działa zawsze stabilnie z krótkimi czasami buforowania, przez ethernet już tak kolorowo nie jest.
Mimo, że ethernet w linuxie ma być RT a USB nie, to zachowanie przy komunikacji przez ethernet jest mocno nieprzewidywalne.
O ile wysyłanie działa dobrze i deterministycznie, ramki zawsze wychodzą i dochodzą do urządzenia na czas, to z odbiorem (na komputerze) są problemy. Gdy mam ustawiony czas buforowania np. na 400us, to zdarza się, że raz na kilka sekund przez około 2-3 ms nie przychodzi żadna ramka a dopiero później otrzymuje wszystkie zaległe. Wygląda na to, że jest tu jakiś problem na styku system-karta sieciowa-sterownik. Próbowałem wielu rozwiązań mających na celu poprawienie przydatności karty sieciowej dla zadań RT ale niewiele to pomogło. Testowałem na różnych systemach (tych gotowych jak i z własnym kompilowanym jądrem RT) i na różnych komputerach. Raz jest lepiej, raz gorzej ale ciągle nieprzewidywalnie. Zapewne odpowiedni dobór sprzętu + karta sieciowa/sterownik oraz odpowiednia jego konfiguracja dałby efekty do przyjęcia, jednak to jest zła wiadomość, ponieważ urządzenie z założenia ma być łatwe w instalacji i użyciu a to nieco sprawę komplikuje.
Nie przekreślam całkowicie ethernetu, ponieważ zależy mi na tym, aby to właśnie tego interfejsu użyć, ale już powoli wyczerpują mi się możliwości i pomysły.

A wifi na płycie głównej jest wyłączone?

Wyłączam wi-fi, co prawda nie w biosie a w systemie. Spróbuję wyłączyć w biosie.

Testowałem wyłączanie wifi w biosie ale nic to nie daje.
Trochę szukałem, gmerałem, informatyką się nie pasjonuję z punktu widzenia komputerów i systemu ale coś wygmyrałem.
Otóż sprawdziłem które przerwanie reprezentuje kartę sieciową i przez który rdzeń jest obsługiwane
(polecenie cat /proc/interrupts)
I okazuje się, że w moim 8 rdzeniowym procesorze, przerwanie numer 42 (od karty sieciowej) obsługiwane jest przez rdzeń numer 1. Ja mam odizolowane rdzenie 6 i 7 dla procesów RT a więc rdzeń 1 używany jest również przez system operacyjny stąd to opóźnienie.
Narazie zrobiłem przyfastrygowanie, taki drut aby sprawdzić i odizolowałem rdzenie 1, 6 i 7 a więc rdzeń obsługujący przerwanie 42 również jest wyizolowany.
Poprawiło to znacznie czasy i teraz najdłuższy czas pomiędzy odebraniem kolejnych ramek (wysyłanych do 400us) to około 600us, gdzie wcześnie zdarzały się czasy nawet rzędu kilku ms - nawet bywało 8ms.
Podjąłem próbę przypisania obsługi konkretnego przerwania do konkretnego rdzenia (wtedy nie musiałbym izolować tylu rdzeni) ale niestety ta próba się nie powiodła. Może coś robiłem źle, jeszcze popróbuję.