AKA_THE_A: kdyz se loze zakrije tak s to da, parkrat jsem to taky delal, ale hrdy na to nejsem . nikdy to nezakryjes uplne a dokonale. Brusky jsou na to konstruovane a brouseni oceli vetsinou probiha pod emulzi ktera to vsechno splavuje pryc, da se samozrejme brousit i bez, ale pak vysledek neodpovida usili (pri brouseni se brouseny kus od kotouce dost hreje, takze se zvetsuje, a nejvice se zvetsuje u kraju kde se nema teplo dal kam rozprostrit a jak se to zvetsuje vic u kraju nez uprostred tak vic na krajich ubrousis a misto toho aby jsi pak po brusce mel rovnou plochu tak to pak mas po vyhladnuti do kopce, a taky bez emulze to trva mnohem dyl. no to jsem trochu odbocil. a pro rypaly. ano litina a elektron se brousi ci jinak obrabi jedine na sucho.

jestli utavil nuz, tak nejspis proto, ze mel moc velke otacky a jestli to chtel jenom urizout, coz asi jo podle toho jak rez vypadal, tak moc nechapu proc to rezal na soustruhu ktery je podle toho co jsem v tom videu videl, bezpecne odepsanej. nevhodne rezne podminky utavi tvrdokovovy nuz i o automatovou ocel, lidi to radi podcenuji, ale rezne podminky, zvlast u odolnych materialu je naprosto zasadni dodrzovat, cim odolnejsi, tim mensi rezna rychlost, pri spravnych podminkach lze tvrdokovem triskove obrabet i materialy s tvrdosti 50HRC. pripadne se obrabi metodou HSC kdy ze stroje litaj horici spony, nastroj a zytek obrobku vsak zustanou studene.

pripadne jsou i dalsi vhodnejsi rezne materialy nebo metody rezani odolnych materialu. tez neni tvrdokov jako tvrdokov, pro ruzne urceni jsou i ruzne tvrdokovy a uz vubec nemluve o geometrii noze. da se rict ze zasadni je uplne vse, jak geometrie a tuhost stroje, spravne upnuti, geometrie noze, rezny material, rezne podminky a i rezna kapalina, jak je z toho jen jedna vec spatne, tak je spatne i vysledek a proste to nejde. automatove materiali odpusti temer vsechno, vetsina slitin hliniku tez, ale zarupevne a dalsi spec oceli, neodpousti vubec nic.

prasecit lze vzdycky, to umi kazdej, ono to jednou jde, pak to jeste jednou jde, pak treba jeste jednou.. jo pockat, ja si zkurvil stroj. zachazeni se strojem je k jeho zivotnosti dost zasadni, a je uplne jedno jestli to je cina nebo neco super hitech za desitky milionu, kdyz se clovek chova ke stroji slusne, vydrzi spolehlive a presne makat deset a vice let i blba levna cina.

zapomel jsem dodat, ze ten posledni zpusob mam nejradeji, protoze mi umoznuje z 1 pc ridit i vice stroju nez jen 1 najednou, cehoz i vyuzivam

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.