poszukam

Znalazłem... <TUTAJ>

Czyli podsumowując w konsoli dajemy:
sudo adduser <the user you want to add> dialout
sudo reboot

Czyli dodajemy swoją nazwę użytkownika do grupy "dialout" i trzeba koniecznie z-bootować system (bez tego nie zadziała -sprawdziłem

Przed połaczeniem kabla piko działał normalnie, po połaczeniu strasznie zwolnił, potem sie zawiesił. Na pocztku ramek było ponad 100, puzniej skakały od ok 10 do 80 , po czym wszystko staneło. Diody na piko koło usb wogule nie migały.

Skoro w ogóle nie migały - to fizycznie nie było śladu połączenia.
Wczoraj też uruchomiłem piko pod ubuntu 13.04. Mam podobny efekt jak piszesz (z tym, że diody migają), ale tylko przy pierwszym uruchomieniu programu i próbie nawiązania połączenia ! Gdy się zamknie piko i załączy powtórnie program, komunikacja już śmiga aż miło &#8211; o co chodzi... nie wiem...

Jest jeszcze taki problem, że za każdym podłączeniem kabla USB zmienia mi właściciela linku do portu COM na roota i ręcznie muszę to przestawić w mc na moje konto gdyż inaczej piko nie widzi portu. Co z tym zrobić ???

To bardzo cenna informacja, z ta ilością wektorów na ramkę. Można sobie przeliczyć, jaki ustawić mikrokrok żeby nie było jakiejś hecy...

A co ma jedno z drugim wspólnego

Ale chyba nie tylko w tym problem. Pamiętasz, robiłem doświadczenie z klikaniem palcem w klawiaturę, i przy o połowę rzadszych ramkach, czyli tylko 30/s czy raczej AŻ, nie przechodziły do sterownika informacje o żądaniu ruchu osi. Wygląda na to, że kliknięcia powyżej pewnej prędkości, i to dużo mniejszej niż częstotliwość ramek, są gubione.

Pamiętam, robiłeś eksperymenty z printer portem po Lan-ie.
Zauważ, że jeśli miałeś 30f/s to sygnały z klawiatury w pesymistycznym wariancie wysyłane są z częstotliwością 15Hz! Cały myk jest tutaj, że dając szybkie impulsy z klawiatury czasami nie trafisz w &#8222;fazę&#8221; i puszczając klawisz odwołujesz ruch zanim ramka zostanie wysłana. Wystarczy, że trafisz z naciśnięciem w chwili gdy rozpoczęło się nadawanie nowej ramki (oczywiście jeszcze bez informacji o Twoim molestowaniu klawisza) teraz czekasz aż zostanie wysłana, a następnie czekasz aż przyjdzie odpowiedź, ale w tym czasie informacja, że był naciśnięty klawisz wyparowała gdyż go puściłeś. Tak więc nie ma tu mowy o gubieniu ramek itp. tylko... jak wyżej.

Można śmiało założyć, że średnia częstotliwość ramek na poziomie 60Hz może zostać zakłócona przez jakiś inny proces na pececie...

Nie może, spróbuj odpalając co tylko chcesz

..a transfer wychodził ok 4000cooord/s (zmieniał się dynamicznie)
czy jest to wartość budząca zaufanie?... dająca gwarancje płynności w dostawach wektorów?

Jeśli to prawda, to są wartości lepsze niż pod windą (gdzie standardem jest 62 ramki i 3000). Można jeszcze wizualnie zerknąć na dwie diody przy gniazdku USB powinny się świecić &#8222;nonstop&#8221; bez jakiegoś spektakularnego mrugania.

może Twórca na zlot zleci?

Chyba, że zapewnisz mu darmowy transport lotniczy Nawet do niedalekiego Poznania mało kiedy się wybieram...

Cosimo, ile MUSI być minimalnie ramek/s, żeby sterownik działał bez zacięć?

Wszystko zależy od tego z jakiej długości wektorów składa się program i jego prędkości (F) np. przy prędkości 400mm/m i &#8222;długich&#8221; (powiedzmy 5mm) wektorach to pewnie i jedna ramka/s by starczyła. Inna sprawa, że im szybszy transfer (a raczej &#8222;ping&#8221;) tym szybsza reakcja na przyciski joga.

Można przyjąć, że w jednej ramce idzie 25 wektorów, zatem łatwo policzyć na ile to starczy przy danej długości wektorów i prędkości jazdy.

ps.
O ku..źba 83 ramki/s - albo linux kiepsko liczy czas albo jest rewelacyjnie

PikoCNC potrafi działać pod Wine...

Ooo... Zerknij jeszcze w okienko monitora zakładka &#8222;sterownik&#8221; i zobacz co pokazuje parametr &#8222;Frame/s&#8221; (normalnie jest 62-63). To taki jakby "ping"