• ú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: 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.
    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.
    Kliknutím sem můžete změnit nastavení reklam