• ú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.
    THERIDANE
    THERIDANE --- ---
    1 odpověď
    JVCNC: Je to pěkný, stylem trochu podobný systému PathPilot, ale obsáhlejší :)

    Na str. 25 máš myslím špatnej obrázek.
    JVCNC
    JVCNC --- ---
    1 odpověď
    je to teda jen pulka, ale i tak pochybuju ze si to nekdo precte, ale alespon jako inspirace by to fungovat mohlo
    JVCNC
    JVCNC --- ---
    +3
    Tak jo, mel jsem tu hodne kecu jak ma vypadat RS a dodelal jsem manual, tak se muzete podivat jak ma vypadat dle me:
    http://gravos.cz/download/doc/user-armoman_v1.99.pdf

    jsem autorem manualu a ridiciho systemu.
    THERIDANE
    THERIDANE --- ---
    Víte o někom v Praze, kdo by udělal kusový výpalky z 1mm plechu nejlíp na počkání? Za nějakou rozumnou cenu.
    HARVIE
    HARVIE --- ---
    Prodam dragchain 10x20mm, 3m za 800kc, k vyzvednuti temer kdykoliv Praha Brevnov.
    JVCNC
    JVCNC --- ---
    THERIDANE: na ten jsem koukali uz cca pred 2 lety kdyz se objevil ve foru o 3d tisku ale zavrhnuto kuli velkemu RDSon a ten me prave inspiroval k tomu co jsem se snazil protlacit. Verim ze bude fungovat lip nez ta toshiba ale topit bude stejne a jak jsem psal, i cip s RDSon 0.3 je pri 1A bez poradne udelaneho chlazeni problem. Nakonec do vyvoje pujde neco jineho ale treba na to jeste dojde.

    Jinak ten plynuly a tichy chod je u driveru s diskretnimi tranzistory dneska uz celkem standard, ty rezonance jsou problem spis u vetsich motoru, u malych, ktery ten TMC2130 uridi to az takovy problem nebyva, ale zlepseni samozrejme porad to je znatelne.
    THERIDANE
    THERIDANE --- ---
    1 odpověď
    JVCNC: Jestli se vám ještě chce, koukněte na tyhle :) https://www.ebay.com/itm/332702392866

    Form-factor podobnej, cena třetinová, 1.2 A trvale (značně realističtější), heatsink je na správné straně :D

    Je to implementace Trinamic TMC2130, true sine stepper driveru s klasickým step/dir nebo rychlým SPI rozhraním. Krokáč jede pak plynule a tiše jak brushless servo, používá se to na desktop mašinkách kde vibrace a rezonance krokáčů můžou způsobit problém.
    JVCNC
    JVCNC --- ---
    AKA_THE_A: +-, odecteno z laboratorniho zdroje s rozlisenim 10 mA, nebyl to uplne zajimavy udaj takze nebylo mereno presneji, i pri tom shutdownu tam nejake obvody zijou, stejne to bere i kdyz je to bez enable. ten thermal shutdown asi jen odpoji prave ten enable.

    zase aspon ma nejakou hysterezi tedy v nem zustane dokud teplota skutecne zase pod nejakou hodnotu neklesne. Jinde jsem videl i jinou implementaci a to ze to vystupy odpoji jen na chvilku (vypadne krok ale pak se zase hned zapne), tedy i pri tom shutdownu je schopne se to upect a ze to je v nem poznas jen podle toho ze motory se skubaj jak je to odpojuje ale jinak jede dal :D
    JVCNC
    JVCNC --- ---
    1 odpověď
    THERIDANE: jo, ted to tam vidim, jako 2.5 A by bylo jeste ok, kdyby to aspon odpovidalo tomu nastaveni, Jenze oni volove vsude kde se tyhle drivery prodavaji pisou papirove udaje samotneho chipu bez ohledu na implementaci. U chipu samotneho to chapu, vyrobce nemuze vedet jak se komu povede to teplo odvest ale ze to tam opise i vyrobce driveru a pak vsichni prodejci je uz zrada na zakaznikovy. Tedy pokud jsou u hotoveho driveru napsane nejake hodnoty, musi byt driver schopen pri techto hodnotach pracovat, jinak je to proste podvod. Pisu o hotovem driveru ne o cipu samotnem.

    0.5 je hodne, to jsem tam nejak prehlid, to proste nejak rozume v tomhle driveru fungovat nemuze. asi sazeji na to ze lidi budou nastavovat proud podle toho napeti a nebudou ho merit.

    ona tam matice prokovu je a na druhe strane je to rozlite, ale dost blbe se to teplo pak dostava jeste z toho ale i tak tomu pri tomhle RDS skrz prokovy moc neverim i kdyz by se to primacklo na neco co by to teplo odvedlo. Cip s RDSon 0.3 R se nam pres thermal pad na tluste medi do stran kde to slo do hlinikoveho tramku (ktery to odvadel i z vrchu cipu) uchladit povedlo docela dobre (pri 32 V 2.5 A a trvale zatizeni), u tohodle pouzdra to proste nejde protoze ma nohy kolem dokola navic idea byla pouzit hotove drivery tohoto typu za par korun, no zazrak se nekonal, driver je nepouzitelny a zustaneme u driveru s diskretnimi tranzistory.

    jen me tak napada ze asi i primo u pololu driveru kde pisou 1 - 1.5A bez chlazeni bude ve skutecnosti tak 0.5-0.7A, coz by asi jeste slo, i ten cip s RDSon 0.3 pri 1A bez chladice proste provozovat dlouhodobe nesel.

    no a jeste power down u tech driveru s trimrem pro nastaveni proudu je taky prakticky neresitelny.
    Jeste nejake drivery tohoto typu koupim a otestuju. vic me stoji ten cas pri testovani a mereni nez ten driver a nakonec ho nekde pouziju, ale aspon pro srovnani.

    taky jsem hledal jestli nekdo nekde meril skutecny proud pres bocnik u tehle driveru a nikdo nejak nic, vsude jen mraky videi jak ho nastavit ale nejake serioznejsi mereni nikde.

    Velka skoda ze pololu nastavilo tenhle standard na tak maly rozmer na kterem nic rozumneho s dobre vyresenym chlazenim vymyslet nejde.
    THERIDANE
    THERIDANE --- ---
    1 odpověď
    JVCNC: Ty 4 A jsou z Absolute Maximum Ratings, operační maximum je 3 A. FETy v tom mají Rds(on) 0.5 Ω, takže to topit bude dost, bohužel.

    Ty drivery co jste koupili jsou naprostá katastrofa, chladič je na špatné straně :-D ty ICs mají thermal pad, pod ním má být matice prokovů která teplo odvádí mědí na druhou stranu a tam má být pořádná soustava žeber. Přes epoxidový pouzdro je odpor vedení tepla řádově vyšší.
    AKA_THE_A
    AKA_THE_A --- ---
    1 odpověď
    JVCNC: wait, takže i v thermal shutdown to bere 10mA? (nezní to jako moc, ale je to ASIC a bez připojenýho motoru nic nedělá...)
    JVCNC
    JVCNC --- ---
    2 odpovědi
    tak,zkousel jsem v praci prosadit takovy napad, ktery vyustil v koupi 3 kusu driveru typu pololu, konkretne tento https://laskarduino.cz/motory-radice/230621-toshiba-tb67s109-driver-pro-krokove-motory.html

    papirove vypada uzasne, 50V 4A, tak jsme zacali merit a zjistili ze skutecnost je ponekud jina

    proud se nastavuje pomoci trimru, pres napeti, tedy zmerene napeti x 2 je nastaveny proud.
    prvni zadrhel byl ten ze max napeti co slo nastavit je necelych 1.8V, tedy misto 4A je maximalni nastavitelny proud 3.6A

    zacali jsme merit proud pomoci bocniku seriove ve fazi motoru a osciloskopu a misto nastavenych 3.6A jsme zmerili jen 2.4A.

    Pak jsme zkouseli napeti, uz pri 32V se driver vypne behem par sekund na thermal shutdown aniz by se stihlo ohrat pouzdro chipu, tedy aniz by byla moznost to teplo z nej jakkoliv dostat.

    Tedy zminka o hodnotach proudu a napeti u tohoto modulu jsou zcela neplatne a to i s jakkoliv aktivnim chlazenim, snad jedine ponorit do kapalneho dusiku. Prilozeny chladic je docela dost knicemu, montuje se jen pomoci samolepky a uzka mezera mezi zebrama zapricini ze bez vetraku bude chladici ucinek nizky. I tak i s tim chladicem uz na 24V 1.5A se nebyl schopen uchladit, coz nakonec nebylo zadne prekvapeni. Regulerni driver papirove stejnych parametru, ktery je ponekud vetsi, ma v sobe 8 velkych tranzistoru s ponekud mensim ztratovym teplem.

    Vzhledem k hodnotam proudu co lidi kolem 3d tiskaren stejnym zpusobem nastavuji i u jinych driveru tohoto typu a zminkach ze jim na to staci maly prilepeny chladic nebo i bez chladice a vzhledem k dalsim zkusenostem s temito chipy a jejich chlazenim usuzuji ze s proudem na tom budou stejne i ostatni drivery tohoto typu, tedy ze se neco nastavi ale skutecnost bude uplne jina. Tedy z meho napadu nakonec seslo, protoze vzhledem ke skutecnym vlastnostem to bylo neprosaditelne.

    Jedine co fungovalo skutecne dobre byl thermal shutdown, ktery vystup do motoru skutecne odpojil a driver ze zdroje bral jen 10 mA
    JVCNC
    JVCNC --- ---
    HARVIE: me je to vcelku jedno, ja se na to jen chtel kouknout protoze to zacina byt rozsirene, lidi po me zacinaji chtit postprocesory pro grbl a chtel jsem o tom vedet trochu vic nez jen to ze to existuje. Ke strojum pouzivam pokrocilejsi (a ponekud drazsi) HW a SW.

    HARVIE: ta presnost je asi ten duvod proc jsem se nikdy niceho kloudneho nedockal (po 2 hodinach jsem to vzdal, takze tezko rict jestli by z toho po 3 neco bylo ale myslim ze ne). nicmene lidi to pouzivaji a libi se jim to a na linuxu to mozna muze behat lip nez na win, tak jsem to doporucil.
    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.
    Kliknutím sem můžete změnit nastavení reklam