ASDA-A2 Ethercat v pozičním řízení (CSP)

Odpovědět
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

23. 4. 2021, 10:00

Zdravím ve spolek.
Dlouho sem nepřispěl svou troškou do mlýna tak tak činím.
Poslední rok ladíme s jirkou (nick Jirkam) jeho novou mašinu s kterou jsou stále nějaké potíže.
Používá Delta drivery ASDA-A2
Nejdřive jsme se snažili rozběhat drivery v rychlostním rezimu pomoci klasické PIDky. To už je v linuxcnc-ethercat připravené a v podstatě stačí okopírovat xml soubor z examplu a vše běží.
Běží ale ne tak jak jsme si představovali. Na ose Y jsou dvě serva (gantry) a ty se neustále hádaly mezi sebou. Přisuzuju to tomu, že se vzájemně přetahovali.
Bylo to vidět v halscopy kde když jeden motor přidal, druhý ubral a naopak. To vedlo k tomu, že se portál klepal při pohybu.
Bohužel ani technici od Delty nebyli schopni poradit jak naladit dva drivery na jedné ose. Autotuning umí naladit pouze jednu osu.
Abych to zkrátil, rozhodli jsme se že přepíšu zdrojáky tak aby se dal použít poziční systém řízení, který by nemel být tak náchylný na klepaní.
V odporné terminologii se to jmenuje Cyclic Synchronous Position Mode a nejde o nic jiného, než že se mu místo rychlosti posílá pozice.
Cesta to byla dlouhá, ale výsledek se dostavil.
A protože by to možná někdo z vás mohl využít tak to tu zveřejním.
dopsal jsem několik souboru do linuxcnc-ethercat které je potřeba nahrát do struktury souboru a potom to celé zkompilovat.

postup:
do souboru lcec_main.c
doplnit někam za řádek
#include "lcec_deasda.h"

#include "lcec_deasda_pos.h"

do adresáře linuxcnc-ethercat/src
nahrát soubory
lcec_deasda_pos.h
lcec_deasda_pos.c

a teď už to jenom zkompilovat.

samozřejmě je potřeba upravit xml soubor tak aby používal místo rychlosti pozici
<masters>
<master idx="0" appTimePeriod="1000000" refClockSyncCycles="1000">
>
<slave idx="0" type="DeASDA_pos" name="X">
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="-25000"/>
</slave>

Tím ale celá legrace nekončíla.
Mašina běhala pěkně hladce, nic se neklepalo, ale chyba při pohybu byla obrovská. Klidně několik mm. A to obzvláště při vyšších rychlostech.
Pokusil jsem se to cele ošetřit tak, že jsem výslednou pozici poupravil o požadovanou rychlost přenásobenou koeficientem. Výsledek lepší, ale furt nic moc. Tak jsem přidal druhý parametr a sice akceleraci. Opět k výsledné pozici přidat akcceleraci krát koeficient i předchozi rychlost krát koeficient.
To už vypadalo dobře, ale celý to muselo běhat na dané odladěné rychlosti. jakmile se změnila rychlost popřípadě akcelerace, opět se to rozsypalo a jezdilo blbě. Jen pro upřesnění... všechny dodělávky byly učiněny v halu pomoci násobičů a přičítaní offsetu atd.
Takže jsme došli k závěru, že tudy cesta taky nevede.
Po hlubším prostudování všech manuálu a nějakého čínského fóra v rozsypaném čaji pomoci googlu translatoru jsem došel k názoru, že tyto úpravy si musí dělat sám driver a ne linuxcnc. To znamená přidat do ethercat telegramu informaci o rychlosti a akceleraci.
To se po pár pokusech povedlo a pak už stačilo tyto informace opět poupravit koeficientem. jeho získani popisu později.
Když se v manuálu pro asda-a2 podiváte na schéma řídící smyčky, tak je vidět že v pozičním režimu, je možnost poupravit výslednou hodnotu pozice rychlosti a momentem.
CSP.jpg
Takže něco jako feed forward nula a jedna. Ktery ma obrovsky vliv na vysledek.
A opravdu, driver si tyto dvě hodnoty řídí po svém a systém se chová o poznání lepe než když to řídí celé linuxcnc.
Ted k tomu co všechno je potřeba do driveru posílat.
požadovanou pozici
požadovanou rychlost
požadovane zrychleni.
plus samozřejmy nějaké ty koeficienty.
net x-pos-cmd joint.0.motor-pos-cmd => lcec.0.X.srv-pos-cmd
net x-vel-cmd joint.0.vel-cmd => lcec.0.X.srv-vel-cmd
net x-acc-cmd joint.0.acc-cmd => lcec.0.X.srv-acc-cmd


