Arduino Due
odkaz na různé G-code sender : http://www.shapeoko.com/wiki/index.php/ ... _/_Control" onclick="window.open(this.href);return false;
Vyzkoušším v práci ten link.
Jinak jsem tam kde jsem byl, motory se točí atd, s tím JCN mám taky problémy, zkoušeli jste posílat g cod přes coolterm?
Ten jede v poho, akorát nepotporuje T6, ani M1.Až bude tepleji budu dělat na kompletní elektronice. Ještě by to chtělo podporu lcd a sd karty. Snad se ro pohne ještě o kus do předu. Zkoušel jsem to i s tabletem, tam by byl problém vyřešen, ale nespojil se, možná jiný tablet vyzkoušet.
Tak zatím a Perun s Vámi.
Jinak jsem tam kde jsem byl, motory se točí atd, s tím JCN mám taky problémy, zkoušeli jste posílat g cod přes coolterm?
Ten jede v poho, akorát nepotporuje T6, ani M1.Až bude tepleji budu dělat na kompletní elektronice. Ještě by to chtělo podporu lcd a sd karty. Snad se ro pohne ještě o kus do předu. Zkoušel jsem to i s tabletem, tam by byl problém vyřešen, ale nespojil se, možná jiný tablet vyzkoušet.
Tak zatím a Perun s Vámi.
coolterm určitě není na obsluhu cnc, v tom je nepoužitelný, ale třeba pro případné nastavení a testování rozjezdů je v poho, podle toho se dá dále upravit finální flash, krásně vypíše aktuální nastavení, což sice umí i chili, ale není třeba zapínat další fičurky jjko je JSON Server.
tady je taková úvaha jak chili rozjet ofline : https://github.com/synthetos/TinyG/wiki/Chilipeppr" onclick="window.open(this.href);return false;
Tak mi konečně dorazilo Arduino Due. Byl jsem zrovna na skok doma, tak jsem si ho sebou vzal na cesty na hraní.
Zatím jsem z toho teda hodně rozpačitý. Ten bootloader a aplikace Bossa/Bossac funguje hodně divně.
Se staršími verzemi Bossac (1.2, 1.2.1, které jsou v binární podobě na webu autora) se mi to nespojí vůbec. Vždycky to zařve, že na daném portu není nic připojené.
Jediná verze, se kterou mi to jede na Windows je verze 1.3a, kterou jsem vybagroval z vývojového prostředí Arduino. Na Linuxu se mi s tím nespojí žádná z verzí.
Autor tam píše, že na procesorech AMD to může fungovat blbě. Protože mám na Windows i Linuxu AMD, tak jsem sebral kolegovi noťas s Intelem a zkusil to tam. Výsledek je ještě horší, na svých WindowsXP s AMD se mi to s verzí 1.3a spojí jak na programovacím, tak na nativním portu Arduina. S tím noťasem a Windows7 se spojím jenom na nativním portu, se staršíma verzema to taky nejede vůbec (stejně, jako to AMD).
Jediné, co funguje spolehlivě je aplikace přímo ad Atmelu, ale ta je pro rutinní práci dost těžkopádná.
Už si připadám tak trochu jako u blbejch na dvorku. Docela by mě zajímalo, jak to funguje vám.
Protože jsem na cestách, tak sebou nemám žádné pořádné nářadí. Doma to zkusím JTAG/SWD programátorem, snad to bude rozumně fungovat.
Ten programovací SW přes bootloader je podle mě teda hodně nedovařený. Nakonec i doporučení autora toho SW stojí zato. Volně cituji: S AMD to může fungovat blbě. Náprava - kupte si jiný počítač, nejlépe s Intelem.
Zatím jsem z toho teda hodně rozpačitý. Ten bootloader a aplikace Bossa/Bossac funguje hodně divně.
Se staršími verzemi Bossac (1.2, 1.2.1, které jsou v binární podobě na webu autora) se mi to nespojí vůbec. Vždycky to zařve, že na daném portu není nic připojené.
Jediná verze, se kterou mi to jede na Windows je verze 1.3a, kterou jsem vybagroval z vývojového prostředí Arduino. Na Linuxu se mi s tím nespojí žádná z verzí.
Autor tam píše, že na procesorech AMD to může fungovat blbě. Protože mám na Windows i Linuxu AMD, tak jsem sebral kolegovi noťas s Intelem a zkusil to tam. Výsledek je ještě horší, na svých WindowsXP s AMD se mi to s verzí 1.3a spojí jak na programovacím, tak na nativním portu Arduina. S tím noťasem a Windows7 se spojím jenom na nativním portu, se staršíma verzema to taky nejede vůbec (stejně, jako to AMD).
Jediné, co funguje spolehlivě je aplikace přímo ad Atmelu, ale ta je pro rutinní práci dost těžkopádná.
Už si připadám tak trochu jako u blbejch na dvorku. Docela by mě zajímalo, jak to funguje vám.
Protože jsem na cestách, tak sebou nemám žádné pořádné nářadí. Doma to zkusím JTAG/SWD programátorem, snad to bude rozumně fungovat.
Ten programovací SW přes bootloader je podle mě teda hodně nedovařený. Nakonec i doporučení autora toho SW stojí zato. Volně cituji: S AMD to může fungovat blbě. Náprava - kupte si jiný počítač, nejlépe s Intelem.
Vzal jsem si to Arduino na cesty a po večerech jsem si s tím trochu hrál. Tady jsou moje prozatimní zkušenosti:
Programátor bossac:
Jak už jsem psal v minulém příspěvku, tady je (byla) situace ne úplně ideální.
To už se ale změnilo. Našel jsem zdrojáky novější verze 1.4 a trochu to pofackoval - dopsal jsem tam přepínání režimů a mazaní Flash tou změnou rychlosti portu, takže už to funguje bez toho šachování s nastavováním rychlosti portů, a hlavně už mi to funguje na všech počítačích, jak na Windows, tak na Linuxu.
Vlastní firmware TinyG2:
Firmware TinyG2 vypadá, že je napsané fakt pěkně a umí toho hodně. Nemám sebou na cestách osciloskop a ani drivery a motory, takže to hodnotím jenom teoreticky. Ale možnostma a funkcema to vypadá opravdu hodně dobře.
Ale je tady jedna velká, opravdu velká, koncepční chyba. Autoři byli asi dobří programátoři, ale špatní koncepční pracovníci, a chyběla jim trocha pokory. Výsledkem je, že to pojali, jako že jsou pupkem světa a každý se bude přizpůsobovat jim. Takže tam implementovali 2 různá rozhraní pro komunikaci s nadřízeným SW (tedu s G-code senderem), ale ani jedno z těch rozhraní není zpětně kompatibilní s (v té době už populárním a rozšířeným) rozhraním GRBL. Přitom ten jejich SW původně z GRBL vyšel. Dokonce je to snad tak, že ani verze TinyG a TinyG2 namají to rozhraní stejné, což už je úplně trestuhodné.
G-code sender:
No a zde je zakopaný pes, tady se projevují důsledky té koncepční chyby s rozhraním. Podle mých dosavadních pokusů v současné době snad neexistuje použitelný nadřízený SW, který by uměl slušně a polehlivě spolupracpvat s TinuG2, aby se z toho stal ucelený systém.
Z těch, které by snad připadly v úvahu:
- UniversalGcodeSender je z nich asi nejstarší. Teoreticky ve verzi 1.08 by měl mít nějakou betaverzi podpory TinyG, ale ta verze není zatím zveřejněná, a ani v night-buildech, které se tváří jako 1.08, to zatím není.
- tgFx by teoreticky vypadal nadějně, ale tento projekt byl ukončen a opuštěn. Navíc autoři vše směřují a tlačí na nový projekt ChiliPeppr, takže zmizela všechna uložiště, kde se dalo stáhnou tgFx v binární podobě (aspoň já jsem ho nenašel). Dají se stáhnout zdrojáky, ale to znamená instalovat zase mraky vývojových nástrojů pro Javu, a to já asi dělat nebudu (Javu nenávidím antiláskou hlubokou a upřímnou).
- ChiliPeppr - je to systém, který neběží jako samostatný program, ale jako on-line stránka ve webovém browseru. Logika ovládání mi připadá nepochopitelná, je to pomalé a svou koncepcí (okno v browseru) podle mě pro seriózní práci nepoužitelné (aspoň pro mě).
- JCNC - nějaký německý SW, který se jeví zdánlivě nejpoužitelnější. Taky jako jediný z nich není v Javě, takže funguje svižně (resp. fungoval by). Jenže tady se opět ukazuje to nešťastně nestandardní rozhraní TinyG2. Ten JCNC píše, že používá rozhraní TinyG. Každopádně nefunguje s TinyG2 dobře. Takže buď je to implemntováno špatně, nebo je rozdíl mezi TinyG a TinyG2.
Celkové zhodnocení:
TinyG2 je pěkný projekt, technicky asi dost dobře napsaný, postavený na levném a snadno dostupném HW. Ale se zásadní koncepční chybou v nešťastně zvoleném komunikačním rozhraní. Protože autoři TinyG2 svůj vlastní nadstavbový SW nepíšou, a ostatní se do podpory jejich rozhraní moc nehrnou, tak je to smrtící kombinace.
Kromě toho všechny ty nadstavbové SW jsou poměrně ne-moc-živé projekty. Nejsou mrtvé, ale žijí pomalu, ve většině z nich jsou updaty staré řadu měsíců nebo i let. Takže nějaký rychlý a dramatický vývoj do budoucna bych tady nečekal.
Já sám se do psaní nadstavbového SW tlačit nebudu. Programování grafickýxh front-end aplikací mě nebaví, tohle bych dělal jenom jako práci, nikoli ve svém volném čase jako zábavu.
Co bych považoval za teoreticky možnou cestu je úprava - dopsání dalšího rozhraní do TinyG2 tak, aby bylo kompatibilní s GRBL. Pak by se dala využít veškerá šíře nadstavbových SW, které jsou všechny orientované na GRBL. Zatím jsem to do hlouby nestudoval, protože mám momentálně jen dost omezené možnosti pro vývoj, ale tohle by snad mohlo být realizovatelné (rozhraní GRBL by mělo být o dost jednodušší než nativní rozhraní TinyG2. Navíc tohle by mě asi i bavilo. Případně zkusit udělat takovou šílenost, jako on-the-fly překladač z rozhraní TinyG2 na GRBL, který by běžel na PC (aspoň jako pokus pro ověření konceptů).
No a pak se nabízí poslední možnost - pojmout TinyG2 jako slepou cestu a uložit ho na dno šuplíku.
Programátor bossac:
Jak už jsem psal v minulém příspěvku, tady je (byla) situace ne úplně ideální.
To už se ale změnilo. Našel jsem zdrojáky novější verze 1.4 a trochu to pofackoval - dopsal jsem tam přepínání režimů a mazaní Flash tou změnou rychlosti portu, takže už to funguje bez toho šachování s nastavováním rychlosti portů, a hlavně už mi to funguje na všech počítačích, jak na Windows, tak na Linuxu.
Vlastní firmware TinyG2:
Firmware TinyG2 vypadá, že je napsané fakt pěkně a umí toho hodně. Nemám sebou na cestách osciloskop a ani drivery a motory, takže to hodnotím jenom teoreticky. Ale možnostma a funkcema to vypadá opravdu hodně dobře.
Ale je tady jedna velká, opravdu velká, koncepční chyba. Autoři byli asi dobří programátoři, ale špatní koncepční pracovníci, a chyběla jim trocha pokory. Výsledkem je, že to pojali, jako že jsou pupkem světa a každý se bude přizpůsobovat jim. Takže tam implementovali 2 různá rozhraní pro komunikaci s nadřízeným SW (tedu s G-code senderem), ale ani jedno z těch rozhraní není zpětně kompatibilní s (v té době už populárním a rozšířeným) rozhraním GRBL. Přitom ten jejich SW původně z GRBL vyšel. Dokonce je to snad tak, že ani verze TinyG a TinyG2 namají to rozhraní stejné, což už je úplně trestuhodné.
G-code sender:
No a zde je zakopaný pes, tady se projevují důsledky té koncepční chyby s rozhraním. Podle mých dosavadních pokusů v současné době snad neexistuje použitelný nadřízený SW, který by uměl slušně a polehlivě spolupracpvat s TinuG2, aby se z toho stal ucelený systém.
Z těch, které by snad připadly v úvahu:
- UniversalGcodeSender je z nich asi nejstarší. Teoreticky ve verzi 1.08 by měl mít nějakou betaverzi podpory TinyG, ale ta verze není zatím zveřejněná, a ani v night-buildech, které se tváří jako 1.08, to zatím není.
- tgFx by teoreticky vypadal nadějně, ale tento projekt byl ukončen a opuštěn. Navíc autoři vše směřují a tlačí na nový projekt ChiliPeppr, takže zmizela všechna uložiště, kde se dalo stáhnou tgFx v binární podobě (aspoň já jsem ho nenašel). Dají se stáhnout zdrojáky, ale to znamená instalovat zase mraky vývojových nástrojů pro Javu, a to já asi dělat nebudu (Javu nenávidím antiláskou hlubokou a upřímnou).
- ChiliPeppr - je to systém, který neběží jako samostatný program, ale jako on-line stránka ve webovém browseru. Logika ovládání mi připadá nepochopitelná, je to pomalé a svou koncepcí (okno v browseru) podle mě pro seriózní práci nepoužitelné (aspoň pro mě).
- JCNC - nějaký německý SW, který se jeví zdánlivě nejpoužitelnější. Taky jako jediný z nich není v Javě, takže funguje svižně (resp. fungoval by). Jenže tady se opět ukazuje to nešťastně nestandardní rozhraní TinyG2. Ten JCNC píše, že používá rozhraní TinyG. Každopádně nefunguje s TinyG2 dobře. Takže buď je to implemntováno špatně, nebo je rozdíl mezi TinyG a TinyG2.
Celkové zhodnocení:
TinyG2 je pěkný projekt, technicky asi dost dobře napsaný, postavený na levném a snadno dostupném HW. Ale se zásadní koncepční chybou v nešťastně zvoleném komunikačním rozhraní. Protože autoři TinyG2 svůj vlastní nadstavbový SW nepíšou, a ostatní se do podpory jejich rozhraní moc nehrnou, tak je to smrtící kombinace.
Kromě toho všechny ty nadstavbové SW jsou poměrně ne-moc-živé projekty. Nejsou mrtvé, ale žijí pomalu, ve většině z nich jsou updaty staré řadu měsíců nebo i let. Takže nějaký rychlý a dramatický vývoj do budoucna bych tady nečekal.
Já sám se do psaní nadstavbového SW tlačit nebudu. Programování grafickýxh front-end aplikací mě nebaví, tohle bych dělal jenom jako práci, nikoli ve svém volném čase jako zábavu.
Co bych považoval za teoreticky možnou cestu je úprava - dopsání dalšího rozhraní do TinyG2 tak, aby bylo kompatibilní s GRBL. Pak by se dala využít veškerá šíře nadstavbových SW, které jsou všechny orientované na GRBL. Zatím jsem to do hlouby nestudoval, protože mám momentálně jen dost omezené možnosti pro vývoj, ale tohle by snad mohlo být realizovatelné (rozhraní GRBL by mělo být o dost jednodušší než nativní rozhraní TinyG2. Navíc tohle by mě asi i bavilo. Případně zkusit udělat takovou šílenost, jako on-the-fly překladač z rozhraní TinyG2 na GRBL, který by běžel na PC (aspoň jako pokus pro ověření konceptů).
No a pak se nabízí poslední možnost - pojmout TinyG2 jako slepou cestu a uložit ho na dno šuplíku.
ahoj je vidět že ses tomu pěkně věnoval , myslím že by opravdu stálo zato se pokusit tinyG2 rozchodit protože to umí Skřivky a jerk a kupu dalších věcý které ostatní projekty neřeší , když se do toho pustíš a podělíš se snámi o to tak ti budem nesmírně vděčný .
zatim dík
Packa
zatim dík
Packa
a úpravy toho TinyG2.Neni to sice arduino, ale mam GRBL rozbehany pod STM32 s LCD displejem "800x480" a SD kartou. Funguje mi verze GRBL v0.8.
S novou verzi 0.9 mam problem pod Keil kompilatorem. Vse funguje jak ma, ale pri zrychleni to vypocita spadne dlouhe impulzy.
Jeste skusim udelat nejakou kniznici pres GCC a pouzit to v KEIL projektu.
Az teraz som nasiel ze existuje projekt TinyG2. Vyzera to zaujimavo, programovat sa da z Atmel Studia ktore je zadarmo.
Nevyhodu vidim momentalne len v chybajucich konektoroch na SD kartu. Nestudoval som zapojenie pinov ale podla datasheetu to ma 16 bitovu externu zbernicu, takze pripojit k tomu LCD s vyssim rozlisenim zrejem pojde (sk su potrebne piny vyvedene na konektory).
Voci GRBL ma zaujala aj podpora siestich osi.
S novou verzi 0.9 mam problem pod Keil kompilatorem. Vse funguje jak ma, ale pri zrychleni to vypocita spadne dlouhe impulzy.
Jeste skusim udelat nejakou kniznici pres GCC a pouzit to v KEIL projektu.
Az teraz som nasiel ze existuje projekt TinyG2. Vyzera to zaujimavo, programovat sa da z Atmel Studia ktore je zadarmo.
Nevyhodu vidim momentalne len v chybajucich konektoroch na SD kartu. Nestudoval som zapojenie pinov ale podla datasheetu to ma 16 bitovu externu zbernicu, takze pripojit k tomu LCD s vyssim rozlisenim zrejem pojde (sk su potrebne piny vyvedene na konektory).
Voci GRBL ma zaujala aj podpora siestich osi.
Co som pozeral tak doska nema vyvedene vsetky piny D0-D15 na konektor, takze na pouzitie externej zbernice je nevhodna.
Riadit displej sa da aj cez GPIO ale rychlostou je to mozno 4x pomalsie. O prenosoch na pozadi ani nehovorim.
Zatial najschodnejsiu cestu vidim upravit zdrojaky na inu vyvojovu dosku. S STM32F103 mam kopec skusenosti, ale na takyto projekt by to chcelo nejake riesenie zadarmo typu Atmel studio a nie stahovat cracknuty Keil alebo IAR. Zajtra pozriem na tie zdrojaky blizsie
Riadit displej sa da aj cez GPIO ale rychlostou je to mozno 4x pomalsie. O prenosoch na pozadi ani nehovorim.
Zatial najschodnejsiu cestu vidim upravit zdrojaky na inu vyvojovu dosku. S STM32F103 mam kopec skusenosti, ale na takyto projekt by to chcelo nejake riesenie zadarmo typu Atmel studio a nie stahovat cracknuty Keil alebo IAR. Zajtra pozriem na tie zdrojaky blizsie