TEAPACK: super, díky, večer naposílám, jak se dostanu k domácí WS a vysmahnu nějaký výkres z toho pokus na 3D :-) (ten teda tím, že se mi zrealizovat do fyzické podoby nepovedl, není úplně vyzkoušený; respektive největší otazník je tam průměr toho vstupního otvoru, aby do toho ty O kroužky šly strčit, ale zároveň to i těsnilo. Nicméně můžu případně fyzicky dodat i tu hadici s perlátorem :-) )

SPM: to aby mohlo celkem snadno jít i z polyamidu =) hoď mi nějaký "výkres" s důležitými rozměry do pošty a kouknu jestli na to něco najdu ;)

Není tu někdo, kdo by zvládnul vyrobit z nerezu (nebo jiného nezávadného kovu, co přežije vodu) takovou dost atypickou vodovodní redukci?

Potřeboval bych váleček, který má uvnitř díru s M10x1mm závitem, do kterého potřebuju našroubovat konec nějaké takovéhle hadice https://www.hornbach.cz/p/celonerezova-hadice-mix-flex-3-8/10671066/ (komplikací je, že do válečku to potřebuju vsunout až po ty O kroužky, aby to těsnilo; tělo mimo ten závit má průměr 10,0, s O kroužky 11,5mm). A z vnější strany M22x1mm, na který našroubju perlátor.

Jsem si myslel, že to vytisknul na 3D tiskárně, ale dost jsem pohořel už na tom závitu M22x1. CAD to nemá v knihovnách, odmítá to vůbec nakreslit a když už mi tam takový nesmysl vyřeže, tak zase vznikne něco, co úplně nevypadá, že by šlo na FDM tiskárně vytisknout (SLA by to asi dala, ale z toho to pak zase nechci pít :-) )

LYCO: ja myslim ze bCNC si umi poradit jen s absolutnim souradnicovym systemem momentalne... aspon teda v pripadech kdy nejak procesuje g-kod. pokud ho jen posila bez zmen, tak to samozrejme nicemu nevadi.

Dangerous behavior of Autolevel with G53 · Issue #1076 · vlachoudis/bCNC · GitHub
https://github.com/vlachoudis/bCNC/issues/1076
Bad visualization of G53 moves · Issue #1485 · vlachoudis/bCNC · GitHub
https://github.com/vlachoudis/bCNC/issues/1485

Tak se pokouším frézovat DPS, a narazil jsem na ošklivý problém. Můj g-code má na začátku

G53 G00 Z-5.00000 (Retract to tool change height)

ale bCNC pošle jenom

G00 Z-5.000

tzn. provede pohyb v souřadnicích obrobku a do mé DPS vyvrtá gravírovací frézou díru cca 2mm v průměru. Děje se to jen pokud mám nasondovaná data pro autoleveling: když je smažu (Probe -> Autolevel -> Clear) tak se pošle správně. Když je načtu ze souboru, tak se to děje taky.

V GRBL mám $10 = 1 (zkoušel jsem i 3 a dělo se to samé).

Doufám že vás neprudím technickou podporou, jestli jo, tak npište a já se přesunu do pošty / do issue trackeru na Githubu.

LYCO: ono to casto ma v sobe bootloader, s trochou stesti ho tam dali i cinani. takze se to da prehrat pres usb. tak jako tak by se to nemelo bricknout. pico by melo jit pouzit, pokud to nema bootloader.

HARVIE: to jsem chtěl řešit až večer :-)

Je to něco custom. Má to procesor ATmega328 a drivery motorů DRV8825 připájené přímo na desce. Asi se to flashuje přes ISP? vidím 6 pinů označených GND, MOSI, 5V, RST, SCK, MISO. Programátor nemám (leda by se dalo něco vyimprovizovat z RPi pico).

LYCO: V zasade s tim problem nemam, kdyz udelas pull request do https://github.com/vlachoudis/bCNC/
tak se na to podivam a muzu to mergnout... Ale programovat to ted asi nemam cas. A bude potreba overit, ze to nerozbije funkcnost lidem co maj zaply to automaticky posilani...

LYCO: jaka deska to je?

HARVIE: na desku i na nastavení GRBL kouknu večer. Sám jsem zvědavý jestli ta deska bude aspoň připomínat něco normálního :)

HARVIE: jo, uvědomuju si že nemůžete podporovat každou čínskou hrůzu, to byste se zbláznili. Ale tady mi aspoň na první pohled připadá, že je problém jenom v nedefaultní konfiguraci, že by možná stálo za to tenhle případ podporovat.