vsechny tychle informace posila trajectory planner pomoci joint kromě acc, které naskočí až po tom co je mašina nahoumovaná. nevím proč ale je to tak a podle zdrojáku je to správne. Možná to souvisí nějak s kinematikou, která může být různa podle polohy nahoumovaní. ale jistej si nejsem a nechtělo se mi jít ve zdrojakach tak do hloubky. Informace, že je potřeba nahoumovat mi stačila.
dal je potřeba posílat, spíš poslat jednou.
koeficient pro rychlost
koeficient pro akceleraci.

setp lcec.0.X.srv-vel-cmd-scale 3.33
setp lcec.0.X.srv-acc-cmd-scale 0.325

Tady malá odbočka. Ve zdrojácích sem to blbě napsal jako pin misto parametru, ale ve finále je to buřt, oba se nastavujou stejne, jenom při hledání ve výpisu halshow je to v jiné kolonce. Už se mi pak do toho nechtělo hrabat.

Jako dalši krok je potřeba tyto koeficienty nastavit.
to jsem dělal tak, ze jsem si pustil halscop a díval se na požadovanou a skutečnou polohu. Rozdíl těchto hodnot je jistě všem kdo ladili PID známý ferror.
na něm je krásně vidět jak chyba bez koeficientu roste s rychlosti.
takž e jsem si pustil sim_pin
loadusr sim_pin lcec.0.X.srv-vel-cmd-scale lcec.0.X.srv-acc-cmd-scale
a měnil za chodu stroje koeficient pro rychlost tak, až při konstatní rychlosti byla výsledna chyba nula (něco málo tam samozřejme lítá ale bavíme se o tisicinách mm)
tim se nastaví prvni koeficient pro rychlost.
Dal je z grafu osciloscopu vidět, ze při konstatni rychlosti je chyba sice nula, ale při akceleraci stále lítá.
To se poupraví druhým koeficientem pro zrychleni.
opět sim_pin a opět zkouseni parametru. z grafu je vidět, jestli se chyba zvětšuje nebo zmenšuje, takže postupnýma iteracema najdeme výslednou hodnotu.
kdyz sem nasel oba potřebné parametry, tak sem je natvrdo napsal do hal souboru.
setp .....
A tim je celej system naladenej. Samozrejme pro jednu osu. ostatni jsou analogické.
Ted stroj jezdi s chybou někde okolo 2 tisícin nezávisle na rychlosti a akceleraci protože driver si to řídí sám a výslednou pozici poupravuje na základě námi předhozených hodnot a svého vnitřniho nastaveni.
Prikladam pro jistotu i param soubor pro driver s kterym sem si taky dost hral a má na cele nastaveni vliv.
A, tak nepřikládám. někde sem ho zabordelil, ale poprosím Jirku jestli ho sem přihodí.
Změn sem dělal opravdu hodně a nedokážu je všechny popsat. Bohužel dokumentace ke všem parametrum není uplne vševysvětlující. a jejich vzájemné ovlivňování je velké.

Ted se musím přiznat, že je to celé trošku ošizené. Dokumentace sice tvrdí, že změnou parametru 0x60B1 a 0x60B2 můžeme ovlivnit rychlost a kroutici moment (ff0 a ff1), ale za žádnýho boha se mi nepodařilo cokoliv ovlivnit pomocí momentu 0x60B2. takže jsem to trošku očural a ikdyž tento parametr se nastavuje tak pouze jako ovlivněnní rychlosti kterou posílame. Kdyby to někdo dokázal rozluštit budu rád. Na všech možných diskuzich jsem našel jen zmínku že tenhle parametr existuje a lze ho použít, ale nikdo tak zatím neučinil.

