CNC řezačka polystyrenu

[quak]

Mechanika i vlastní princip stroje funguje moc hezky.
Stále ale bojuji se softwarem, Nejprve se mi zdálo jako dobrý nápad použit Inkscape s pluginem pro G kód a skutečně se pár věci podařilo vyřezat. Bohužel se u něj velmi špatně zadává startovací bod ( Viděl jsem to na YouTube ale v praxi se mi to nepodařilo) a nepřišel jsem na způsob jak ovlivnit směr kterým pojede po křivce. Takže jsem začal zkoumat možnost Fusion 360, kde pohyb nástroje mám plně pod kontrolou, bohužel jsem ale nenašel postprocesor (a zkoušel jsem poctivě všechny) který by generoval G kód vhodný pro software ICE. Vždycky je potřeba g-code nějakým způsobem ručně doupravit. Když k tomu přičtu poměrně nepohodlný software ICE pro ovládání pohybu stroje. tak si říkám jestli by to nešlo nějak přes GRBL.

Thomeeque:

Mluvil jsi o tom, že by bylo možné přidat možnosti převodu do tvého GCU programu. Teď po několika dnech úmorného snažení naroubovat na sebe věci, které jsou tak nesourodé mi to přijde jako dobrý nápad a možný směr pro tento systém. Napadá tě nějaké řešení?

[Thomeeque]

Thomeeque:

Mluvil jsi o tom, že by bylo možné přidat možnosti převodu do tvého GCU programu. Teď po několika dnech úmorného snažení naroubovat na sebe věci, které jsou tak nesourodé mi to přijde jako dobrý nápad a možný směr pro tento systém. Napadá tě nějaké řešení?

Včera před spaním jsem zkusil oprášit můj projekt (rozjet si znovu vývojové prostředí a build proces), trochu mne to potrápilo, ale už se to poddalo, zkusím na to večer sednout. Něco jednoduchého bych měl zvládnout Pošli mi plz ukázkový gcode (cokoliv, co jde otevřít v GCU a vypadá tak, jak očekáváš). Cokoliv vygenerované pro MACH nebo LinuxCNC by neměl být problém. Počítám, že gcode bude (alespoň pro začátek) obsahovat i nájezd a výjezd z materiálu, prostě veškerý pohyb drátu. Jak budeme definovat XY bod [0,0] a pracovní prostor, nějak takto?

V GUI by se zadávala ta vzdálenost motorů a L1 a L2 bodu [0,0]..?

Koukal jsem na screenshot z tvého prvního postu a úplně tam tomu nerozumím, ale asi to ani není nutné, když se domluvíme takto. [Xmax, Ymax] asi vědět nemusím, jen bych mohl dělat nějakou kontrolu.

Kompenzaci prověšení řemínků si asi pořešíš v řídícím systému (tj. já to budu generovat 1:1)?

T.

[quak]

Moc by mě potěšilo, kdyby se podařilo najít jiný způsob jak to zprovoznit bez toho německého SW šílenství…
Výstupem by měl být G kód pro čtyřosý systém XYZA s tím, že X a Z jsou totožné a stejně tak Y a A. 4 osy jsou potřeba kvůli seřízení nuly. Pokud nebude možné hýbat každým motorem zvlášť, nebylo by možné ani srovnat horký drát do roviny. To je ale věc manuálního nastavení a netýká se převodního softwaru.
Nastavení nuly nyní provádím tak, že mám na všech řemíncích značky ve stejné vzdálenosti (1880mm) a manuálně, jeden po druhém najedu značkou na řemeničku. V softwaru je zadaná rozteč motoru (1522mm) i délky řemínků a tím je definovaná nula. V tomto případě to znamená, že nula je dole a uprostřed pracovního prostoru. nicméně pro Fusion to není problém. Bohužel tady není možné zadávat nulu způsobem jakým jsme zvyklí CNC mašinek, tedy někam najet a kliknout “tady je 0”. Tady musí být souřadnice absolutní, vzhledem ke geometrii stroje. Zadávat nulu způsobem jako máš na obrázku výše by bylo trochu méně praktické a u tohoto sytstému je lepší pokud možnu co nejvíc věcí dělat uprostřed pracovního prostoru.

Určitě by bylo fajn, kdyby ve tvém softwaru byla možnost nastavit offset X Y. Pokud totiž potřebuji stejnou věc vyříznout několikrát, nebo vyřezávat z desky odkud jsem už něco vyřezal, je praktičtější, zadávat offset až tady, aby se kvůli tomu nemusel generovat nový počáteční g-kod. V g-kode senderu už offset nastavovat nemůžu, protože by to rozbouralo geometrii.

