Akcelerace a S krivky

[pavel-gravos]

Pro me nepouzitelne, v tom se asi vyzna jen autor,
navic to zrejme sezere strasne moc casu, ja mam jen ARM7 na 60MHz, ne cele xGHz PC.
Ale mluvil jsi o nejakem jednoduchem FIR filtru, to bylo zajimavejsi.
Uz jsi dodelal ten vlastni driver? Vypadalo to nadejne a pak ticho.
P.

[ledvinap]

Pro me nepouzitelne, v tom se asi vyzna jen autor,
navic to zrejme sezere strasne moc casu, ja mam jen ARM7 na 60MHz, ne cele xGHz PC.

V tomhle ma EMC trosku vyhodu - vykonu je spousta, takze se spousta veci da resit 'matematicky' a neni treba resit slozite optimalizace.
Reseni S-krivek by stacilo prekreslit na papir. Pokud by se ignorovala moznost zmenit feed_override, tak se to o neco zjednodusi. Vicemene nejslozitejsi pak bude vypocet kdy zacit brzdit, a mozna by byla mozna optimalizace (pocitat to odzadu jako akceleraci). Vykonove si to moc neumim predstavit, ale bude to nejaky konecny pocet nasobeni na krok...

Ale mluvil jsi o nejakem jednoduchem FIR filtru, to bylo zajimavejsi.

Kdysi byl na linux-cnc.org odkaz na disertacni praci, ktera to resila. Bohuzel je ted nefunkcni/nemuzu to najit.
Neco je tady" http://ieeexplore.ieee.org/stamp/stamp. ... r=05152296" onclick="window.open(this.href);return false;

Hodne zjednodusene a mozna nespravne je vychozi myslenka v tom, ze pokud aplikuji na rychlost linearni transformaci/linearni filtr tak je celkova ujeta vzdalenost stejna. Mimo jine je to pouzito na blending navazujicich segmentu. A v pripade vhodne zvoleneho filtru je mozne limitovat jerk a dalsi derivace.

Bohuzel jsem dost na hranici sveho chapani prislusne matematiky, takze je pro me dost casove narocne si to srovnat v hlave ..

Uz jsi dodelal ten vlastni driver? Vypadalo to nadejne a pak ticho.
P.

Nebyl jsem schopen si poradit s vibracemi (mid-band instability). Pak mi zacal dochazet dostupny vykon MCU a myslenka mereni proudu z bocniku na kazdem mustku zacala byt prilis komplikovana. Takze mi pred par dny prisly obvody na mereni proudu na principu HAL, takze ted pracuju na jejich dobastleni a pak zkusim pokracovat. Nektere veci by to mohlo zjednodusit. A cilove asi vidim jako velmi rozumny prechod na ST ARMy, vykon navic bude hodne znat ..

[sidonie]

Ale to jsou prece 2 ruzne veci:
jedna je pouziti jine akcelerace pro obrabeni a jine pro prejezdy - celkem schudne
druha je prejit z jedne rychlosti na jinou rychlost a tu rychlost menit
se zmenou akcelerace = S krivka - obtizne

A jak chceš přejít mezi dvěma stavy? Prostě tam skočíš po nohách z mostu a budeš doufat, že je tam dost vody aby jsi si nezlomil nohy?
Psal jsem, že přechod mezi těmi dvěmi akceleracemi bude nutný nějak řešit, možná by stačilo jen zastavit na určitou dobu, ale takový pohyb bude na stroji vypadat nepřirozeně, trhaně.

[Honza - GRAVOS]

při možnosti jiné akcelerace (lineární) pro posuvy a jiné akcelerace (lineární) pro rychloposuvy je to jednoduché, stroj mezi posuvem a rychloposuvem a pak následně mezi rychloposuvem a posuvem stejně musí zastavit a při tom zastavení se dá změnit.

možna by nebylo od věci se s diskuzí ohledně akcelerací, s-křivek atd. přesunout jinam, to už tématu moc neodpovídá.

[Radek-B]

No v prve rade to Yishin Li provozuje na nerealtimove verzi systemu , pres USB s 7i43(pro mne trosku problem). Je to pouzitelne a po nurbsech to jezdi brilantne a plnou max. rychlosti jaka je vubec mozna. Zadne sekani ci trhani v draze proste neni a ono to jezdi rychle i zatacky ..

Urcite se znova mrknete na ta videa a vsimnete si jak to krasne jezdi, to jsou ty spravne prumyslove pohyby!!!