A je tu ještě jedna maličkost.
Pozici si driver přepočítá na základě scale ktery je v ini. Pro rychlost a zrychleni tam tahle funkce není (uplne sem ji nedodělal), takže se pro osu s dvěma drivery musi nastavit parametr pro rychlost a akceleraci zvlášt a to se stejnou hodnotou ale opačnym znaménkem. Samozrejme jen v případě, že je scale v ini pro jednu osu a dva motory nastavení také s opacným znamenkem.
Vychozi hodnoty od kterych se muzete pri ladeni oprit jsou o pár řádek výš. A samozřejme záleží na tom, kde se provadí potřebný scale pro usy. Jestli na driveru, nebo v linuxcnc. možností je několik.

tak snad sem na nic nezapomněl. Návod to není uplně jednoduchý, ale předpokládám, že se do něj budou pouštět jen ti co vědí co dělají a ne jen kopirujou řádky do terminalu. Možná je tenhle návod úplně zbytečnej a jenom neumim naladit mašinu v rychlostním režimu. Když tak se ptejte na co chcete a já na na co budu chtít odpovím.

A na závěr ještě jedna informace.
Všechno to běhá krásně, nic se neklepe. rychlost i akcelerace parádní. Ale....
Ale občas dochází k tomu, že najednou začne servo pískat. Po chvíli se uklidní. Někdy to uděla jednou za den jindy časteji.
Na mezinarnim foru jsme našli informaci o tom, že to může způsobovat chyba synchronizace DC hodin. A pozični system je na to obzvlášte citlivý. už na to vyšel patch a návod jak to ošetřit.
Jmenuje se to PLL patch
V LCNC master už je celý patch aplikovaný a není potřeba nic kompilovat. pro starší systémy najdete v adresářové strukůře linuxcncn-ethercat adresář, kde jsou pro ruzne verze přiloženy dané patche. je potřeba aplikovat patch a pak překompilovat LCNC.
Co tenhle patch vlastně dělá?
Ve standartní režimu řídí DC hodiny systém a zařízení se podle toho synchronizují, ale když se nám tyhle hodiny občas vlivem nejakýho zpoždění rozhodí, tak to dělá neplechu. U velocity režimu to moc vliv nemá, ale u pozičního bohužel ano. Pomocí pll patche ale můžeme říct celemu soustrojí, že hodiny nebude řídit master, ale třeba první slave, kde nehrozí že dojde ke špatnému časováni.
A pro tohle celé stačí v xml souboru pro mastera změnit refClockSyncCycles na -1.
Pokud pll patch neni aplikovany a pokusíte se nastavit -1, tak vam to vynada, že to takhle nastavit nejde. myslim, že je to vidět v dmes. Takže zkouška je velmi jednoduchá.
A když neoedituje xml v jiném adresáři jako se povedlo Jirkovi tak se hned dozvíte jak to dopadlo. :-)

Jirka to má nastavený cca týden a zatím neříkal, že by to zase začalo pískat. tak doufám, že to bylo tím.
Zajímavý je, že jsem zkoušel tento patch na svem jednojádrovém stařičkem PC, který ale má krasnou latency nekde kolem 5000 a tam to proste nefunguje. jakmile zapnu PLL patch, tak servo začne při pohybu vrčet a vůbec to nezní pěkně.

