HARVIE: tak vymyslet si vlastni protokol presne podle potreb je lepsi reseni nez se snazit s problemy pouzivat neco co ma slouzit ponekud trochu k necemu jinemu a stejne si potrebne prikazy vymyslet.
Kdyz se kouknes na g kody pro smoothieboard, tak zjistis ze si jich vetsinu autori sami vymysleli a nejsou kompatibilni vubec s nicim a s g kodem jakozto s RS274D to moc spolecneho nema a pak nema smysl drzet se g kodu jako standardu protokolu kdyz k tomu vlastne sami jako ke standardu nepristupuji.
u soustruhu je leccos o hodne jinak, treba radiusova komenzace spicky, delkove korekce atd. ktere implementovane pro frezku na soustruhu fungovat nemuzou. Zatimco na frezce se programuje draha stredu nastroje, pripadne kontura a draha je kompenzovana ekvidistantne tak u soustruhu se programuje draha spicky noze a komenzace radiusu uz ekvidistanta neni. Cykly funguji jinak a nektere kody pro frezku funguji uplne jinak nez pro soustruh. Kdyz se bez toho obejdes tak to asi pouzit lze.
vice os je sice hezkych ale co s nimi chces delat a jak je chces ridit/ovladat? uz u 4 os pro rotacni obrabeni potrebujes bud inverse time feed nebo aby to umelo pri minutovym posuvu rychlosti kompenzovat samo podle smeru pohybu jednotlivych os a prumeru na kterem se nastroj pohybuje a nic z toho jsem ani u grbl ani u smoothieboardu nenasel.
nicmene vsichni svorne taji rychlost zpracovani, kolik radku g kodu/s zvladnou zpracovat. Asi si to budu muset poridit a pohrat si s tim (jako bych uz ted nemel frontu takovych vecich dost dlouhou :)). Ale aspon jsem dohledal delku look ahead a max kHz abych si udelal nejake srovnani.