TEAPACK: Díky za radu - vůbec mě nenapadlo kouknout do dokumentace a hledat x102 card nebo něco podobnýho :D zjistit z čeho je to Hmi je těžký,musim zpětně zjišťovat,většinou to získám se slovy "na vem si to jestli se ti to hodí,jinak to jde do šrotu"

SALAM23: ten popis je označení svorkovnice ve výkresu... když najdeš nějaký schéma k tomu HMI, tak tam to bude popsaný k čemu že je dobrá X102 =) Ideálně to bude ve schématu od mašiny, ale nevím, jestli ti sdělili, z čeho to vykuchali....
Pokud to HMIčko bylo v soustruhu, tak by dva kabely mohly být k pravítkům, ale je to věštění...

Jeste se ke me dostalo jedno HMI - tentokrat trosku novejsi naslapanejsi model - urcenej 100% na rizeni 6 os - nastaveno v programu a pry by to melo zvladat ovladat 30 os?Coz nechapu. To jsem vykoukal v sofwaru co v tom je - otazka je,netusite nekdo co je to za karty vzadu "ty cerny popsany fixem" ?

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.

Az budu mit trochu casu, tak to zkusim naflashovat na esp32 co mam na stole a dopisu do bCNC podporu pro Serial over IP, aby to slo pipojit i bez USB...

Kdyz sme u forku GRBL, tak me docela zaujal port na ESP32 https://github.com/bdring/Grbl_Esp32



Samozrejme ESP32 ma bluetooth a wifi, takze pridali webovej xichtik:

HARVIE: ok nebudu se hadat,tak je to asi nejaky fork jak pises,ale vim z vlastni zkusenosti ze lze pres grbl ridit 4 osy - mam doma kompletne oziveny a nastaveny arduino pro 4 osy pripraveny na rezacku polystyrenu ,beha mi to na uno r3 + protoneer cnc shield v 3 i na mega 2560 + ramps 1.4 na klasickym grbl tusim 0,8c

SALAM23: Grbl je pro atmega328p, Arduino mega je ATmega2560. GRBL-Mega je fork naportovanej na arduino mega v ramci GNEA projektu.

cituji https://github.com/grbl/grbl/wiki
"Grbl is for three axis machines. No rotation axes (yet) – just X, Y, and Z."

HARVIE: to mega znamena ze grbl je nahrano na desce Arduino Mega tusim 2560 nebo tak nejak ,grbl je uplne klasicky ale 4 osy

SALAM23: no. to je GRBL-Mega, ne GRBL :-)

HARVIE:

Samozrejme tu duplikaci osy na 4tej driver si tam muzes najumperovat i s GRBL firmwarem... To je defakto jen kus dratu. To pouzivam...

SALAM23: myslim, ze si to pletes. GRBL umi 3 osy.
4 osy umi protoneer shield, coz je nejrozsirenejsi HW na kterym se GRBL pouziva. Ten firmware to ale nepodporuje. Nicmene jsou nejaky neoficialni forky, ktery to umi. Maj ale zas jiny omezeni.

HARVIE:grbl zvlada i 4 osy - tu 4 bud jako duplikat xyz nebo jako dalsi nezavislou A

JVCNC: a v jakym formatu bys posilal data tomu interpolatoru? bys musel vymyslet neco custom... jinak pokud vim, tak na hobby soustruhy se GRBL bezne pouziva... Pokud potrebujes vic nez 3 osy, tak existuje smoothie. Ma az 6 os, ma i rezim pro 3D tiskarny, atd... http://smoothieware.org/

HARVIE: ten interpret neni nutne realtime zalezitost, to je hlavne interpolace, rizeni rychlosti a reakce na vstupy, casto to neni ani interpolace ale jen generovani pulzu jako to napr dela LinuxCNC + mesa nebo mach3,mach4 + smoothstepper (coz ale taky neni uplne stastne reseni). Nad ramec G kodu mas uz treba jen referenci stroje. Co pak teprve nejaky preprocesing, jako filtrace. Proc tomu posilat gkody ktere jsou treba pod rozlisenim. To by asi nejak resitelne bylo a mozna to sendery nejak resi ale neni to treba moc univerzalni pro frezka/soustruh (a jsou i jine stroje). Cpat to do MCU je vyvojove narocnejsi nez to resit v SW na PC a limituje to celkove moznosti budouciho vyvoje a jsi omezen jen na g kody implementovane primo v MCU. Navic g kod jako takovy je uz pomerne zastaraly a rozdily v implementacich jsou mezi RS cim dal tim vetsi. Zase pro ciste hobby to je vcelku dostatecne.

HARVIE: ono hlavne jestli ted umi 30kHz na osu tak s S krivkama by to bylo o poznani min a ono i tech 30kHz je dost malo. Koncept kdy se snazej do jednoho MCU dostat co nejvic vcetne interpretru G kodu neni uplne stastna cesta protoze ne vsechno jde g kodama resit. CNC ridici system neni jen interpret a hlavne pak v tom jednom MCU resis i nerealtime veci ktere zerou pamet a vykon kdyz to krmis datama z PC/tabletu kde mas vseho dost.

THERIDANE: a jako bonus je v nem mineralni slozka, ktera je prej zakladem slusny brusny pasty :-)

HARVIE: to sání poletujícího bordelu od frézy je šikovný :-D zrovna řeším u truhlářské frézky, po roce používání je na všem dost prachu (kterej když chytne vlhkost leptá i vede napětí)

JVCNC: U GRBL totiz ted probiha portovani na 32b mikroprocesory, protoze 8b arduina uz jim nestaci kvuli nedostatku pameti a nemuzou pridavat novy funkce...