Ještě mám v záloze jednu úpravu a sice isolování jednoho jádra. Jak jsem se dočetl, tak to občas taky dělá neplechu. V podstatě jde o to, že vícejádrový systém během běhu programů různě přepíná a přiřazuje výkon podle potřeby. Tohle všechno samožřejmě v normální případě krásně funguje a zvyšuje výkon celý mašiny, ale existují aplikace jako je zrovna LCNC (možná spiš RTAI PREEMPT atd) kterej prostě nedokáže využit více jader a pokud ano, pak dochází k přehazování z jadra na jádro a to celé žere nejakou režii a může to paradoxně brzdit a dělat neplechu. obzláště pak pro přesné časování.
Koho to zajimá, tak stačí najít isolcpus. je toho na forech dost k dohledání.
v podtsatě stačí jeden řádek do grubu.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=2,3"

tim se odizolují jádra 3 a 4 protože jsou číslovaný od nuly.
kolik jader ma system je videt třeba z lscpu

A tady je celý adresář s pozičním řízením. Je tam přidáno i pár nových zařízení, který tam nebyly ale Jirka je používá, ale už nevím který.
linuxcnc-ethercat-pos.rar
(672.96 KiB) Staženo 97 x
Ethercatu zdar.
Martin
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

23. 4. 2021, 12:21

mazec
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
zz912
Příspěvky: 1348
Registrován: 25. 5. 2008, 7:16

24. 4. 2021, 8:10

Palec nahoru.
LinuxCNC - MESA 7i96
zz912.webnode.cz
Uživatelský avatar
OompaLoompa
Příspěvky: 459
Registrován: 28. 6. 2017, 1:45
Bydliště: Západný Slovakistan

24. 4. 2021, 11:43

Zaujimavé, že len donedávna to roky celé bežalo na softvérovo generovanom DC mastrovi, a nikomu to akože moc neprekážalo :?

Prečo je ale na dosiahnutie uspokojivých prevádzkových parametrov potrebné suplovať časť práce serva cez riadiaci systém? :roll:
Každý poriadny servo firmvér si veci ako rýchlosť/akceleráciu derivuje v reálnom čase z pozičných dát, a nepotrebuje tým byť dodatočne dokrmovaný cez zbernicu. Ak by sa jednalo o overdrive na základe predanalýzi z plánovača, tak v tom prípade ok, lebo tieto dáta si firmvér z prsta sám nevycucia, ale v tomto prípade mi to tak nepripadá? :|

Ergo, keď potrebujem minimalizovať follow-error, riešim to výlučne cez firmvér, a nie pomalou slučkou cez RS, ktorá mi do celého procesu primieša len ďalšie neduhy a neželané rezonancie.

PS: Ako sa to správa pri záťaži? :wink:
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

24. 4. 2021, 2:27

Pěkné, žes to rozjel a funguje dobře. Blahopřeji.

K tomu DC (Distributed Clock): skoro mám pocit, že master DC vůbec řídit nemůže. V EtherCAT definici je, že to musí dělat nějaké připojené zařízení. Defaultně první na sběrnici, které je toho schopno. Ale master to může přidělit i nějakému jinému.
Takže pokud to neřídí nějaké to pověřené zařízení, tak ho prostě neřídí nikdo. DC není povinné, a často ani není nezbytné.

Mám pocit, že v originální verzi IgH mastera (přímo od IgH) byla zrovna v obsluze DC nějaká chyba. Aspoň mně se to chovalo podivně, a s většinou zařízení mi to nefungovalo.
V těch opatchovaných verzích, které jsou různě po internetu a které už dělala komunita nezávisle na IgH, tam je to už myslím trochu pospravované. Aspoň v některých.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

24. 4. 2021, 3:15

OompaLoompa:

mas pravdu spravne by to mel delat driver
ale z nejakeho dufodu se fupemu nepovedlo ho k tomu premluvit
tak holt takhle
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
zz912
Příspěvky: 1348
Registrován: 25. 5. 2008, 7:16

24. 4. 2021, 3:21

Zvažoval jsi i variantu jiného výrobce driverů jako řešení problému?
LinuxCNC - MESA 7i96
zz912.webnode.cz
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

25. 4. 2021, 9:42

OompaLoompa píše: 24. 4. 2021, 11:43 Zaujimavé, že len donedávna to roky celé bežalo na softvérovo generovanom DC mastrovi, a nikomu to akože moc neprekážalo :?