Pro můj konkrétní stroj je Xmax=1100mm a Ymax 550mm

S ohledem na rozměry a délky řemínku, by pro konverzi ve tvém softwaru stačilo rozsekat dráhy po úsečkách o délce 1 mm (možná i delší - záleží na vyřezávaném tvaru) tak, jak to máš na tom svém obrázku.
Kompenzaci prověšení řemínku nemusíme řešit vůbec, protože je malé a při řezání polystyrenu si hrajeme na milimetry, nikoli desetiny nebo setiny.

Ota

[quak]

Tady je jednoduchý kód Fusion360 pro vyříznutí dvou vložek do krabice:
(v dalším postu přihodím něco s obloukama)

(1001)
(T3 D=1.2 CR=0. - ZMIN=0. - FLAT END MILL)
G0 G90 G94 G17
G21
G0 Z1.

(2D CONTOUR2)
M5
T3
M3 S5000
G54
M8
G0 X-0.6 Y0.001 (** Nájezd na první bod objektu vlevo dole)
Z1. (** Souřednici Z pochopitelně ignorujeme)
G1 Z0. F333.
Y49.001 F1000.
Y49.601
X29.4
Y100.001
Y100.601
X130.
X130.6
Y53.401
X65.6
Y1.117
X65.9
Y46.001
Y46.601
X130.9
Y100.001
Y100.601
X197.1
Y50.401
X167.1
Y0.001
Y-0.599
X66.5
X65. Y-0.6
X0. Y-0.599
X-0.6
Y0.001
G0 Z1.
G0 X-10 Y0 (*** Ručně dopsané odjetí horkým drátem 10mm od materiálu)
M9
G0 Z1.
M30

[Thomeeque]

Moc by mě potěšilo, kdyby se podařilo najít jiný způsob jak to zprovoznit bez toho německého SW šílenství…
Výstupem by měl být G kód pro čtyřosý systém XYZA s tím, že X a Z jsou totožné a stejně tak Y a A. 4 osy jsou potřeba kvůli seřízení nuly. Pokud nebude možné hýbat každým motorem zvlášť, nebylo by možné ani srovnat horký drát do roviny. To je ale věc manuálního nastavení a netýká se převodního softwaru.

Pro mne XYZA výstup není problém (i když trochu přemýšlím, jak se bude chovat feed), ale GRBL 4 osy nezvládne, nebo ano? Pokud ne, co kdybys X a Y posílal do obou driverů a měl tam jen (fyzický) přepínač, který by uměl vždy jednu stranu v průběhu seřizování nuly disablovat?

A ještě mne tedy napadlo, že mám i naprogramovaný jednoduchý GRBL sender v Javě (mám tu jen Maca a nenašel jsem na něj pro GRBL nic pro mne použitelného), který by šel upravit - baštil by normální gcode a do grbl posílal L1L2. To by asi bylo pohodlnější. Nicméně víc práce pro mne (zatím to neumí jogovat, žádné GUI to nemá), také by se mi to naslepo blbě ladilo. Začněme tím GCU. Udělám tam tedy nastavení vzdálenosti motorů a home position, pro kterou zadáš L1, L2 a zároveň i X a Y, což bude tvůj offset (bude to uloženo v local storage, takže po prvním nastavení budeš měnit už jen offset).

Jaký používáš sender btw.?

T.

[quak]

Ten výstup XYZA, tím myslím jen při zápisu řádku zduplikovat hodnotu pro X akorát před ní zapsat Z. X a Z si budou vždy rovny, stejně tak Y a A.

GRBL 4 osy zvládne. Dávám čtyř a pěti osé GRBL do svých Airbrush mašinek, akorát to vyžaduje Arduino Mega. Mám na to ale vlastní desku která dokáže až 6os a osa Y je dublovaná aby bylo možné použít dva motory pro Y. Běží to na GRBL mega 5X.


Kdyby ten tvůj systém uměl i poslat daný kod do GRBL, tak by to byla naprostá bomba. Ale znamená to, že by musel umět nejen posílat spočítaný kod, ale mít alespoň základní ovládací funkce. Myslím tím jen příkazový řádek a jogování. Jogování řeší GRBL poměrně primitivně, po zmáčknutí tlačítka vyšle sender jednořádkový G-kod, Toť vše. Stejným způsobem jsou tam i makra.