Yishin ma ponekud nezvladnute generovani programu pres Rhino pomoci spouteni scriptu. jako drahu pro stroj musite umet zadat prostorovy nurbs, knots, vahy, a kontrolni body (uplne stejne jako by jste ho kreslili v CAMU). Implementace v EMC je prorostla tak ze nejake vycteni funkci a pouziti jinde je na hoooodne dlouho, hosi sikmooci na tom dost zamakali(makaji stale a jak se divam tak akzdy den makaji) a nurbs + jerk opravdu zmakli. Co se mi nelibi tak tam maji par siditek (parametru) ktere nejsou ve svete velkych masin a tim padem vznika dost problem z postem u bezne pouzivanych CADU.

program pro nize uvedene video vypada viz. priloha foot.ngc
http://www.youtube.com/watch?v=BraEMAu5UkY" onclick="window.open(this.href);return false;
originalni fce G6.2 pro fanuc viz. priloha fanuc.ngc
moje verze pro EMC fanuc.ngc

[Radek-B]

Ale to jsou prece 2 ruzne veci:
jedna je pouziti jine akcelerace pro obrabeni a jine pro prejezdy - celkem schudne
druha je prejit z jedne rychlosti na jinou rychlost a tu rychlost menit
se zmenou akcelerace = S krivka - obtizne

A jak chceš přejít mezi dvěma stavy? Prostě tam skočíš po nohách z mostu a budeš doufat, že je tam dost vody aby jsi si nezlomil nohy?
Psal jsem, že přechod mezi těmi dvěmi akceleracemi bude nutný nějak řešit, možná by stačilo jen zastavit na určitou dobu, ale takový pohyb bude na stroji vypadat nepřirozeně, trhaně.

Dobra pripominka, stavu kdy je potreba matematicky zvlast osetrit prave vzniklou situaci je zhruba 7. A spocitat misto kdy konci S krivka je opravdu orisek

RADEK

[Radek-B]

http://www.youtube.com/watch?v=eltogURP-Fg" onclick="window.open(this.href);return false;

Projekt roku 2010 T-support + VUT Brno (teda alespon myslim a pokud se mylim omlouvam se)

Tu je krasne videt co dela vysledna obrabeci rychlost pri zadani drahy pomoci interpolace G1, tak jak to delame vsichni a jak se zmeni pri zadani pomoci prevodu drahy na bikubickou splinu , u siemense funkce POLY. U fanuku fce G5.1. Nurbsy jezdi jeste lepe protoze krivka je nahrazovana vice nez 4-mi body jako u fce POLY.

RADEK

[sidonie]

při možnosti jiné akcelerace (lineární) pro posuvy a jiné akcelerace (lineární) pro rychloposuvy je to jednoduché, stroj mezi posuvem a rychloposuvem a pak následně mezi rychloposuvem a posuvem stejně musí zastavit a při tom zastavení se dá změnit.

možna by nebylo od věci se s diskuzí ohledně akcelerací, s-křivek atd. přesunout jinam, to už tématu moc neodpovídá.

Zastavit právě nemusí, ale rozhodně pro začátek je lepší něco než nic, jen se bude muset rychloposuv vypínat dřív jak 1 mm před obrobkem, to by v takovémhle řešení nemuselo fungovat, ale 5 mm na rozjezd pracovního posuvu musí stačit rozhodně.

[robokop]

to video me docela bavi
tam si vpodstate stezujou ze kdyz tam poslou kod v G01 tak to nedodrzuje rychlost a resi to jako problem
muj klient pouziva uz par let GSK kde jsme z casovych duvodu a lenosti napsali post tak ze generuje pouze G01
vsechny listy vrtuli ma tedy pouze z G01 a system vzdy dodrzuje rychlosti vyjma useku kde se reverzuje a pod.
jezdi se 1.5m/min

mozna to neni az tak o s krivkach jako o tom jak kdo umi zvladnout navaznost jednotlivych segmentu a interpretovat G-kod
pokud vim tak gravos taky zvlada miliony usecek bez problemu pritom na tom samem programu se treba siemens zazere a neda slusnou rychlost

[Radek-B]

to video me docela bavi
tam si vpodstate stezujou ze kdyz tam poslou kod v G01 tak to nedodrzuje rychlost a resi to jako problem
muj klient pouziva uz par let GSK kde jsme z casovych duvodu a lenosti napsali post tak ze generuje pouze G01
vsechny listy vrtuli ma tedy pouze z G01 a system vzdy dodrzuje rychlosti vyjma useku kde se reverzuje a pod.
jezdi se 1.5m/min

mozna to neni az tak o s krivkach jako o tom jak kdo umi zvladnout navaznost jednotlivych segmentu a interpretovat G-kod
pokud vim tak gravos taky zvlada miliony usecek bez problemu pritom na tom samem programu se treba siemens zazere a neda slusnou rychlost

