To je jiný level.
Kompenzaci bude dělat vyšší vrstva LinuxCNC (resp. asi to pojede v rychlostním režimu), a to tak bude úkolovat stepgeny.
Tady je teď řeč jen o té nejnižší vrstvě, tj. o úkolování těch stepgenů.
Mesa 7i90
Já ale přece ty StepGeny neúkoluji v žádném případě vzhledem k periodě Servo-Threadu, ale pouze je v periodě Servo-Threadu "aktualizuji". Tedy řeknu jim "máš být tam a tam" v polohovém režimu (nebo "jeď takovouhle rychlostí" v rychlostním režimu).
StepGen pak (bez ohledu na to jak moc pravidelně je "updatován" - to je mu skoro jedno pokud se nejedná o SW stepgen) udělá vše pro to, aby "okamžitě" dosáhl zadané polohy a uplatní vnitřní regulátor, který má k dispozici následující:
- požadovanou novou polohu (S2)
- precizní aktuální pozici (S1) (přečteno z akumulátoru pozice MESA přesnost něco kolem nanometrů),
- aktuální rychlost (V1) (tato je přesně zadaná z minulé "aktualizace" v Servo-Threadu)
- povolenou maximální akceleraci (Amax) a povolenou maximální rychlost (Vmax) (aby mohl spočítat minimální chybu v době dosažení zadané polohy)
Akcelerace je (tak nějak slovy řečeno) zmněna rychlosti v daném čase, takže aby mohl určit "novou rychlost" a dodržet limity Maximální Akcelerace (Amax)tak má k dispozici:
- přesný čas minulé "aktualizace" (T1)
- přesný současný čas (T2)
- současnou rychlost (V1)
Novou požadovanou rychlost (V2) spočte dle algoritmu minimalizující chybu v bodě požadované polohy (S2)
(vzoreček z hlavy nevypotím, protože už to je pár let co jsem se v tom hrabal a není uplně jednoduchý a je větvený/podmíněný v závislosti na různých stavech a možnostech do jakého stavu se může dostat atd...)
Nově zadaná rychlost (V2) pak ještě musí ležet v intervalu: V1 +- (Amax * (T2 - T1))
a nakonec ořezání maximální povolené rychlosti (samože v obou směrech):
pokud V2 > Vmax tak V2 = Vmax (pohyb v kladném směru)
pokud V2 < -Vmax tak V2 = -Vmax (pohyb v záporném směru)
Všimni si, že v uvedených vzorečcích nikde nefiguruje perioda - Nově zadaná rychlost (a tedy frekvence) není nijak přímo vázaná na Servo-Thread.
(v horším případe je vázaná na BaseThread pokud bych uvažoval Software StepGeny - což ale není oblastí našeho zájmu)
(ona v kódu tedy na některých místech ve skutečnosti figuruje i ta perioda respektive její délka, ale to teď není podstatné)
Ještě se vrátím k tomu skoro jedno. Není mu to úplně jedno, protože akcelerace je měněna skokově s frekvencí ServoThreadu.
Pokud by byla perioda update přiliš dlouhá, nebo nepravidelná, tak by byla akcelerace taky tak nějako nepravidelná a protože hračka "necítí" rychlost, ale "cití" zrychlení tak by to mělo nejspíše vliv na "plynulost" pohybu - možná nějaké vibrace atd.
Stepgen sice "umí teoreticky nekonečnou akceleraci", ale protože programátor nespadl z hrušky tak i ten elektronický StepGen dodržuje nastavenou maxmální akceleraci (Amax) (která musí být trochu větší než tak kterou je omezen Trajectory Planner)Mex píše: ↑10. 7. 2018, 3:56 Moc mi není jasné, jak se pak úkolují stepgeny v polohovém režimu (tedy např. že mají dojet na pozici 45.7 kroků), když jim neřekneš čas, za který tam mají dorazit, nebo rychlost, kterou tam mají dojet. U mechanických systémů je to snadné - když úkoluješ servo po 1ms, tak tam se prostě pohyb zprůměruje mechanickou setrvačností. Ale elektronický stepgen umí teoreticky nekonečnou akceleraci.
Sranda je v tom, že v polohovém režimu jim neříkáš "KDY" mají být na místě, ale "KDE" (S2) mají být "TEĎ" (T2) (a oni udělají maximum aby se tam "střelhbitě" dostali s dodržením "vnitřních limitů rychlosti a akcelerace")
To, že chodí správná požadovaná poloha "pravidelně", je úkolem Trajectory-Planeru, který počítá "novou požadovanou polohu (S2)" každý Servo-Thread a to je pak ještě přepočítáno přes Kinematiku stroje pro převod Kartézských souřadnic polohy dané G-Kódem na jednotlivé osy - tedy vstupy jednotlivých StepGenů).
Všimni si, že i tady je požadovaná poloha počítána v tom samém Servo-Threadu a tedy případná nepravidelnost má malý vliv na správný výpočet požadované polohy, protože i tento počíta s aktuálním přesným časem (dle HPET)
Po pochopení těchto souvislostí teprve zjistíš, jak je "nemožné" odtrhnout vlastní generování polohy od "jádra LinuxCNC" (nezamněňovat s RealTime jádrem Linxu - operačního systému), tak aby nepotřeboval relativně pravidelný Servo-Thread. V současném pojetí celého "jádra LinuxCNC" není prostě možné ho "odtrhnout" od Real-Time a udělat z něj pouhý "sender" G-Kódů, protože výpočet kinematiky a polohy je docela fest svázán se správným generováním aktuální požadované polohy pro Servo-Thread a není zdaleka tak triviální jak si nezasvěcení myslí .....
... jsem se zase nějako rozepsal
Díky moc za spoustu informací. 
Ale tohle není na jedno přečtení, budu to muset přečíst víckrát a fest se nad tím zamyslet.
Takhle z voleje mi totiž pořád není jasné, proč stepgen těch třeba 100 kroků, které dostal za úkol udělat, neudělá maximální možnou rychlostí (samozřejmě se započtením nastavené Vmax a Amax).
Ale dám si na večeři porci vtipné kaše a ono mi to snad dojde.
Díky.
Ale tohle není na jedno přečtení, budu to muset přečíst víckrát a fest se nad tím zamyslet.
Takhle z voleje mi totiž pořád není jasné, proč stepgen těch třeba 100 kroků, které dostal za úkol udělat, neudělá maximální možnou rychlostí (samozřejmě se započtením nastavené Vmax a Amax).
Ale dám si na večeři porci vtipné kaše a ono mi to snad dojde.
Díky.
Ale on se snaží ze všech sil udělat "těch třeba 100 kroků maximální možnou rychlostí", ale tak, aby v případě potřeby akceleroval, nebo rovnou brzdil vzhledem k aktuální rychlsti, kterou se pohybuje a zároveň tak, aby na konci "dobrzdil" a "nepřestřelil".
On počítá dopředu jednak v rámci periody (Hmm tady je asi to kde používá "odhadovanou fixní periodu" - tedy nastavený ServoThread) a zároveň v rámci cílové polohy, která může být stovky period daleko.
Žena zapomněla nakoupit, a tak jsem neměl z čeho uvařit vtipnou kaši, tudíž mi to moc nemyslí.
Jestli jsem správně pochopil Tvůj popis, tak výpočet toho nového obsahu stepgenů probíhá zpětně, se zpožděním jedné periody servocyklu.
A ten údaj o délce servoperiody tam vstupuje, ale taky zpětně. Takže se ve výpočtu nepočítá s nějakou definovanou délkou periody, ale vezme se délka té předchozí, a předpokládá se, že ta následující bude stejně dlouhá.
Pokud to tak je, tak jádro LinuxCNC si myslí, že je už o krok dál, než v reálu je. Tedy že si myslí, že už stojí v poloze S2, ale driver Mesy (tedy modul hostmot2.ko) teprve posílá do Mesy náplň stepgenů pro přejezd z S1 do S2.
Nebo tam tenhle zpožděný výpočet není a zpožděně se bere jen délka periody, tj. rozdíl současného reálného času a reálného času minulé periody?
Zřejmě by mohlo fungovat oboje, řekl bych.
Předpokládám, že ta Tvá věta "on počítá dopředu jednak v rámci periody ... a zároveň v rámci cílové polohy, která může být stovky period daleko" se už nevztahuje na stepgeny. Ten výpočet na mnoho period dopředu už má snad na starostí někdo jiný, někdo výše postavený.
Díky.
-
robokop
- Site Admin
- Příspěvky: 22386
- Registrován: 10. 7. 2006, 12:12
- Bydliště: Praha
- Kontaktovat uživatele:
napada me co se stane kdyz ten stepgen bude muset dorovnat nejakou vetsi odchylku
max f je z configu
akcelerace je u stepgenu patrne interni konstanta
co udela servo je asi jasne
co ale udela krokac kdyz mu poskoci mzikove kmitocet a mechanika ma nejakou setrvacnost
a s interni akceleraci stepgenu nemuzu hnout (nebo muzu?), nikdy jsem si toho nevsimnul
mozna to je duvod proc tam cpou tu pidku
max f je z configu
akcelerace je u stepgenu patrne interni konstanta
co udela servo je asi jasne
co ale udela krokac kdyz mu poskoci mzikove kmitocet a mechanika ma nejakou setrvacnost
a s interni akceleraci stepgenu nemuzu hnout (nebo muzu?), nikdy jsem si toho nevsimnul
mozna to je duvod proc tam cpou tu pidku
Vsechna prava na chyby vyhrazena (E)
Přehodil jsem Mesu do pozičního režimu, což díky podrobnému návodu od fupeho bylo velmi snadné (děkuji).
Funguje to parádně. Pochopitelně zmizelo dojíždění osy na konci. Zatím jsem nenašel nic, co by se snad zhoršilo.
Jen drobná poznámka, kdyby to někdo chtěl podle téhož návodu realizovat (což vypadá, že lze rozhodně doporučit):
je tam překlep, ten řádek má vypadat takhle:
net x-pos-cmd => hm2_5i25.0.stepgen.01.position-cmd
(šipka je obrácená naopak)
Dotaz na Mesa-odborníky: nemáte prosím náhodou nějaké "latency-kurvítko" ?
Chtělo by to něco, čemu by se zadal rozsah a ono by to záměrně zhoršilo latenci o náhodný čas od nuly až po zadaný rozsah (náhodně, v každé servo-periodě jinak). Tedy nástroj pro otestování vlivu latence na výsledné generované signály.
Pokud o nějakém nevíte, tak asi budu musel nějaký napsat. Snadno bych to uměl přidat do driveru Mesy, takže pak by obsluha Mesy byla v každé periodě jinak dlouhá. Ale to asi není optimální místo, protože mezitím už bude načtena hodnota timeru HPET. Takže by to asi chtělo dát někam hned na začátek zpracování servo-periody.
Díky všem.
Funguje to parádně. Pochopitelně zmizelo dojíždění osy na konci. Zatím jsem nenašel nic, co by se snad zhoršilo.
Jen drobná poznámka, kdyby to někdo chtěl podle téhož návodu realizovat (což vypadá, že lze rozhodně doporučit):
je tam překlep, ten řádek má vypadat takhle:
net x-pos-cmd => hm2_5i25.0.stepgen.01.position-cmd
(šipka je obrácená naopak)
Dotaz na Mesa-odborníky: nemáte prosím náhodou nějaké "latency-kurvítko" ?
Chtělo by to něco, čemu by se zadal rozsah a ono by to záměrně zhoršilo latenci o náhodný čas od nuly až po zadaný rozsah (náhodně, v každé servo-periodě jinak). Tedy nástroj pro otestování vlivu latence na výsledné generované signály.
Pokud o nějakém nevíte, tak asi budu musel nějaký napsat. Snadno bych to uměl přidat do driveru Mesy, takže pak by obsluha Mesy byla v každé periodě jinak dlouhá. Ale to asi není optimální místo, protože mezitím už bude načtena hodnota timeru HPET. Takže by to asi chtělo dát někam hned na začátek zpracování servo-periody.
Díky všem.
StepGen počítá (a musí si umět poradit) i s případem, kdy nedokáže dojet na zadanou pozici (S2) v rámci jediné periody.Mex píše: ↑10. 7. 2018, 10:16 Jestli jsem správně pochopil Tvůj popis, tak výpočet toho nového obsahu stepgenů probíhá zpětně, se zpožděním jedné periody servocyklu.
A ten údaj o délce servoperiody tam vstupuje, ale taky zpětně. Takže se ve výpočtu nepočítá s nějakou definovanou délkou periody, ale vezme se délka té předchozí, a předpokládá se, že ta následující bude stejně dlouhá.
Pokud to tak je, tak jádro LinuxCNC si myslí, že je už o krok dál, než v reálu je. Tedy že si myslí, že už stojí v poloze S2, ale driver Mesy (tedy modul hostmot2.ko) teprve posílá do Mesy náplň stepgenů pro přejezd z S1 do S2.
Nebo tam tenhle zpožděný výpočet není a zpožděně se bere jen délka periody, tj. rozdíl současného reálného času a reálného času minulé periody?
Zřejmě by mohlo fungovat oboje, řekl bych.
Předpokládám, že ta Tvá věta "on počítá dopředu jednak v rámci periody ... a zároveň v rámci cílové polohy, která může být stovky period daleko" se už nevztahuje na stepgeny. Ten výpočet na mnoho period dopředu už má snad na starostí někdo jiný, někdo výše postavený.
Díky.
Většinou je to případ kdy se snaží dohna relativně malou odchylku v rámci jedné až dvou period. Zpětně si dopočítává rychlost kterou se pohybuje zadaný bod (S2). Odhadovaná rychlost (V2) v době (T2 + Delka periody) je ((S2 - S1) / (T2 - T1)). Algoritmus počítá s tím že v době dojetí na nové místo v budoucnosti musí mít "nějakou" rychost (V2) a "nějakou" polohu (S2).
Algoritmus regulátoru rychlosti nemůže dobržďovat na nulu v každém novém zadaném bodě kam směřuje, ale sleduje (dopočítává/odhaduje) i rychlost jakou se má v "cíli" pohybovat. Tento odhad je zatížen chybou nepřesné délky skutečné periody, ale chyba není kumulativní a v dalším cyklu je okamžitě kompenzována. Servo-Thread běži dostatečně rychle na to aby se tyto chyby neprojevovaly na plynulosti pohybu.
Pokud je pozice zadávána Trajectory-Plannerem, tak je rychlost (V2) relativně dobrým odhadem jak rychle se má v místě určení nadále pohybovat. Pokud je místo (S2) někde "daleko" (klidně stovky period) a od minula se nemnění, tak je požadovaná rychlost v místě "cílu" nulová ((S2 - S1) == 0) a algoritmus StepGenu počítá s tím, že tam musí co nejrychleji dojet, ale zároveň i dobrzdit (tedy mít taky nulovou rychost) v místě (S2)
Jedním z případů kdy toto "musí" řešit byla implementace Joggingu přes klávesnici, kdy se do stepgenu dala prostě a jednoduše požadovaná poloha (S2) "kraje stolu" (samozřejmě příslušný kraj dle směru šipky). Tedy spíš musel, protože se implementace Joggingu zmněnila při zmněně oddělení "Joints/Axis" a nevím jak je to teď po novu).
Výpočet probíhá prostě tak nějak +- "Periodu kolem" aktuálního času. Z každé strany časového úseku použije co je k dispozici. Jak jsem řekl není to žádný jednoduchy vzoreček, ale spíše algoritmus.
Akcelerace a rychlost u StepGenu není "vnitřní" konstanta, ale je nastavována v .halrobokop píše: ↑10. 7. 2018, 11:32 napada me co se stane kdyz ten stepgen bude muset dorovnat nejakou vetsi odchylku
max f je z configu
akcelerace je u stepgenu patrne interni konstanta
co udela servo je asi jasne
co ale udela krokac kdyz mu poskoci mzikove kmitocet a mechanika ma nejakou setrvacnost
a s interni akceleraci stepgenu nemuzu hnout (nebo muzu?), nikdy jsem si toho nevsimnul
mozna to je duvod proc tam cpou tu pidku
Něco jako (natvrdo v HALu):
setp hm2_5i24.0.stepgen.02.step_type 0
setp hm2_5i24.0.stepgen.02.control-type 0
setp hm2_5i24.0.stepgen.02.maxaccel 650.0
setp hm2_5i24.0.stepgen.02.maxvel 140
Nebo v HALu použiji (mohu použít) data z .ini souboru
[JOINT_0]
TYPE = LINEAR
FERROR = 0.050
MIN_FERROR = 0.010
MAX_VELOCITY = 115.0
MAX_ACCELERATION = 560.0
Povolená akcelerace pro jednotlivé osy (nezamněnovat se StepGeny respektive Joints) je pak definována v .ini nějako takhle:
[AXIS_X]
MAX_VELOCITY = 115.0
MAX_ACCELERATION = 560.0
No a nakonec do toho vstupuje i akcelerace a rychlost Trajectory-Planeru
[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = mm
CYCLE_TIME = 0.0050
DEFAULT_LINEAR_VELOCITY = 10.0
MAX_LINEAR_VELOCITY = 108.334
MAX_LINEAR_ACCEL = 550.0
Vztah mezi OSOU "AXIS" a "JOINTem" (tedy přímo aktuátorem respektive StepGenem) je dán KINEMATIKOU stroje
Všimněte si že "nejrychleji" ("nejostřeji") se musí pohybovat "JOINTS" (tedy SteoGeny), Trocha pomalejší jsou pak "OSY" stroje. No a "nejlínější" pak musí být Trajectory Planner.
(U strojů s "TRIVIÁLNÍ KINEMATIKOU" jsou OSY a JOINTS svázány jedna ku jedné a mohou tedy mít nastaveny stejně Max_Rychlost a Max_Akceleraci)
Tož asi tak nějak.....
PS: Hrnu to "z patra" tak mě kdyžtak nechytejte za slovíčko a nějakou tu chybku. Uvádím principy, nikoliv konkrétní přesné vzorečky.
PS2: Rozdělil bych to i barvičkama aby to bylo přehlednější, ale nějako nevím v novém rozhraní fóra jak na to
Chvílemi mám pocit, že si ta moje Mesa ze mě dělá srandu.
Na prvním obrázku jsou signály DIR a STEP pro krátký g-kód, jen jeden pohyb tam a zpět.
Podstatné jsou ty spodní signály, vyšší je DIR a pod ním je STEP.
Co je špatné jsou ty jehly na signálu DIR. Mesa si prostě na 1ms jen tak přepne signál DIR na opačný směr, a to za plné rychlosti signálu STEP. Takže je to evidentně chyba, není to žádné dorovnání rychlosti a podobně.
Na druhém obrázku je detail té jehly. Je vidět, že to skutečně na dobu jedné servo-periody přepne při plné rychlosti jízdy směr. Opět jsou to ty signály dole. Je tam vidět, že nemá vůbec žádnou snahu třeba zpomalit STEP, jede prostě pořád na plný kvalt, ale na chvíli zařadí zpátečku.
No a občas Mesa vymyslí takový podivný konec pohybu, jako je na 3. obrázku. Je tam vidět, jak osa dojíždí a brzdí. Ale pak se najednou zase rozjede, a to bez rampy rovnou na plnou rychlost, a navíc během toho pohybu ještě přepne signál DIR.
Z toho jsem teda fakt tumpachovej.
Sledovali jste někdo podrobněji průběhy, které vám generují vaše Mesy?
Případně neměl třeba někdo nějaký problém s LPT Mesou na dlouhém kabelu, že by tam vznikaly chyby? Tím by se snad dala vysvětlit ta jehla, ale ten podivný konec jízdy na 3. obrázku snad ani ne.
Dělá to s jak s originálním firmware od Mesy, tak i s mým upraveným. Měnil jsem kabely, logický analyzátor, několikrát udělal OFF/ON jak Mesy tak LinuxCNC, ale funguje to pořád stejně blbě.
Nemáte prosím někdo nápad?
Na prvním obrázku jsou signály DIR a STEP pro krátký g-kód, jen jeden pohyb tam a zpět.
Podstatné jsou ty spodní signály, vyšší je DIR a pod ním je STEP.
Co je špatné jsou ty jehly na signálu DIR. Mesa si prostě na 1ms jen tak přepne signál DIR na opačný směr, a to za plné rychlosti signálu STEP. Takže je to evidentně chyba, není to žádné dorovnání rychlosti a podobně.
Na druhém obrázku je detail té jehly. Je vidět, že to skutečně na dobu jedné servo-periody přepne při plné rychlosti jízdy směr. Opět jsou to ty signály dole. Je tam vidět, že nemá vůbec žádnou snahu třeba zpomalit STEP, jede prostě pořád na plný kvalt, ale na chvíli zařadí zpátečku.
No a občas Mesa vymyslí takový podivný konec pohybu, jako je na 3. obrázku. Je tam vidět, jak osa dojíždí a brzdí. Ale pak se najednou zase rozjede, a to bez rampy rovnou na plnou rychlost, a navíc během toho pohybu ještě přepne signál DIR.
Z toho jsem teda fakt tumpachovej.
Sledovali jste někdo podrobněji průběhy, které vám generují vaše Mesy?
Případně neměl třeba někdo nějaký problém s LPT Mesou na dlouhém kabelu, že by tam vznikaly chyby? Tím by se snad dala vysvětlit ta jehla, ale ten podivný konec jízdy na 3. obrázku snad ani ne.
Dělá to s jak s originálním firmware od Mesy, tak i s mým upraveným. Měnil jsem kabely, logický analyzátor, několikrát udělal OFF/ON jak Mesy tak LinuxCNC, ale funguje to pořád stejně blbě.
Nemáte prosím někdo nápad?
Na prvním obrázku jsou na tom signálu DIR 3 krátké pulzy.
Jeden je do log.1 a další dva jdou do log. 0.
Jaké jsou mezi těmito pulzy časy?
Na první pohled to vypadá, že je časový rozestup stejný.
A pak bych se podíval, jestli je tento čas mezi těmito pulzy stejný jako čas mezi začátkem generování STEP a prvním pulzem DIR do log. 1.
Na první pohled to vypadá na nějakou časovou závislost.
Jeden je do log.1 a další dva jdou do log. 0.
Jaké jsou mezi těmito pulzy časy?
Na první pohled to vypadá, že je časový rozestup stejný.
A pak bych se podíval, jestli je tento čas mezi těmito pulzy stejný jako čas mezi začátkem generování STEP a prvním pulzem DIR do log. 1.
Na první pohled to vypadá na nějakou časovou závislost.
Vývoj HW, návrhy DPS (OrCAD, Eagle, Pads)
Že by černá magie?
zkoušel si kořen mandragory? Stači kousek, nastrouhat na desku primo na FPGA pole.
A ted vážně. Máš k tomu připojený motory? jestli to na chvili prepne směr a přitom tam pere kroky, tak se prece musí ten motor utrhnout. nebo se pletu?
Když napises podmínky pokusu, idealne i třeba s kodem, kterej poustis, tak to muzu vyzkoušet na 7i76e, která leží prede mnou na stole, hned vedle analyzatoru. taky jede na 1kHz tak by to mělo byt stejny.
nikdy jsem neslysel, ze by mesa stepgeny delaly nekomu problém, ani me ne. mam 7i43 a chodi jak z praku.
stepgen je pro všechny karty stejnej, takze jestli je to v tom, tak by se to měli projevit i u me. každopádně tomu nerozumim.
Martin
zkoušel si kořen mandragory? Stači kousek, nastrouhat na desku primo na FPGA pole.
A ted vážně. Máš k tomu připojený motory? jestli to na chvili prepne směr a přitom tam pere kroky, tak se prece musí ten motor utrhnout. nebo se pletu?
Když napises podmínky pokusu, idealne i třeba s kodem, kterej poustis, tak to muzu vyzkoušet na 7i76e, která leží prede mnou na stole, hned vedle analyzatoru. taky jede na 1kHz tak by to mělo byt stejny.
nikdy jsem neslysel, ze by mesa stepgeny delaly nekomu problém, ani me ne. mam 7i43 a chodi jak z praku.
stepgen je pro všechny karty stejnej, takze jestli je to v tom, tak by se to měli projevit i u me. každopádně tomu nerozumim.
Martin