Používám UGS Platform, ten mě dává slušný možnosti, ale zákazníkům doporučuji Candle, ten je jednodužší a graficky se mi víc líbí...

[quak]

Začněme tím GCU. Udělám tam tedy nastavení vzdálenosti motorů a home position, pro kterou zadáš L1, L2 a zároveň i X a Y, což bude tvůj offset (bude to uloženo v local storage, takže po prvním nastavení budeš měnit už jen offset).

Naprosto souhlasím, nejdřív stačí aby to "opilý G-kod" vyplivlo do souboru. Parametry na vstupu, Rozteč, L1 L2, X, Y za mě dobrý. Těším se na výsledek...

[Thomeeque]

Ten výstup XYZA, tím myslím jen při zápisu řádku zduplikovat hodnotu pro X akorát před ní zapsat Z. X a Z si budou vždy rovny, stejně tak Y a A.

Rozumím, jen přemýšlím, jak se GRBL u lineárního pohybu postaví k rozkladu aktuálního zadaného F do rychlostí na jednotlivých osách, pokud tam bude mít pohyb ve všech 4 souřadnicích. Protože pokud neví, že Z je vlastně X a A je vlastně Y (co se směru pohybu týče), bude to IMHO počítat špatně. Nebo to nějak ví?

[quak]

V tom bych problém neviděl (můžu to zkusit i prakticky) ale běžně tady pouštím do GRBL testovací G-kody pro 5 os s tím, že jsou to náhodně generovaná čísla v daném rozsahu každé osy. Mašina pak několik hodin jezdí sem a tam otvírá a zavírá trysku a všechno jede současně bez nejmenších problémů. Když to dokáže spolknout normání 4 osý G-kod a jezdit podle něj tak to určitě zvládne i "opilý G-kod"

EDIT:
Pokud vím, tak generování pulsu pro lineární pohyb probíhá tak, že se spočítá rozdíl mezi startovacím bodem X1 a cílovým bodem X2, tomu odpovídá určitý počet pulzů a rychlosti odpovídá frekvence. To samé se děje pro všechny osy současně. Jak je to s obloukem nevím, tam máš pravdu, že ten lze aplikovat asi jenom na dvě osy. Proto bude nutné rozsekat celou dráhu drátu na krátké úsečky. Pokud by rozebírat oblouk na úsečky bylo ve tvém softwaru komplikované, vždycky můžeme najít postprocesor, který generuje přímo úsečky místo oblouku. Možná bych se k této variantě alespoň v první fázi přiklonil.

Zkusil bych nejdříve cestu nejmenšího odporu abychom ověřili, že to je možné.

[Thomeeque]

Ha, na chvilku jsi mne uchlácholil, ale pak jsem to smazal IMHO abys správně rozpočítal jednotlivé složky, musíš znát absolutní ujetou vzdálenost v prostoru (protože k tomu je feed vztažen, jde o absolutní rychlost pohybu nástroje v prostoru, alespoň u klasického 3-osého obrábění) a tu to právě spočítá špatně. Možná proto existuje G93. No, každopádně o tom potom, jdu pokračovat v programování

[quak]

Jdu nahrát do Arduina 4 osé GRBL a prostě to otestuji na krátkém kodu , který napíšu v ruce a bude jasno

[quak]

Ověřeno, Nahrál jsem si do Arduina čtyřosý GRBL. V Excelu jsem vygeneroval asi 100 řádků náhodných přejezdů X Y, kde hodnoty Z A jsou shodné s X Y. Pak jsem dvoukanálovým osciloskopem kontroloval pulzy Step vždy pro osu X+Z a pak Y+A. Sedí to proti sobě jako přibitý i během rampování a při různých změnách rychlostí.

[Thomeeque]

Hmm, to je asi nejdůležitější, jen to možná nepojede podle zadaného F (v závislosti na tom, jak moc se bude lišit délka přejezdu v XY versus v XYZ, něco takového).

Už mám první verzi, jen zápasím s uploadem na server, tak snad to za chvilku dám

T.

[OompaLoompa]

no ak to chcete riešiť cestou post-processingu G kodu, tak ten feedrate bude ten váš postprocesor tiež musieť prepočítavať, inak bude vo výsledku rovnako "opitý" ako ten G-kód

podstatne lepším riešením by bolo upraviť priamo GRBL pridaním podpory pre tento typ kinematiky.

[Thomeeque]

Co bychom si bez tebe počali..