Chlape ty si uplne mimo.

RADEK

[sidonie]

Nejsem žádnej odborník, ale myslím, že robokop má pravdu. Na tom videu je to na 100% o postu z CAM a jejich optimalizaci. Jestli že něco napíšu ručně, tak to musí fungovat v pohodě, ale pokud to samé vypadne z CAM na desetitisíce úseček, tak bývá neřešitelný problém, hlavně to nejde editovat na stroji, ale musí se zase do CAMu a všechno znova, taková práce je na ...

[Radek-B]

Tak ted nevim jestli sem z Marzu nebo co ??? Nebo tomu fakt nerozumim. Zacali jste se bavit o Jerku, Nurbs a Spline a o tom ze kdyz se to aplikuje , tak se ze stroje stane bezpecne letadlo s brilantnimi vysledky. Pak prijde nekdo s tim ze G1 je v podstate funkce s kterou neni problem a ze to je to prave orechove pro vyrobu tvarovych ploch. Vytkne umeni pouziti Cad/Camovskych post funkci , proti cemuz nic , ale pritaka mu jiny co to pise zasadne rucne

Jedine co je fakt ze jsme v nevhodnem vlakne.

RADEK

[Honza - GRAVOS]

to nedodržení nastavené rychlosti při použití G1 je problém ŘS, které zpracovávájí aktuálně jen 1 řádek dopředu např. siemens 802 i při nastavené continuous path při G1 jede momentálně maximálně jen takovou rychlostí, aby byl schopen po rampě na konci následujícího vektoru zastavit do nuly, dál prostě nevidí. Nevím jak je to u jiných ŘS, ale konkrétně u toho siemens 802 to tak je (moc pěkně je to i v manuálu znázorněno na grafech). u GVE64 to je podobné, jede se aktuálně maximálně jen takovou rychlostí, aby bylo možné zastavit po rampě do nuly ne však na následujícím vektoru, ale až na konci bufferu, ve kterém jich je 420, což umožní to, aby nastavená rychlost byla dodržena do určité rychlosti i na křivce složené z mnoha relativně krátkých vektorů (g1), už jsem o tom psal zde http://www.c-n-c.cz/viewtopic.php?f=67& ... 009#p68009" onclick="window.open(this.href);return false;

[robokop]

no mozna jsme vsichni z marsu a hledame reseni ve slozitych S krivkach kdyz je podobneho vysledku mozne docilit daleko jednoduseji

[Radek-B]

to nedodržení nastavené rychlosti při použití G1 je problém ŘS, které zpracovávájí aktuálně jen 1 řádek dopředu např. siemens 802 i při nastavené continuous path při G1 jede momentálně maximálně jen takovou rychlostí, aby byl schopen po rampě na konci následujícího vektoru zastavit do nuly, dál prostě nevidí. Nevím jak je to u jiných ŘS, ale konkrétně u toho siemens 802 to tak je (moc pěkně je to i v manuálu znázorněno na grafech). u GVE64 to je podobné, jede se aktuálně maximálně jen takovou rychlostí, aby bylo možné zastavit po rampě do nuly ne však na následujícím vektoru, ale až na konci bufferu, ve kterém jich je 420, což umožní to, aby nastavená rychlost byla dodržena do určité rychlosti i na křivce složené z mnoha relativně krátkých vektorů (g1), už jsem o tom psal zde http://www.c-n-c.cz/viewtopic.php?f=67& ... 009#p68009" onclick="window.open(this.href);return false;

Vetsina systemu zpracovava dopredu jen jeden radek, je to dano i tou funkci G1. A pro to jsou na strojich i funkce jine ktere toto resi (G64, G5 ,G6 , M90 a dalsi). Avsak pri pouziti primo pri G1 je potreba se zamyslet a zvolit vhodne parametry pro chovani filtru, anebo treba bikubickeho propoctu, jinak nebude dodrzena draha.
Takze mate v GVE funkci lookAhead ? Ctete drahu dopredu a vyslednou rychlost pocitate dle jeji celkove delky (co uhel mezi useky). Planner vydava body drahy tak ze pokud vi ze se nebude zastavovat tak nebrzdi na zadnem useku. Mezibody se vydavaji v periode casovace ? Umite fci G64 ? Jak potom zastavujete v mezibode (kde je konec drahy) kdyz konec useku lezi v pravem uhlu k useku dalsimu ?
Take nema cenu se bavit o rychlostech mensich nez 1m/min (spis vice) pri tak male rychlosti je brzdeni spis nezadoucim jevem.
Nechtelo by to fakt jine vlakno ?

RADEK