• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    VODRHACNC - teorie a rady pro domácí stavbu našich obráběcích strojů frézky, soustruhy, 3D tiskárny, vračky, pily, brusky etc.
    JVCNC
    JVCNC --- ---
    THERIDANE: ja si tyhle veci implementoval sam, protoze hotove veci jsem pouzit nemohl a nechtel a myslim ze to neni zase tak moc slozite aby bylo nutne tam strkat dalsi vrstvu.

    jako ona to neni spatna metoda, kdyz mas jako vstup bitmapu treba na fotky atd. protoze nic jineho nez tu bitmapu nemas, kdyz uz ale mas 3d model tak je to ponekud hloupe. ja mel v nem hlavne problem s terminama, tedy pochopenim co tim vlastne mysli a proc to po me vlastne chce nastavit, no ted s tou metodou to zacina davat vetsi smysl i to proc je to tak pomale a proc to vlastne doporucuje pouze do dreva.

    HARVIE
    HARVIE --- ---
    1 odpověď
    THERIDANE: BlenderCAM me hrozne nadchnul, kdyz jsem videl prezentace. Ale v praxi jsem se v tom trochu ztratil a nikdy se mi nepodarilo v nem neco kloudne zprocesovat (stejne jako v PyCAMu). To UI je proste dost komplexni. A to rikam jako fanousek Blenderu, v blenderu pracuju s 3D meshema, sculptuju a striham video. Ale jako CAM jsem ho zatim nezvladnul zkrotit. Uz jen to, ze v blenderu neni uplne jasny v jakejch jednotkach se pracuje, musi se to tam nekde nastavovat pokazdy a hrozi, ze na to clovek zapomene. Taky se mi stavalo, ze sem tam nekde nastavil moc velkou presnost a cely to zatuhlo.

    Mam nejakej dlouhodobej plan pozvat pana Viléma do BrmLabu, az si najdu cas, aby nam udelal workshop a trochu se poptat na veci, co mi nejsou jasny.
    HARVIE
    HARVIE --- ---
    1 odpověď
    JVCNC: Za jogovani a nulovani pri pozastavenym stroji se muzete primluvit tady:
    Can i jog during feed hold? · Issue #592 · gnea/grbl · GitHub
    https://github.com/gnea/grbl/issues/592

    Jako treba PyCAM je tak pomalej, ze nez se vypocitala CAM operace, kterou jsem potreboval udelat, tak jsem si v mezicase stihl ty funkce doprogramovat do bCNC :-D Ale 3D otaceni nahledovyho okna pomoci mysi mu funguje vcelku pouzitelne rychle... Kdyby to tak fungovalo v bCNC, byl bych nadsen.
    THERIDANE
    THERIDANE --- ---
    2 odpovědi
    JVCNC: K té trojce - než se v tom babrat je daleko lepší lupnout do GtkGLArea nějakou existující scenegraph implementaci, která abstraktní věci jako třeba kameru implementuje a VBO používá když může.

    K BlenderCAMu... používal jsem ho, pak jsem řešil nějakej triviální problém s můstky, tak jsem to šel opravit... jímal mě strach. Pan Vilém (autor) je taky akademik, ještě navíc umělec. CAM funguje tak, že se scéna vyrenderuje, a dál se (většinou) pracuje s bitmapami (Z buffer, stencils, atd.), a většinou s aspoň O(n²) cenou :-)
    JVCNC
    JVCNC --- ---
    2 odpovědi
    HARVIE: 1. to by mohla byt lepsi volba, nicmene porad mam strach z toho pythonu. zatim jsem nepotkal nic v pythonu co by bezelo srovnatelne rychle jako z jinych prog jazyku. Tim nerikam ze nic takoveo neni a ze to nejde, jen ze jsem to jeste nepotkal.

    2.jestli nebude problem s prekreslovanim GUI pres tkinter nez s komunikaci. realtime to byt nemusi, jen mi to snizuje uzivatelsky komfort a necitim se pohodlne kdyz se nejake jevy aktualizuji mene casto nez kazdych 0.1s, tedy je to jen pocitove. Castejsi aktualizace funkcne asi nic neprinese

    3. OpenGL je jen zobrazovac, panovani, zoomovani rotace atd. musis implementovat sam, ale neni to nic extra sloziteho. Dostatecne rychle to data krmit nemusis, v efektivnejsi ale ne nejefektivnejsi (a nejslozitejsi) variante ktera by byla dostatecna, pres vertex array funkci opengl predas pocet prvku v poli a pointer na prvni prvek (zjednodusene receno) a nemusis nikam posilat vsechny souradnice pro kazdy frame znova. Jeste efektivnejsi je vertex buffer object, ale ten podle me uz neni potreba a hlavne si nejsem jist ze je implementovan napr v openGLES atd. a nektere integrovane graf. karty s tim budou mit problem

    3. o pendantu jsem nekde neco cetl ale jeste nezkousel.
    4. jo to dava smysl.
    5. v jinem senderu jsem to zkousel ale docela jsem si pockal nez to probehlo
    6. jo to asi jo
    7. zkousel jsem par dalsich senderu a nikde se mi to nepovedlo, jen nevim jestli nebylo implementovano nebo to GRBL neumi, co jsem tak koukam tak vetsina senderu neni uz par let vyvyjena a skoncila ve fazi vizualizace drah nebo jen jako gui bez zadnych dalsich funckionalit.

    na Linuxu muzes zkusit BlenderCAM, jen je napsanej taky v pythonu a je silene pomalej. na linuxu to mozna pobezi lip, to jsem nezkousel.
    HARVIE
    HARVIE --- ---
    +5
    A malem bych zapomnel na PF. Chtel jsem to sestrihat, ale nejak jsem se na to vysral, tak je to nudny a dlouhy:

    Deset oříšků pro Andreje (PF 2019)
    https://www.youtube.com/watch?v=vsxBBFMk1hY


    BTW pri nataceni tohodle videa byla pouzita nova funkce, kterou jsem dopsal do bCNC, ktera umoznuje behem jogovani zaznamenavat body a vytvorit tak primo g-kod.
    HARVIE
    HARVIE --- ---
    1 odpověď+2
    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.
    HARVIE
    HARVIE --- ---
    ctvrta osa nemusi bejt slozita:

    Custom CNC 4th axis: Up and running!
    https://www.youtube.com/watch?v=uRPh-AJBirs
    JVCNC
    JVCNC --- ---
    +1
    tak kouknul jsem se na signaly co generuje grbl a zjistil

    rychlost se meni kazdych 10 mS a v mem pripade o cca 500 hZ, tedy acc/dec rampa neni zrovna moc plynula.
    jeste musim zjistit jestli je fixni delta frekvence nebo casu.

    pokud bude fixni delta casu, coz bude nejpravdepodobnejsi, tak to znamena ze cim vyssi akcelerace tim bude vetsi tendence ztracet kroky behem rampy z duvodu skokove zmeny rychlosti, protoze s rostouci akceleraci poroste delta frekvence. Tedy kdyz uz motory ztraci kroky tak s plynulejsi rampou by je to jeste neztracelo protoze prubeh rychlosti by byl plynulejsi

    https://i.postimg.cc/SKVHFqNh/grbl-step2.png

    https://i.postimg.cc/dQXPVqRQ/grbl-step1.png
    SALAM23
    SALAM23 --- ---
    JVCNC: me ta posledni verze 1.1 dela nejakou neplechu celkove - nejlip mi funguje verze 0,9 - ta mi chodi bez chyb - tak to jeste treba vyzkousej,treba se neco zmeni
    TEAPACK
    TEAPACK --- ---
    THERIDANE: ad JOG - to je ten problém, mělo by to fungovat stylem stiknutí tlačítka -> JogOn, release->JogOff ... nikoli neustále posílat instrukci posuň se o (rychlost opakování klávesy*rychlost posuvu) :-/
    JVCNC
    JVCNC --- ---
    1 odpověď
    SALAM23: tak hraju si s UGS platform a tam se to chova stejne, behem pauzy neni mozny zadny pohyb, snad teda na to neni nejaky extra figl nebo nastaveni primo v grbl o kterem zatim nevim. Pouzivam offic hotovy HEX v1.1

    jinak UGS platform ma zatim nejrychlejsi zpracovani g kodu z tech 3 sw co jsem zkousel, tedy i nejake jemnejsi 3D jako formicky s tim asi uz pujdou delat
    SALAM23
    SALAM23 --- ---
    +1
    dneska jsem malinko laboroval s Machem 3 a usb - testuju novy drivery a napadlo me,ze by sel mach rozchodit se Simaticem HMI - po chvilce laborovani a badani po netech se neco podarilo rozhybat,po dalsi chvilce jsem nasel screen pro Sinumerik a malinko ho prekopal na Simatic - zatim to teda vsechno testuju,ale zda se,ze bude mach plne ovladatelnej - jen jeste musim natukat vsechny hodnoty do desky





    JVCNC
    JVCNC --- ---
    no nemoh jsem spat tak jsem zkusil jeste GRBL s grblgui, ktere je pro zmenu napsane v jave. Reakce fajn, vykresleni rychle, GUI minimalisticke, vcelku nic to neumi ale hlavne to pomalu odesila gkod, tedy rychlost zpracovani jen par desitek radku/s, mam pocit ze bCNC je o neco rychlejsi (ale ne nejak zasadne).
    JVCNC
    JVCNC --- ---
    JVCNC: taky pak jeste linuxcnc realne vice nez 1000 radku gkodu /s realne nemuze zpracovat, protoze uz nema kdy casteji menit frekvence signalu. Coz by nemuselo jeste tolik vadit, ale na tyhle parametry se zamerim az pozdeji.
    JVCNC
    JVCNC --- ---
    1 odpověď
    THERIDANE: ja tam hlavne nikde nenasel zadne volani opengl, vse to kresli pres tinker a jestli ten to pak kresli pres opengl je vzhledem ktomu ze to posila porad vsechny data uz celkem jedno.

    no ono by si grbl vsechny prichozi prikazy melo hned zpracovat a buffer uvolnit, jestli tot ak dela nevim ale jestli ne tak se snadno naplni a pak uz proste nebude nic prijmat. Co ma pak ve svem look ahead bufferu je uz jedno melo by stacit poslat feed hold, podobne jako to dela u pauznuti obrabeni (kde mi prijde ze je ale taky nejaka prodleva). Spise podezrivam ze to maji udelane tak, ze pri OnKeyDown posilaji data ale pri OnKeyUp uz ten feed hold neposlou a tak se vse odeslane zpracuje nez se stroj zastavi. Jak to je udelane ve skutecnosti uz studovat nebudu, tohle je proste problem.

    On LinuxCNC je poplatny dobe vzniku, navic na akademicke pude i kdysy vznikal a dal se to uz jen nabaluje do sileneho molochu a celkove vubec ta koncepce je dneska uz hodne prezita. Me osobne prijde ze jednoduche veci resi zbytecne slozite a to uz je i to grbl pokrocilejsi v tom ze SW ukoluje HW na urovni pohybovych vektoru i kdyz nestastne skrz g kody narozdil od linuxCNC a dalsich kde SW ukoluje HW na urovni frekvence signalu, resi jitter frekvence aktualizace rychlosti PIDkou kde ta frekvence je jen 1kHz kdyz to pritom muze delat i HW s frekvenci stejnou jako je frekvence vystupniho signalu ale hlavne ze to s mesou umi generovat 4MHz, jenze k cemu je to dobre kdyz frekvence zmeny frekvence signalu je jen 1kHz.
    JVCNC
    JVCNC --- ---
    SALAM23: dobre vedet, vzykousim
    THERIDANE
    THERIDANE --- ---
    2 odpovědi
    JVCNC: bCNC je pomalý protože kreslí 3D pohled v immediate mode (na každej bod několik volání funkcí) a navíc na hlavním GUI vlákně, je to dost prasácky napsaný. Pořád ale lepší než LinuxCNC, který je psaný úplně stejně prasečím akademickým stylem, ale ještě navíc v nečitelným Tcl.

    Důvod, proč to zastaví až chvíli po uvolnění klávesy, je buffer seriovýho portu - čím víc povelů na jog se tam nahromadí, tím dál to pojede.
    SALAM23
    SALAM23 --- ---
    2 odpovědi
    JVCNC: Me to pausnuti a nasledny pohyb masinkou funguje,kdyz dam play,tak najede na pozici kdy jsem zapauzoval a pokracuje dal - testovano v Easelu a Ugs - to asi bude problem toho bCNC
    JVCNC
    JVCNC --- ---
    3 odpovědi
    tak jsem si zacal hrat s GRBL, flashnuti hotoveho HEXu bylo bezproblemu ze SW jsem zacal s bCNC a zde nekolik prvnich postrehu, tedy takova moje minirecenze a vlastne muzu pokracovat v odpovedi na dotaz co komercni systemy nabizi navic.

    GUI je takove topornejsi, ne moc uplne user friendly. Ikonky mi nektere prijdou silene jako pravitko pro sondu, káča jako vřeteno, svinovaci metr pro jednoduche sondovani.

    odezva programu je ponekud pomalejsi, aktualizace polohy nastroje a souradnic, prekresleni zobrazeni strojnich drah, coz je dano asi tim ze to bezi pod pythonem kterej je proste pomalej. Na hrani doma OK, v praci bych u toho vyrost.

    odezva JOGovani, pres tlacitka na monitoru OK i kdyz taky o neco pomalejsi ale sipkama na klavesnici vidim jako problematicke, Kdyz sipku pustim, stroj jeste kus ujede nez vubec zacne brzdit. Cim dyl jedu pomoci klavesnice tim deele to pak jede kdyz sipku pustim. Tohle vidim jako docela dost nebezpecny a kriticky nedostatek.

    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.

    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. Nevim jestli to je pouze vlastnosti bCNC nebo jestli to je nemozne by design u GRBL obecne. To by mi pri pouziti docela dost vadilo, docela jsem si zvyknul ze jednim tlacitkem stroj zastavi, vypne vystupy, vyjede z rezu a druhym tlacitkem zase vse co bylo vypnute zapne, vrati se do rezu a pokracuje. Tedy krome 2 tlacitek pause/stop a run/continue pro zminene ukony nepotrebuju.

    k nastaveni toho moc neni, je srozumitelne. Jen se mi nepovedlo zapnout soft limity. Napred jsem povolil homovani, pak soft limits a porad hlasi last error $20=1, ale asi nevadi, moje podezreni vzhledem k tomu ze 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.

    no to bude zatim vse, zatim jsem jen flashnul arduino a spustil bCNC. Nez zkusim sondovani atd. tak to budu muset pripojit ke stroji. Napred to ais jeste pripojim na log. analzyator a kouknu se na casovani signalu, prubehy rychlosti a reakcni dobu na podnety.

    Vzhledem k cene tomu nema smysl asi neco vycitat, na doma je to za malo penez docela dost muziky a pro stroje v cenove kategorii 10-15k kc to je vcelku adekvatni rizeni. Pro stroje drazsi cenove kategorie bych asi sahnul uz po necem jinem a osobne se mi to libi vic nez napr mach3 (i pres ponekud kostrbate GUI bCNC)

    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.

    stejne tak tvrzeni k verzi 1.1 ze overridy jsou bezne pouze na prumyslovych strojich neni zrovna moc pravdive, overridy jsou jednou z nejzakladnejsichi funkci CNC ridicich systemu uz velice dlouho pred grbl i na hobby strojich.

    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.

    Kliknutím sem můžete změnit nastavení reklam