Rozjezd a doběh KM

Krutor · 30. 1. 2009, 7:52

Zdravím, píšu vlastní CNC software, kde softwarově generuju kroky pro KM na LPT. Mám tam samozřejmě rozjezdové a doběhové rampy, neboli zrychlení a zpomalení. Moje otázka je, zda rampa musí vždy začínat, resp. končit na nulové rychlosti, nebo zda můžu začít třeba na 30% maximálních otáček. Chápu, že to závisí na setrvačných hmotách, to už bych si doladil, jde mi jen o princip zda zrychlovat přesně od nuly, resp. od momentální rychlosti, nebo tam může být nějaký rychlostní skok (nespojitost na grafu rychlosti v čase).

Praktický důsledek bude třeba když pojedu po dráze, na které bude ostrý zlom např o 45 stupňů - budu v tomto místě muset úplně zastavit a znovu se rozjet v jiném směru, nebo to do určité rozumné rychlosti můžu prostě natvrdo "zalomit" ?

Díky

teebee · 30. 1. 2009, 8:06

Profi masiny to maju vyriesene tak, ze na takychto zlomoch sa robi kruhova interpolacia (pri hrubovani vacsi polomer) a tym sa dosahuje vysia priemerna rychlost. Pokial vies nejak rozlisit, ci ide o hrubovanie alebo dokoncovanie, urcite by som to skusil.

Ak budes motoru programovo davat rychlostne soky, vnesies tam nepresnosti drahy, ktore budu rozsahovo mozno rovnake ako pri tej interpolacii a hlavne budu neprdvidatelne.

PavelZ · 30. 1. 2009, 8:21

Uvedená problematika je např. v Machu3 řešena volbou buď:
a) Exact Stop - zastavuje natvrdo na konci každé entity (G0, G1 či G2/3)
b) Constant Velocity - ty zlomy jede pokud možno konstantní rychlostí v závislosti na nastavených parametrech, max. dovoleného zrychlení apod. - je to docela složité, doporuču ji trochu málo o tom počíst. Každopádně uvedený režim zaobluje rohy. Prostě je to věda, hlavně když se to má udělat jako koordinovaný pohyb více os.

sysel · 30. 1. 2009, 8:48

PavelZ píše: b) Constant Velocity - ty zlomy jede pokud možno konstantní rychlostí v závislosti na nastavených parametrech, max. dovoleného zrychlení apod. - je to docela složité, doporuču ji trochu málo o tom počíst. Každopádně uvedený režim zaobluje rohy. Prostě je to věda, hlavně když se to má udělat jako koordinovaný pohyb více os.

Přesně jak píšeš, nedávno jsem gravíroval písmena o velikosti 5mm a špička A a špička V tam prostě nebyly a byl to domršený patvar, stačilo jen mu ubrat rychlost z 1900 na 500 a hned to vypadalo jako písmenka

k · 30. 1. 2009, 10:51

ako bolo spomenute exact stop zastavuje kady pohyb na konci .. exact path je o inom ten dodrzaiva drahu a spomaluje a zrychluje podla potrieb .. ma ale volitelny parameter P ktory hovori, ze mozem sa odklonit od pozadovaneho pohybu max o P pricom mozem zachovat vyssiu rychlost.

BTW. prv ako zacnete pisat svoj soft skuste EMC .. a ak vam na nom nieco nechodi ako pitrebujete je lepsie to upravit priamo v jeho zdrojaku ako pisat celucicky soft od zaciatku. (vyhoda EMC je prave to, ze je to otvoreny zdrojak).

Krutor · 30. 1. 2009, 3:25

Díky!
Tak to tak vidím, že žádné rychlostní skoky se konat nebudou. Ovšem aby soft nejel přesně po zvolené dráze a "šidil" rožky, to nepřipadá v úvahu.

Výhoda vlastního softu je ta, že si to naprogramuju, jak chci já. Takže pro hrubování budou rádiusy, pro finiš ostré rohy.

Vím, že trochu zbytečně programuju něco, co už spousta lidí vyřešila (a líp), ale já bych na 100% žádný open-source soft nebyl schopnej rozběhnout, natož upravit. Jsem rád, že se vyznám ve svém.

Výhoda je, že jsem si nadefinoval svůj vlastní jazyk, kterým budu stroj programovat. Rozhodně je čitelnější než G-kód, takže ho můžu psát přímo z hlavy.

Radek-B · 30. 1. 2009, 3:51

Krutor píše:Díky!
Výhoda je, že jsem si nadefinoval svůj vlastní jazyk, kterým budu stroj programovat. Rozhodně je čitelnější než G-kód, takže ho můžu psát přímo z hlavy.

Tak ten jazyk by mne zajimal , co jsi vlastne vymyslel, co je citelnejsi nez G kod.

