hospudka

[Mex]

Borec tady udělal "závod" mezi LinuxCNC a GRBL.
Změřil tam, že LinuxCNC 2.6 stejný G-kód při stejném nastavení stroje jel výrazně pomaleji než GRBL, LinuxCNC 2.7 s novým plánovačem pak jel zhruba stejně jako GRBL.
http://www.cnczone.com/forums/benchtop- ... ost1700148" onclick="window.open(this.href);return false;

[robokop]

Neznam grbl ale nemuze to byt tim ze ten planovac je jednodussi? Tedy ma min funkci?

[Mex]

Nevím, co znamena jednodušší.
Anijerking nemají myslím ani jeden z nich (mluvím o starém LinuxCNC 2.6). A co jiného tam může být jednodušší?
Rozdíl je podle mě v tom, že GRBL umí plánovat s ohledem na další vektory (look-ahead), kdežto starý LinuxCNC to neuměl. Je to až ve verzi 2.7.0, a ta už taky dosáhla zhruba stejného času.

[robokop]

no nic konkreniho
jen jestli je to treba porovnavka porovnatelneho?

[PAKO.ll]

trocha technické historie http://kybl.net/post/118432309615/stroj ... cribblercz" onclick="window.open(this.href);return false;

[4rest]

Myslím že ty fotky jsou z české správy sociálního zabezpečení, protože by se prý všechny staré dokumenty nevyplatilo digitalizovat.

[Mex]

jen jestli je to treba porovnavka porovnatelneho?

Porovnává doby vykonání stejného G-kódu na stejně nastaveném stroji.
Tak co tam může být neporovnatelné?
Pokud se dá předpokládat, že oba systémy dodrží maximálně nastavenou obálku (tj. max rychlost a max zrychlení), tak rozdíl může být jen v tom, že ten lepší dokáže analyzovat předem další kroky, takže zbytečně nebrzdí tam, kde by pak zase musel akcelerovat.
Nebo Tě napadá nějaké jiné vysvětlení?
Docela zajímavé by bylo vidět podobné srovnání mezi LinuxCNC 2.6, LinuxCNC 2.7, Mach3, Mach4 a nějakými "krabičkami" - GRBL, TinyG2, Gravos atd.
Mohli bychom nachystat nějaký testovací G-kód (asi nějaké 3D frézování), nadefinovat max. rychlost a zrychlení, a každý by to zkusil na tom, co má k dispozici.
Já bych uměl změřit LinuxCNC 2.6, GRBL a TinyG2.

[robokop]

no ja prave myslel ze to grbl je jen pro jednocipy a linuxcnc pro intel
takze mi to prijde neporovnatelne
ale jak pisu o grbl nic nevim
nevim o co slo

jinak ten test by mohl byt zajimavy
asi by to chtelo ale stanovit nejake univerzalni podminky coz nevim zda bude vubec korektne mozne
ale priblizit se tomu pujde

[CZ_Pascal]

Pokud se dá předpokládat, že oba systémy dodrží maximálně nastavenou obálku (tj. max rychlost a max zrychlení), tak rozdíl může být jen v tom, že ten lepší dokáže analyzovat předem další kroky, takže zbytečně nebrzdí tam, kde by pak zase musel akcelerovat.
Nebo Tě napadá nějaké jiné vysvětlení?

A v tomhle je přesně ten problém. Předpokládat se to možná dá, ale věřit se tomu nedá. Už dříve proběhlo porovnání MACH3 a LinuxCNC (Tehdy ještě EMC2) a světe div se MACH3 projel stejný kód rychleji
To se někomu znalému linuxu nezdálo tak napojil výstup Step/Dir co lezl z MACH3 přeš MESA kartu na LinuxCNC (na způsob zpětné vazby) a seldovali kde je ten zázrak že to MACH3 "dal" rychleji.
Zázrak se ale nekonal. Zjistilo se pouze že MACH3 si občas ulehčil žívot a nedodržel nastavené maximální rychlosti a zrychlení.

Pouhé porovnání rychlosti tedy bez detailního sledování (přesného měření) všech veličin (tedy i zrychlení a rychlosti) je velice zavádějící.

Bohužel nemohu dát konkrétní odkaz na ono porovnání, ale věřím, že kdo bude chtít tak si to do hodiny vygooglí.

