CNC Fórum

tusi nekdo jak to tedy vyresit ?

bud si napis vlastni postprocesor, nebo se obrat na dodavatele CAM

Vyhoď z toho vše nepodstatné.
Začni tou výměnou nástroje (T1 M6). Pak případně vyhoď další nepodstatné věci z hlavičky.
A podívej se, jakou verzi GRBL máš, jestli v není nějaký známý problém.
Bezproblémová by měla být verze 1.1f.

prece nemuzu byt jedinej komu to dela tyto problemy a pokud ano tak z nejakeho specifickeho duvodu ktery musi jit opravit

To jistě ano.
Zkusím to ještě potřetí a naposled.
Zkontroluj verzi GRBL.
Vyházej v toho souboru nepotřebné G-kódy, abys zjistil, který z nich to způsobuje.

GRBL mam 1.1e zitra nahrahu 1.1f a otestuju

tak s GRBL 1.1h ktery ma byt aktualni je vysledek stejnej

Fajn. Takže jedna malá jistota, že v GRBL to není.
Tak teď vyhodit vše nepotřebné z hlavičky. Včetně té výměny nástroje.

Mex píše: ↑4. 11. 2019, 5:24 Ale třeba G90 a G91 jsou podle mě vylučující-se nastavení. G90 zapne absolutní režim, G91 relativní.
Takže ten CAM v hlavičce cvičně několikrát přepne ty režimy tam a zpátky.
Asi aby to rozhýbal, jako když člověk rozevírá třeba zatuhlé kleště.
Nebo to chápu blbě?

Do G91 to přepne jen dočasně kvůli G28 (člověk by to čekal napsané v opačném pořadí, tj. G91 před G28, ale funguje to i takto - je to na trochu delší studium).

Např. postprocesor 4887_grbl.cps (viz tento post) tam tuto sekvenci přidává v jednom bloku s komentářem "retract to safe plane" (ve funkci onSection()).

Tady je to popsáno jako "Move Straight to the Reference Position".

T.

Jinak souhlasím, z kódu povyhazovat vše, co není potřeba a najít postupně viníka. K tomu ti může pomoci třeba i můj prográmek, viz http://thmq.mysteria.cz/gcu?open=https: ... ?id=112888, kde je každá instrukce stručně popsána v bublině po najetí myší. Dá se to přepnout i do češtiny. T1 zní nadějně, akorát to nedává moc smysl, protože GRBL kompenzaci rádiusu nepodporuje (ale třeba to tam nějak dopytlíkuje GUI? Já bohužel o GRBL nic moc nevím..). Případně začít ručně napsaným kódem.

tak jsem kod premazal takto a stejnej vysledek, pouzil jsem i jiny arduino, smazal a nahral znova eeprom a stejny, uz fakt nevim kde muze byt problem

Hmm, tak tady už jsou asi jediná trochu "exotika" (tj.něco, co by teoreticky mohlo jedoduchý řídící systém mást) ty obloukové nájezdy v XZ a YZ rovinách.. Zkusil bych to možná bez nich, ale moc nadějí bych tomu nedával. Možná by pomohlo video běžícího stroje, třeba bychom něco podezřelého zahlédli nebo zaslechli.

tak jsem ted udelal jeste 2x test s machem a pak zas prez grbl a vysledek byl ze s machem i grbl jsou obdelniky vetsi o cca 0.5mm ale s rozdilem ze mach ma pak celkovou delku cca 151.5mm a s grbl je to presne 150, pouzil jsem pro oboje stejnej soubor, tohle je fakt zahada

Tipuji, že ti v určitých situacích (např. nějaká rezonance v určitém místě při určité rychlosti, což se může pro různé řídící systémy lišit) hapruje něco na stroji příp. v elektronice. Zkus měnit feed, rampy a tak, jestli to bude mít vliv. Příp. zkus, jestli se to vše bude chovat stejně, pokud bude místo vřetena upnutá jen fixka.

Nechybí v hlavičce přesnost, neboli G64? Obvykle se to teda projeví v poloměru rohů, ale náhoda je blbec, kdo ví. Když jsem to v mých počátcích neměl, tak mi třeba hajzl dělal kruhy menší. Zkus do hlavičky dát řádku "G64 P0.01", určo tim nic nezkazíš.