Musím říct že do flashování firmwaru se mi moc nechce, bojím se že tu desku bricknu. Jako jasně, mohl bych potom koupit nějakou běžně používanou desku, nakreslit a vytisknout nějaký držák a běžet na tom, ale to je další balík práce (a peněz) do kterého se mi vůbec nechce :-(

HARVIE: to není poprvé co slyším podobné věci, proč ti číňani tak lžou? :-/

Dokonce nam tam jednou nekdo psal, ze ma GRBL 1.1, ale pak se ukazalo, ze cinani vzali GRBL 0.9 a upravili ho, ze vypisovalo verzi 1.1 i kdyz nebylo :-D

Usetris tim vsem spoustu problemu, protoze u bCNC vzdycky nekdo hlasi nejaky divny chyby. Pak se ukaze, ze pouziva nejaky cinsky firmware co se tvari jako GRBL, ale neni to GRBL. Nebo je znacne upraveny.

LYCO:
Ja si ted nejsem jistej, co dela $#
Ale trochu bych se bal, aby se to neinterpretovalo jeste predtim nez se sonda dotkne (dokud je v pohybu). protoze to neni standartni g-code.

Co to mas za desku? Na tech cinskejch casto jde rozjet GRBL z upstreamu...
Tedy to cos posilal: https://github.com/gnea/grbl
Muze bejt potreba ho trochu nakonfigurovat pred sestavenim, ale neni to zdaleka takova veda jako treba konfigurace firmware pro 3d tiskarny s barevnym displejem :-)

Jinak tohle mas spravne?

GRBL should be configured to use MPos rather than Wpos. This means that $10= should be set to odd number. As of GRBL 1.1 we recommend setting $10=3. If you have troubles communicating with your machine, you can try to set failsafe value $10=1.

HARVIE: okay, začínám tušit: https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/config.h#L164

Firmware je z Číny, netuším kde vzít zdrojáky abych to změnil :( myslíš že dává smysl abych doprogramoval do bCNC že po každém G38 pošle "$#"? Nechce se mi kompilovat vlastní firmware když neznám jak jsou připojené piny etc. a nevím jak tyhle informace zjistit.

LYCO: hm, možná to je jen pro GRBL 0.9? Na https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface o tom není ani zmínka (jen že je to výstup příkazu "$#").

Zkusil jsem to ručně přes picocom (sériový terminál) a skutečně tam ta odpověď není automaticky, ale $# ji normálně reportuje:

g38.2 z-10
ok
?<Idle|MPos:-113.000,-211.000,-34.505|FS:0,0|Pn:P|Ov:100,100,100>
$#
[G54:-113.000,-211.000,-34.500]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:-113.000,-211.000,-34.488:1]

HARVIE: v logu nic není (jen info že controller state je střídavě idle a running). Pro jistotu jsem to teď vyzkoušel na svém stolním počítači (Manjaro Linux) s bCNC čerstvě checkoutovaným z gitu:

 3200  git clone https://github.com/vlachoudis/bCNC.git
 3201  cd bCNC
 3202  python -m venv venv
 3203  . ~/venv/bin/activate
 3204  pip install .
 3205  python -m bCNC

a výsledek je stejný. V terminálu (záložka terminal v bCNC, co zobrazuje komunikaci s GRBL) taky všechno vypadá normálně, bCNC pošle G38.2Z-10F10, GRBL odpoví "ok"m několikrát po sobě.

Možná je divné (ale tady si nejsem jistý), že po každém sondování nevidím [PRB ...], to bych trochu čekal. Podle https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl by to měl posílat, ale možná bCNC nějak filtruje výstup?

LYCO: pust prosim bCNC v konzoli a podivej se, jestli to tam nevypisuje nejaky chybovy hlasky...

HARVIE: to zní moc hezky, ale já nemám tu modročervenou mřížku. Jak jsem psal, vůbec se nenasbírají data.

LYCO: Ja kdyz to delal poprve, tak me zmatla jedna vec:

bCNC umi nascanovat autoleveling data, na canvasu se objevi ta mrizka cervenomodra. Pak je potreba nastavit, ktera XY souradnice je 0 (to je casto ta sama, kde se nuluje Z). Autolevel je automaticky aplikovan pri odesilani kodu do CNC, neni potreba nic delat. bCNC zaroven umi aplikovat autolevel data na g-kod soubor. Na to velky pozor! Protoze kdyz uz data jsou nactena v bCNC a aplikuji se na g-kod. Jsou pak znovu aplikovana i na odesilany kod, coz zpusobi prekompenzovani na druhou stranu a autolevel je pak uplne k nicemu. Rucni aplikovani na nacteny g-kod je vhodne jen v pripade, ze data exportujeme pro pouziti s jinym senderem, ktery sam uz autoleveling nedela. (nebo pro bCNC, ve kterem nejsou autolevel data aktualne nactena = neni v nem modrocervena "sachovnice")

LYCO: říkal jsem si že bych do kódu přidal nějaké ladící výpisy a podíval se co se tam děje, ale v tuhle chvíli se soustředím na elektroniku a na ladění cizího kódu mi úplně nezbývá kapacita.