toto som zistil dávnejšie:
AXIS.n.f-error-lim je hodnota povolenej odchýlky. Pri odchýlke väčšej ako táto hodnota, vyhodí systém Following error.
Jej hodnotu je možné meniť z halcmd. Je načítaná v pine ini.n.min_ferror
No a pri štarte sa nastaví hodnota zapísaná v INI súbore, v sekcii AXIS ako MIN_FERROR
Mesa 7i90
Jakou verzi LCNC používáš?
Ješte do verze něco kolem 2.5.x se používal stepgen v pozičním režimu, ale pak někdo z vývojářů usoudil, že bude lepší vložit do toho PIDku a použít velocity mode. Nejak uplne nevim jestli je to dobře nebo špatně, každopádně chvíli po tehle změne jsem ladil jednu mašinu a hrozně jsem se divil, že mi všechny osy dotahujou pozici klidně i tři sekundy, tak jsem to zkoumal, zvednul Proporcionalni složku a zlepšilo se to. Nakonec jsem celou PIDku vyhodil, vratil control-type na 0 (position mode) a pripojil požadovanou polohu primo na stepgen a chodilo to úplně výborně.
Jak píšeš o FERROR a MIN_FERROR tak to trochu v takovémhle zapojení strací logiku. Krokovej motor nemá od přirody zpětnou vazbu. To znamena, že PID nemá pořádně podle čeho regulovat. Vycházi z toho co mu zpátky posílá stepgen kterej je rizenej v rychlostnim rezimu, ale o realny pozici stejne nic nevi, jenom si ji dopočítává.
system posílá požadovanou pozici, kterou si sam vypocita podle dane akccelerace do PID, ta to přepočítá na zakladě nastavení PID na rychlost, pošle rychlost do stepgenu, kterej si dopočítá pozici a pošle je zpátky. Když je rozdil vetší než FERROR hodi chybu. Takže ladim PID jako blb aby to sedělo, ale přitom podle mě stačí posilat rovnou pozici do stepgenu v pos mode a zpatky do systemu požadovanou pozici. Stejne předpokladam, že se motor neutrhnul a jsem tam kde mám byt. PID mi s timhle stejne nepomuze. Mozna se nejak mění charakteristika rizeni, ale netusim jak.
Umím si rychlostni rezim predstavit u serva se zpetnou vazbou, ale u krokače mi to prijde zbytecny.
Prostě to na mě dělá dojem, že je tam ta PIDka na nic. možná se pletu, pak mě někdo prosím opravte.
Martin
Ješte do verze něco kolem 2.5.x se používal stepgen v pozičním režimu, ale pak někdo z vývojářů usoudil, že bude lepší vložit do toho PIDku a použít velocity mode. Nejak uplne nevim jestli je to dobře nebo špatně, každopádně chvíli po tehle změne jsem ladil jednu mašinu a hrozně jsem se divil, že mi všechny osy dotahujou pozici klidně i tři sekundy, tak jsem to zkoumal, zvednul Proporcionalni složku a zlepšilo se to. Nakonec jsem celou PIDku vyhodil, vratil control-type na 0 (position mode) a pripojil požadovanou polohu primo na stepgen a chodilo to úplně výborně.
Jak píšeš o FERROR a MIN_FERROR tak to trochu v takovémhle zapojení strací logiku. Krokovej motor nemá od přirody zpětnou vazbu. To znamena, že PID nemá pořádně podle čeho regulovat. Vycházi z toho co mu zpátky posílá stepgen kterej je rizenej v rychlostnim rezimu, ale o realny pozici stejne nic nevi, jenom si ji dopočítává.
system posílá požadovanou pozici, kterou si sam vypocita podle dane akccelerace do PID, ta to přepočítá na zakladě nastavení PID na rychlost, pošle rychlost do stepgenu, kterej si dopočítá pozici a pošle je zpátky. Když je rozdil vetší než FERROR hodi chybu. Takže ladim PID jako blb aby to sedělo, ale přitom podle mě stačí posilat rovnou pozici do stepgenu v pos mode a zpatky do systemu požadovanou pozici. Stejne předpokladam, že se motor neutrhnul a jsem tam kde mám byt. PID mi s timhle stejne nepomuze. Mozna se nejak mění charakteristika rizeni, ale netusim jak.
Umím si rychlostni rezim predstavit u serva se zpetnou vazbou, ale u krokače mi to prijde zbytecny.
Prostě to na mě dělá dojem, že je tam ta PIDka na nic. možná se pletu, pak mě někdo prosím opravte.
Martin
Ja mám na frézke servá s ovládaním STEP-DIR. Pidku som vyhodil, riadenie prepol control-type na 0 a funguje to. bez spätnej väzby nemá zmysel špekulovať o niečom inom.
Na plazme (vo výstavbe) mám servá ovládané +-10V a spätnú väzbu enkodérom. Tam PID funguje celkom fajn. nastavoval som zatiaľ P a I zložku. Možno v reálnom stroji bude treba doladiť ešte D.
Na plazme (vo výstavbe) mám servá ovládané +-10V a spätnú väzbu enkodérom. Tam PID funguje celkom fajn. nastavoval som zatiaľ P a I zložku. Možno v reálnom stroji bude treba doladiť ešte D.
Taky jsem nějako nepochopil proč je defaultně (tedy zkrze konfigurátor) po StepGeny použita PID.
Stepgen jako takový má v sobě "vlastní" regulační smyčku.
Všechny příkazy polohy (data) které posílá HostMot2 (tedy něco jako "driver MESY") do FPGA jsou rychlostní.
Ta regulační smyčka obsahuje nějaký "jakože FeedForward" regulátor kombinovaný s PID.
Kdysi jsem to trochu studoval, ale už je to hodně dlouho tak si absolutně přesný vzorec výpočtu nepamatuju.
Výpočet funguje tak že dává jako vstup do vnitří PID "budoucí polohu" (tedy něco jakože FeedForward, ale trochu jinak pojatý).
On tedy nereguluje "současnou chybu" (tak jako klasická regulační smyčka) , ale snaží se minimalizovat "chybu budoucí" (tedy tu která bude v době následující periody).
Dodržuje přitom povolené rychlostní a akcelerační limity (které z podstaty věci musí být "rychlejší" než akcelerační a rychlostní limity Trajectory Planneru)
Pokud se požadovaná (zadávaná) poloha "pohybje" rychleji než stíhá vnitřní regulační smyčka (dodržující "svoje" limity) tak se Following Error zvýší nad "povolený" (viz vysvětlení Robokopa o pár příspšvků výše) a skončí to chybovou hláškou.
Snad jsem to vysvětlil alespoň trochu srozumitelně
V podstatě Vstupem do HostMot2 v polohovém módu je požadovaná poloha a zpětně z FPGA si tahá skutečnou polohu a na základě toho jede "vnitřní" regulační smyčka která udržuje rychlost tak aby byla odchylka co nejmenší.
Stepgen jako takový má v sobě "vlastní" regulační smyčku.
Všechny příkazy polohy (data) které posílá HostMot2 (tedy něco jako "driver MESY") do FPGA jsou rychlostní.
Ta regulační smyčka obsahuje nějaký "jakože FeedForward" regulátor kombinovaný s PID.
Kdysi jsem to trochu studoval, ale už je to hodně dlouho tak si absolutně přesný vzorec výpočtu nepamatuju.
Výpočet funguje tak že dává jako vstup do vnitří PID "budoucí polohu" (tedy něco jakože FeedForward, ale trochu jinak pojatý).
On tedy nereguluje "současnou chybu" (tak jako klasická regulační smyčka) , ale snaží se minimalizovat "chybu budoucí" (tedy tu která bude v době následující periody).
Dodržuje přitom povolené rychlostní a akcelerační limity (které z podstaty věci musí být "rychlejší" než akcelerační a rychlostní limity Trajectory Planneru)
Pokud se požadovaná (zadávaná) poloha "pohybje" rychleji než stíhá vnitřní regulační smyčka (dodržující "svoje" limity) tak se Following Error zvýší nad "povolený" (viz vysvětlení Robokopa o pár příspšvků výše) a skončí to chybovou hláškou.
Snad jsem to vysvětlil alespoň trochu srozumitelně
V podstatě Vstupem do HostMot2 v polohovém módu je požadovaná poloha a zpětně z FPGA si tahá skutečnou polohu a na základě toho jede "vnitřní" regulační smyčka která udržuje rychlost tak aby byla odchylka co nejmenší.
Děkuji všem za odpovědi. 
To naroubování PID na řízení stepgenu se mi od začátku zdálo podezřelé, nakonec už jsem to tady psal. PID se hodí pro řízení systému se setrvačností nebo dopravním zpožděním, ale ne pro eliminaci náhodných nepredikovatelných odchylek (tedy nepřesnosti v časování servo-threadu).
Jestli je MIN_FERROR skutečně FERROR pro pomalé pohyby, tak pak by to vysvětlovalo, proč zvýšením hodnoty se to spravilo. Ale pak by se to snad mělo jmenovat něco jako SLOW_FERROR nebo nějak podobně, MIN se snad všude jinde používá jako zkratka pro minimum.
Jestli se dá přepnout režim úkolování stepgenu jinak, tak to s velkou chutí udělám, protože to dojíždění os a překmitávání po ukončení pohybu mě docela irituje (i o tomhle už jsem tady psal). Proto jsem "vyladil" konstantu P=520, při které to ještě moc nepřekmitne a nedojíždí to extrémně dlouho.
Ještě jednou díky všem za cenné informace. Večer se dostanu ke stroji, tak budu experimentovat.
To naroubování PID na řízení stepgenu se mi od začátku zdálo podezřelé, nakonec už jsem to tady psal. PID se hodí pro řízení systému se setrvačností nebo dopravním zpožděním, ale ne pro eliminaci náhodných nepredikovatelných odchylek (tedy nepřesnosti v časování servo-threadu).
Jestli je MIN_FERROR skutečně FERROR pro pomalé pohyby, tak pak by to vysvětlovalo, proč zvýšením hodnoty se to spravilo. Ale pak by se to snad mělo jmenovat něco jako SLOW_FERROR nebo nějak podobně, MIN se snad všude jinde používá jako zkratka pro minimum.
Jestli se dá přepnout režim úkolování stepgenu jinak, tak to s velkou chutí udělám, protože to dojíždění os a překmitávání po ukončení pohybu mě docela irituje (i o tomhle už jsem tady psal). Proto jsem "vyladil" konstantu P=520, při které to ještě moc nepřekmitne a nedojíždí to extrémně dlouho.
Ještě jednou díky všem za cenné informace. Večer se dostanu ke stroji, tak budu experimentovat.
At to nemusíš dlouho studovat, nasel sem tu pro představu nejakou starou konfiguraci pro 5i25 predelanou na position mode.
jediny rozdil krome nazvu karty u tebe asi bude zamena joint za axis. predpokladam, ze jedes na necem novejsim.
Nebo si muzes zkompilovat starou verzi 2.5.x a pak ti to udela pncconf sam, ale zase neumi vesinu karet a zabere to dost casu.
#*******************
# AXIS X
#*******************
# Step Gen signals/setup
setp hm2_5i25.0.stepgen.01.dirsetup [AXIS_0]DIRSETUP
setp hm2_5i25.0.stepgen.01.dirhold [AXIS_0]DIRHOLD
setp hm2_5i25.0.stepgen.01.steplen [AXIS_0]STEPLEN
setp hm2_5i25.0.stepgen.01.stepspace [AXIS_0]STEPSPACE
setp hm2_5i25.0.stepgen.01.position-scale [AXIS_0]STEP_SCALE
setp hm2_5i25.0.stepgen.01.step_type 0
setp hm2_5i25.0.stepgen.01.control-type 0
setp hm2_5i25.0.stepgen.01.maxaccel [AXIS_0]STEPGEN_MAXACCEL
setp hm2_5i25.0.stepgen.01.maxvel [AXIS_0]STEPGEN_MAXVEL
# --- stepper signals---
net x-pos-cmd <= axis.0.motor-pos-cmd
net x-pos-cmd <= hm2_5i25.0.stepgen.01.position-cmd
net x-pos-fb <= hm2_5i25.0.stepgen.01.position-fb
net x-pos-fb => axis.0.motor-pos-fb
net x-enable <= axis.0.amp-enable-out
net x-enable => hm2_5i25.0.stepgen.01.enable
a všechny PIDky muzes zahodit.
M
jediny rozdil krome nazvu karty u tebe asi bude zamena joint za axis. predpokladam, ze jedes na necem novejsim.
Nebo si muzes zkompilovat starou verzi 2.5.x a pak ti to udela pncconf sam, ale zase neumi vesinu karet a zabere to dost casu.
#*******************
# AXIS X
#*******************
# Step Gen signals/setup
setp hm2_5i25.0.stepgen.01.dirsetup [AXIS_0]DIRSETUP
setp hm2_5i25.0.stepgen.01.dirhold [AXIS_0]DIRHOLD
setp hm2_5i25.0.stepgen.01.steplen [AXIS_0]STEPLEN
setp hm2_5i25.0.stepgen.01.stepspace [AXIS_0]STEPSPACE
setp hm2_5i25.0.stepgen.01.position-scale [AXIS_0]STEP_SCALE
setp hm2_5i25.0.stepgen.01.step_type 0
setp hm2_5i25.0.stepgen.01.control-type 0
setp hm2_5i25.0.stepgen.01.maxaccel [AXIS_0]STEPGEN_MAXACCEL
setp hm2_5i25.0.stepgen.01.maxvel [AXIS_0]STEPGEN_MAXVEL
# --- stepper signals---
net x-pos-cmd <= axis.0.motor-pos-cmd
net x-pos-cmd <= hm2_5i25.0.stepgen.01.position-cmd
net x-pos-fb <= hm2_5i25.0.stepgen.01.position-fb
net x-pos-fb => axis.0.motor-pos-fb
net x-enable <= axis.0.amp-enable-out
net x-enable => hm2_5i25.0.stepgen.01.enable
a všechny PIDky muzes zahodit.
M
Všude jinde to tak je.
Ale autoři Mesy použili PID (nebo něco jako PID) i pro úkolování stapgenů v Mesa kartách. Tady jen pro generování kroků, bez jakékoli vazby na nějaký připojený motor nebo něco podobného.
Záměrem bylo (předpokládám) vyrovnávání nepřesností časování servo-threadu.
-
robokop
- Site Admin
- Příspěvky: 22924
- Registrován: 10. 7. 2006, 12:12
- Bydliště: Praha
- Kontaktovat uživatele:
Taky nevim co je to tak najednou popadlo
Zacli to tim konfiguratorem vnucovat
Hloub jsem to nezkoumal
Povazoval jsem ze to ma najaky vyznamny duvod
Nevyhodou je ze je potreba ty pidky nastavit coz polohove generovani nepotrebovalo
Zacli to tim konfiguratorem vnucovat
Hloub jsem to nezkoumal
Povazoval jsem ze to ma najaky vyznamny duvod
Nevyhodou je ze je potreba ty pidky nastavit coz polohove generovani nepotrebovalo
Vsechna prava na chyby vyhrazena (E)
Není potřeba pokud budeš používat regulaci uvnitř StepGenů (která je naladěna velice dobře protože může fungovat na trochu jiném principu než standardní regulátory) .... a tedy provozovat StepGeny v polohovém módu.
Poněkud jiná situace by byla pokud by jsi chtěl zavést zpětnou vazbu z pravítek - tam už je naopak potřeba si PIDku naladit (polohový mód StepGenu na to už tak vhodný nejspíše nebude)
Vyrovnávat nepřesnosti časování servo-threadu není (konkrétně v tomto případě) potřeba.
On (LinuxCNC respektive HostMot2 driver) nepočítá s časem periody, ale s aktuálním reálným časem pro všechny výpočty.
Jinýmy slovy výpočet regulačních smyček nepředpokládá (nedosazuje do výpočtových vzorců), "granulovaný" čas s fixní délkou periody, ale čas skutečný (granulovaný čítačem procesoru HPET, který taky fachá docela svižně).
Stejně tak do výpočtů StepGenu MESA karty nebere polohu "graulovanou" na velikost jednotlivého "kroku" (která se reálně pohybuje od 0,1 mikronu až do řádu setin), ale se "sub-krokovou" polohou s přesností na nanometry. Samozřejmě né kvůli snaze polohovat s takovou přesností, ale
a) kvůli možnosti nastavit co "nejostřejší" regulační smyčku bez překmitů atd. (stejný důvod proč mají serva tak brutálně přesné enkodéry)
b) kvůli výpočtu probíhajícím skrze "fixed point" aritmetiku (tedy na straně FPGA MESA nepočítá s FloatingPoint čísly) - poloha je 48bit fixed point číslo (nevím teď z hlavy kolik z toho je za "desetinnou tečkou", ale je to hodně)
-
robokop
- Site Admin
- Příspěvky: 22924
- Registrován: 10. 7. 2006, 12:12
- Bydliště: Praha
- Kontaktovat uživatele:
jj presne to jsem psal
to jsme se nepochopili
jinak jak pises nekde jsem narazil na pocty bitu atd... a ta mesa to ma dost brutalne siroky
proste pro pripad kdyby to nekdo potreboval
mozna pocitali s tim ze jednou budou ridit 3D tiskarnu ktera bude tisknout jednotlive atomy
to jsme se nepochopili
jinak jak pises nekde jsem narazil na pocty bitu atd... a ta mesa to ma dost brutalne siroky
proste pro pripad kdyby to nekdo potreboval
mozna pocitali s tim ze jednou budou ridit 3D tiskarnu ktera bude tisknout jednotlive atomy
Vsechna prava na chyby vyhrazena (E)
A jseš si tím jistý?
Ty stepgeny přece musíš úkolovat vzhledem k periodě servo-threadu. Pokud potřebuješ jet nějakou rychlostí, tak tomu odpovídá nějaká konkrétní frekvence kroků STEP. Takže tomu stepgenu musíš nějak předat informaci o frekvenci, kterou má generovat.
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.
Sakra, mám v tom bordel.