Prečo je ale na dosiahnutie uspokojivých prevádzkových parametrov potrebné suplovať časť práce serva cez riadiaci systém? :roll:
Každý poriadny servo firmvér si veci ako rýchlosť/akceleráciu derivuje v reálnom čase z pozičných dát, a nepotrebuje tým byť dodatočne dokrmovaný cez zbernicu. Ak by sa jednalo o overdrive na základe predanalýzi z plánovača, tak v tom prípade ok, lebo tieto dáta si firmvér z prsta sám nevycucia, ale v tomto prípade mi to tak nepripadá? :|

Ergo, keď potrebujem minimalizovať follow-error, riešim to výlučne cez firmvér, a nie pomalou slučkou cez RS, ktorá mi do celého procesu primieša len ďalšie neduhy a neželané rezonancie.

PS: Ako sa to správa pri záťaži? :wink:
Otázka dobrá, odpověd nemám.
Na začátku procesu, jsem si to myslel taky. Předělám to na pozični systém a mam hotovo. Ale chyba lavky. Opět zdůrazňujo, že to může být hlubší neznalostí driveru jako takového. Hrál sem si s kdejakým parametrem o kterém sem si myslel, že by mohl mít vliv. Ale chyby sem se nedokázal zbavit. Tak sem to obešel způsobem kterým sem to obešel.
On se v praxi moc poziční systém řízení nepoužívá, většinou je to rychlostní. Momentovej sem snad v praxi ani neviděl.
A jak se to chová při zátěži? Myslíš při obrábění? To bude muset odpovědět Jirka. Já tu mašinu znám jenom z obrázku a podle zvuku z telefonu. Nikdy sem u ni nestál. Ale to mi nebránilo si s ní hrat.
M
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

25. 4. 2021, 9:46

Mex píše: 24. 4. 2021, 2:27
K tomu DC (Distributed Clock): skoro mám pocit, že master DC vůbec řídit nemůže. V EtherCAT definici je, že to musí dělat nějaké připojené zařízení. Defaultně první na sběrnici, které je toho schopno. Ale master to může přidělit i nějakému jinému.
Má pravdu předsedo....
To sem napsal pěknou kravinu. Aspoň je vidět že to četl někdo kdo o tom něco ví.
PLL patch nepředává hodiny z mastera na slavě, ale poupravuje hodnoty pro planování cyklu dané úlohy. Nevim jak jinak přesně to popsat.
Ono toho zas tak moc k dočtení nikde neni. A že bych to pochopil ze zdrojáku to fakt asi nedám.
M
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

25. 4. 2021, 9:52

zz912 píše: 24. 4. 2021, 3:21 Zvažoval jsi i variantu jiného výrobce driverů jako řešení problému?
Popravdě ani moc né. Ono když do toho člověk nasype nějaky desítky tisíc, tak se nejdřív snažím to udělat s tím co mám. Sice to nebyly moje prachy, ale stejně. Možná by se jiný drivery chovaly líp, neumím posoudit. tolik toho za sebou zase nemam, abych mohl porovnávat od stolu. Třeba je tu někdo kdo poradí.
Nemyslim si že by ty ASDA-A2 byly špatný. Umí toho na můj vkus až moc. Jenom seznam parametrů má několik stránek. škoda jen s jejich dokumentací.
U většiny parametrů je jakštakš popis, ale u jiných skoro nic. Možná název, min max, ale na co všechno má vliv se člověk nedoví.
M
jirkam
Příspěvky: 217
Registrován: 15. 6. 2007, 10:25
Bydliště: Pardubice

2. 5. 2021, 8:34

Ahoj všem.
Přikládám .par s nastavením driveru od fupeho.

Pří zátěži jsem nezaznamenal nějaké problémy.

Jinak klobouk dolů před fupem.
A hlavně díky za Tvou trpělivost.

Jirka
Přílohy
fupe.zip
(4.65 KiB) Staženo 91 x
Odpovědět

Zpět na „LinuxCNC - drive pod nazvem EMC2“