• ú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.
    TEAPACK
    TEAPACK --- ---
    JVCNC: Jen tak letmo jsem se dostal za stranu 40 a pěkné =) jen mi tam chybí HW kolečko, občas je potřeba koukat pod nástroj a hýbat jemně s mašinou ... =) (nebo aspoň při opravách, kterými se zabývám z 90% času... )
    JVCNC
    JVCNC --- ---
    THERIDANE: nojo, jsi prvni kdo si toho vsimnul, grafickou cast a obrazky budu resit nejak vzhledneji az ve verzi 2.0 az to prevedu do noveho vyvojoveho prostredi. Ted musim hlavne dopsat druhou cast manualu.

    myslis ten od Tormacha? ten je postaven na LinuxCNC a je mladsi, jestli se nepletu.
    jo jeste jsem zapomel dodat ze delam jen SW, HW dela kolega. SW jsem po nem prevzal mozna uz pred 10 lety a dneska je uz prakticky cely prepsany.

    jeste na tom dost prace bude, uz ted mam vyvojovy plan na dalsich 5 let.
    THERIDANE
    THERIDANE --- ---
    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 --- ---
    je to teda jen pulka, ale i tak pochybuju ze si to nekdo precte, ale alespon jako inspirace by to fungovat mohlo
    JVCNC
    JVCNC --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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.
    Kliknutím sem můžete změnit nastavení reklam