V podstate by ses divil kolik jazyku pro ruzne stroje existuje a dokonce i ten
DIN ISO kod ma nespocetne variaci a moznosti.
Dej nejaky priklad.

RADEK

30. 1. 2009, 5:45

je fajn ze je citelnejsi ale urcite do toho dej alespon par zakladnich Gcek jinak to pujde blbe postovat
ruzne postprocesory jsou ruzne omezene ve tvorbe vystupniho kodu

sysel · 30. 1. 2009, 6:52

Krutor píše:Výhoda je, že jsem si nadefinoval svůj vlastní jazyk, kterým budu stroj programovat. Rozhodně je čitelnější než G-kód, takže ho můžu psát přímo z hlavy.

Taky bych ho chtěl vidět.... Doufám, že pak dáš ukázku?

CZ_Pascal · 30. 1. 2009, 7:32

Kdyz se do dusledku zamyslite tak zjistite, ze nikdy nenabihate plynule na danou rychlost, ale hned prvni krok je rozbeh z nuly na nejakou rychlost a pak zase stop. A dokud to bude rizeno krokove (tedy step / dir) tak to nikdy nebude jinak. Krokovy motor spojeny s nejakym systemem ma vzdy nejakou maximalni rychlost na kterou se chytne bez rampy, ale tato rychlost je pro ruzne motory-systemy-parametry ruzna. Zmnena proudu, nebo vstupniho napeti driveru take ovlivni tuto rychlost u stejneho systemu. Takze pokud skakat na nejakou rychlost tak jedine pri konkretnich podminkach na konkretnim stroji. A pokud system snese relativne velkou pocatecni rychlost tak snese urcite i relativne velke celkove zrychleni takze se vyhoda pocatecniho skoku temer smaze. Spis bych se soustredil na kvalitu rampy. Nikdo nerika ze musi byt ciste lichobeznikova (tedy s konstantni akceleraci nebo deceleraci). I tyto parametry se daji mnenit v prubehu rampy a dosahnout tak zase o kus lepsich parametru. Kdybyste meli v aute nebo vytahu tak ostre rampy jak se pouzivaji pro cnc tak by to z nas vymlatilo dusi. A to ze to stroj prezije neznamena, ze by se pri idealnejsich podminkach (plynula zmnena akcelerace) necitil o podstatny kus lepe.

PavelZ · 30. 1. 2009, 8:46

Přesně jak říká CZ_Pascal, opravdu kvalitní pohyb je ten, který má spojitý průběh zrychlení. U lichoběžníkové rampy jsou skoky ve zrychlení, což zcela logicky způsobuje rázy. O něčem takovém např. mluví ArtSoft, že bude(je) implementováno v novém produktu Quantum.
A přitom stačí z lichoběžníkového průběhu rychlosti udělat parabolické, harmonické či cykloidní ... hned to bude na dynamice pohybu znát. Nemyslím, že by to bylo tak výrazně programově složité.

30. 1. 2009, 9:07

spousta systemu uz S krivky podporuje
nebo nejake vylepseni akcelerace decelerace
staci si precist dokumentaci

PavelZ · 30. 1. 2009, 9:16

robokop píše:spousta systemu uz S krivky podporuje
nebo nejake vylepseni akcelerace decelerace
staci si precist dokumentaci

Při naší smůle to asi u EMC ještě nebude, co ? Alespon jsem to nikde v manuálu nenašel.

30. 1. 2009, 9:29

no pokud to tam neni nemuselo by byt az tak slozite to dopsat
pro nektere cleny urcite ne

PavelZ · 30. 1. 2009, 9:41

Na EMC Documentation Wiki je toto

3. Trajectory planning algorithms
EMC employs a trapezoidal velocity profile generator. The plot of the velocity vs. time has either constant velocity regions (cruise regions) or regions with constant acceleration/decceleration. The position is the integral of the velocity vs. time plot and thus consists of linearly increasing or decreasing regions corresponding to cruise phases in velocity, and parabolic regions which correspond to the acc/decceleration velocity regions.
The acceleration vs. time is piecewise continuous - but the jerk is infinite (where the acceleration changes or the velocity vs. time has a sharp 'corner'). There are jerk-limited or double-jerk-limited trajectory planners described in the litterature but they have not been implemented in EMC (yet?).
Something about time-optimality here ? (jerk or djerk planners are not time-optimal, the trapezoidal planner is ?)

Což chápu tak, že se sice s implementací uvažuje, ale zároven se zde tvrdí, že časově nejsou optimální.
Jinak zde http://thesis.lib.ncu.edu.tw/ETD-db/ETD ... 323107.pdf je kupř. trochu teorie (pozn. přeskočte prvních pár stránek s rozsypaným čajem, anglicky je to až dále

)