JVCNC: Vzhledem k tomu, ze jsem momentalne prakticky jedinej aktivni vyvojar bCNC, tak se to pokusim nejak rozebrat...
> GUI je takove topornejsi, ne moc uplne user friendly.
Mame z toho nekolik issues na githubu... Az vyresime nejaky dalsi problemy, tak to asi zkusim prepsat do gtk3 a gtkbuilderu. Prvni na rade je asi prechod z pythonu 2 na python 3. A celkove jsem na tom dost mizerne s casem.
> odezva programu je ponekud pomalejsi, aktualizace polohy nastroje a souradnic
GRBL funguje tak, ze mu posles otaznik a ono vrati aktualni souradnice. To se dela nekolikrat za sekundu. Neni to zrovna realtime, ale myslim, ze se nekde v bCNC dal snizit interval. Zajimalo by me, jestli to melo nejakej duvod. Jako ze aby to nepretezovalo arduino/seriovku. Nevim. Docela zajimavej namet k zamysleni. Ale popravde me to sere jen kvuli mymu OCD. Zadny prakticky problemy jsem s tim nemel. Stejne se pri jogovani koukam na stroj, ne na monitor :-)
> prekresleni zobrazeni strojnich drah, coz je dano asi tim ze to bezi pod pythonem kterej je proste pomalej.
Tohle je achylova pata. Mam z toho trochu hruzu, jestli to vubec nekdy vyresime. Osobne doufam, ze to vyresi pouziti OpenGL misto tkinter canvasu. Ale nevim, jestli budem vubec schopny to OpenGL dostatecne rychle krmit datama. Nevim jak presne to funguje... Doufam, ze OpenGL umi aspon zoomovani a 3D otaceni mysi bez toho, aby to musel pocitat python. Kdyby tu byl nejakej odbornik na OpenGL ochotnej to prepsat, tak bych byl vyslovene nadsenej.
> Kdyz sipku pustim, stroj jeste kus ujede nez vubec zacne brzdit. Tohle vidim jako docela dost nebezpecny a kriticky nedostatek.
O tom vime a delame na tom. GRBL 1.1 ma novej protokol pro jogovani. Podle me je uplne stejnej jako ten starej, ale aspon tam vysvetlujou, jak v senderu spravne implementovat joging s realtime odezvou.
Mimochodem bCNC ma webovej pendant, kterej si muzes na portu 8080 otevrit z mobilu. 2 lidi ted pracujou na tom, aby tam byl realtime HTML5 joystick, kterej tohle bude podporovat. Jak to implementovat v hlavnim GUI zatim nevim. Jeste se mi neporailo zjistit jak se v tom zatrolenym tkinteru obsluhuje uvolneni tlacitka a klavesy. Ale vsichni sme se shodli, ze je treba to resit.
> trochu nelogicnosti nebo jsem neco nepochopil, kdyz v menu File vyberu Config nebo Controler atd. tak abych nastaveni videl, musim se jeste prepnout do menu CAM, kde pak trochu nepochopitelne vidim nastaveni stroje.
To ses trefil zrovna do vyvojovy verze, kde to bylo par dni rozkopany. Ted je Config a Controller docasne presunutej zpatky do zalozky CAM, aby to nebylo UPLNE matouci. Jeste to budem muset vyresit. Do 0.9.15 se to ale asi nedostane. Jeste pred par dnima se ta zalozka nejmenovala "CAM", ale "Tools". Ted se jmenuje CAM, aby byla jasna snaha oddelit CAM funkce od vsech ostatnich. S tim Config/Controller se nam to zatim kvuli nejakejm problemum nepodarilo. Ale jednou se snad dockame.
> pauznuti obrabeni sice funguje rychleji nez kdyz pustim tlacitko na klavesnici pri JOGu, ale strojem po tom co ho pauznu uz nehnu, tedy neodjedu nastrojem z rezu, nekouknu na nastroj jestli je OK, nesundam z neho namotane spony, pripadne napeceny plast, nevymenim nastroj, proste stroj se az do pokracovani ani nehne.
Tohle me taky trapi a nejsem si jistej, jak to je. Obcas mam pocit, ze to GRBL neumi. Ale to by bylo dost naprd. Kazdopadne bCNC ma behem pauzy zadisablovany vsechny tlacitka, cimz se takova moznost uplne eliminuje. Nicmene presne jak rikas... Napisu vyvojarum GRBL a zjistim co a jak, potom sepisu nejakej plan, jak to implementovat do bCNC.
> soft limity jsou funkci HW a nikoliv SW ze je to bude kontrolovat az pro konkretni zpracovavany radek g kodu a nikoliv po nacteni souboru nebo nastaveni ref,bodu. Sice to nenaboura ale i tak to uz je pozde, to uz muze byt pulka i vic obrabeni hotove.
Mas pravdu, soft limity resi arduino. ne bCNC. zkus v zalozce "Terminal" zapnout volbu "Check g-code" a spustit g-kod. To je rezim, kdy GRBL parsuje g-kod, ale vystupy nic nedelaj. Soft limity nepouzivam, ale docela by me zajimalo, jestli na ne "check" rezim upozorni. Vyvojari doporucujou program pred spustenim v tomhle rezimu project. V praxi to nedelam. Mozna casem pridam moznost delat to automaticky.
> jen mi nektera tvrzeni na offic webu prijdou ponekud nadnesene a nalepky jako high performance software nejsou zrovna moc na miste, vzhledem k tomu ze to je low end. 30 kHz ve 3 osach neni zadna slava.
High performance je to ve smyslu, ze vymackli z atmegy328 kazdej volnej bajt. Momentalne pracujou na ARM portu, protoze ta atmega uz toho vic nezvladne. Jinak u bCNC je taky nejakej podobnej privlastek. Tam to zas znamena to, ze to zvladne i dlouhy programy bez sekani na raspberry pi.
> P.S. ted ctu o necem ze to vyjede z rezu, vypne vystupy a po obnoveni zase zapne a vrati se, zatim jsem na to jeste nenarazil, takze tam mozna tahle funkce nekde je.
Dej vedet, jestli to najdes. Taky by me to zajimalo.
Jinak brzo snad vydam bCNC 0.9.15, pokud pouzivas vyvojovou verzi z gitu, tak te asi moc novinek nezaskoci. Proti 0.9.14 sme toho ale pridali relativne dost:
bCNC/CHANGELOG.md at master · vlachoudis/bCNC · GitHub
https://github.com/vlachoudis/bCNC/blob/master/CHANGELOG.md
Osobne je mi sympatictejsi UI co ma UGS platform, nicmene u bCNC me hodne bavi, ze ma v sobe i zakladni 2D CAM (uz jsem zacal pridavat i prvni vlastovky 3D funkci). Hlavne teda na Linuxu, kde neni zrovna velkej vyber CAMu. Kdyz jsem postavil CNC, tak sem resil, jak vubec na Linuxu udelam g-kod. Treba jak vyriznu pitomou ctverhrannou diru do drevotrisky. Pak jsem ale zjistil, ze bCNC ma v sobe vse co potrebuju v zalozce "Tools", zatim co ja vsude hledal "CAM". Mel jsem to nainstalovany, jen jsem o tom nevedel. Proto jsem ted zacal vic tlacit na to, aby se v dokumentaci a v UI pouzivala zkratka "CAM". Spousta lidi totiz nema tuseni, ze bCNC je vic nez g-code sender.
P.S.: Kdyz taky prilozite ruku k dilu a neco v bCNC doprogramujete, tak budu mit radost :-) Jeste mame pred sebou dost prekazek, coz je zrejmy i z tohodle prispevku.