THERIDANE: to ale ten bottleneck zase moc daleko neposunes a zavedes uplne novy, sice zvednes max uzitnou frekvenci vystupu, ale nebudes ji vzavislosti na pozadavcich umet dostatecne rychle menit, protoze ji potrebujes menit nejlepe s kazdym krokem v ramci jitteru, tedy pro kazdy krok poslat i rychlost, kdysy jsem se o neco podobneho pokousel, pro zvoleny delkovy usek cca po 10 krocich, ktery mohl variovat jsem posilal jeho rychlost, a pro moc vysoke rychlosti to nefungovalo, tedy max mnou timto zpusobem dosazene max rychlosti a akcelerace byly takove, ze to nemelo smysl.
Delal jsem to hlavne pro to abych si mohl udelat libovolny prubeh rychlosti. prineslo to vic problemu nez uzitku a cele jsem to poslal k ledu, naskytlo se lepsi reseni, tak jsem to dal neresil.
Libovolny zadrhel na komunikaci znamena okamzite zastaveni bez rampy = ztrata kroku, uz se neda pokracovat. Problem je taky reakce na vstupy, napr referencni spinace, od sondy atd. kdy je potreba reagovat na zmenu stavu vstupu jeste pred vykonanim dalsiho kazdeho kroku, jinak krome samotne chyby ref. spinace nebo sondy, tam budes mit nativni chybu rostouci s rychlosti, proste nebudes umet zareagovat na vstup dostatecne rychle a bez citace polohy, tzn skutecne vykonanych kroku, ani nebudes vedet kdy a kde k aktivaci vstupu ref. spinace nebo sondy vlastne doslo. coz kdyz se dostanes vyhodne k poradne sonde, te bude pekne stvat.
coz je pri referenci osy, mereni nastroje, pripadne digitalizaci nebo mereni soundou naprosto zasadni. jak tak koukam na linuxcnc wiki a latency testu tak nejlepsi vysledky pri 1ms threadu je jitter kolem 4000-5000ns u LPT portu, u toho tveho reseni by se to melo zlepsit, ale zase na ukor rychlostniho rozliseni, ktery je pri vyssich rychlosti pohybu problem u krokacu, coz se obvykle resi tim, ze generovani pulzu kuli frekvenci dela nejake to fpga, aby byla co nejvyssi co driver jeste snese a nalezitym mikrokrokem, ktery skok ve frekvenci vlivem nizsiho rychlostniho rozliseni, se zmensuje s jemnejsim mikrokrokem. Stejny zpusob se domnivam ze pouzivaji mesa karty, ktere maji fpga na generovani pulzu a PCI pro komunikaci.
dalsi mozna cesta je do HW neposilat zmeny rychlosti, ale jen koncove body polohy, pripadne rychlost na koncovem bodu, pokud se zmeni a HW se stara o vse ostatni, tedy i o reakci na stavy vstupu, kdy je HW schopen reagovat na vstup s kazdym pulzem a chyba v komunikaci znamena jen to, ze se posledni odeslany bod odesles znovu a kdyz ne, tak po zpracovani vsech bodu v HW HW osy zabrzdi podle nastavene rampy do nulove rychlosti zcela bezpecne a po oprave komunikace z libovolneho duvodu, (vytazenej kabel, ruseni atd.) se da bezproblemu pokracovat dal, pokud k naprave komunikace dojde jeste pred zpracovanim prijatych bodu, tak ani nic nepoznas, muzes HW od PC klidne odpojit a zase pripojit a vubec nic se nedeje. navic do takoveho HW muzes ty koncove body posilat klidne i z telefonu, nebo cehokoliv, nemusi to byt PC, koncove body a jejich koncove rychlosti tam muzes poslat z cehokoliv. timto zpusobem pracuje napr i hw k 3d tiskarnam.