Samozřejmě je možné že systémy které zvládají pouze triviální kinematiku stroje zvládají projet nějaký kód rychleji. LinuxCNC je trochu "bržděn" svou ohromnou flexibilitou, kde se ve všech aspektech uvažuje možnost stroje s netriviální kinematikou (různé hexapody, robotická ramena atd...) a zcela záměrně používá pro všechny jednotný (byť trochu složitější a možná malinko pomalejší) výpočtový model. Dalším faktem je že se jedná stále o systém vyvíjející se pod OpenSource licencí "hrstkou nadšenců" a je docela překvapivé že i za těchto podmínek má překvapivě dobré vlastnosti a živý/rychlý vývoj.
To se o spoustě OpenSource projektů říci nedá (jejich vývoj zanikne dříve než dosáhne spolehlivého dokončení/odladění)

[Pepa z depa]

.. PAKO.II ten kybl.net - dost dobrý, fotky i se zdroji jako třeba tahle kráska
http://biker-queens.tumblr.com/post/109 ... stumblrcom" onclick="window.open(this.href);return false;

[robokop]

no bylo by dost zajimave zpracovat nejake podminky + jejich kontrolu a sjet ten test treba i na profi systemech

[lubos]

Pokud by ten jakýkoliv test měl být objektivní musela by mašina mít pravítka někde vy se musela zaznamenta odchylka od polohy. Všichni třeba víme jak si mach zkracuje rohy a tak to může za určitých okolností u jiných systémů. Také není nezajímavý aspekt kdy zmáčknu třeba pauzu jak rychle systém zareaguje a jak přesně dobrzdí a znovu se při pokračování obrábění strefí. Obecně je podle mě porovnávání systémů stejné jako porovnávání aut. Nelze jednoznačně říci co je obecně lepší.

[robokop]

no ja tim predchozim prispevkem myslel treba nejaky bazmek na stul ktery se soucasne upne do vretena a bude odmerovat skutecne pohyby stroje
tim se podchyti treba i pohony ale to je v dusledku kolikrat taky prace systemu

jde tim pak porovnat opravdu ruznorode technologie rizeni

[Mex]

A v tomhle je přesně ten problém. Předpokládat se to možná dá, ale věřit se tomu nedá. Už dříve proběhlo porovnání MACH3 a LinuxCNC (Tehdy ještě EMC2) a světe div se MACH3 projel stejný kód rychleji

No při vší úctě k LinuxCNC (taky ho používám a mám rád), tak ve starých verzích (tj. před 2.7) byl jenom velmi jednoduchý plánovač trajektorie. Takže překonat ho rychlostí asi zase nebylo nijak nereálné.
Pokud mám trajektorii poskládanou ze spousty krátkých useček (a klidně můžou být dohromady v přímce), tak aspoň u mě to starý LinuxCNC projede hodně pomalu.

P.S. Přiřadil jsi můj citát 4restovi. Mně to nevadí, ale aby to nevadilo jemu, že mu vkládáš do úst něco, s čím třeba nesouhlasí.

[CZ_Pascal]

P.S. Přiřadil jsi můj citát 4restovi.

...aha... to jsem nějako zmotal (jsem měl za to že když označím text a ten dám citovat tak si to forum správně "přebere" komu výrok patří)

No při vší úctě k LinuxCNC (taky ho používám a mám rád), tak ve starých verzích (tj. před 2.7) byl jenom velmi jednoduchý plánovač trajektorie.

Ano s tím nelze než souhlasit. Sám jsem zde (možná mezi prvními) poukazoval na novější verzi s přepracovaným "Trajectory Plannerem" která zvládá "koukat" více než jediný "krok" dopředu.

Pokud mám trajektorii poskládanou ze spousty krátkých useček (a klidně můžou být dohromady v přímce), tak aspoň u mě to starý LinuxCNC projede hodně pomalu.

...právě případ kdy je "milion" krátkých úseček nelišící se od přímky o určitou vzdálenost řešil (nebo se pokoušel řešit) "Naive Cam Detector". Maximální vzdálenost se řešila parametrem Q v příkazu G64 ("path blending")

Mimochodem implementace starého "Path Blendingu" (tedy skutečného prolínání jednotlivých ůseček) byla co do spojitosti akcelerace výhodnější než současné nahrazení kruhovým obloukovým segmentem, který má ze své podstaty akceleraci nespojitou. Nicméně bylo podstatně složitější jej "matematicky uchopit" pro použití v současném "Trajectory Planneru" který umí "koukat" několik (dle nastavení) kroků dopředu.