Mesa 7i90

Odpovědět
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

19. 7. 2018, 4:42

OompaLoompa píše: 19. 7. 2018, 3:22
Jakej je rozdil v množství posilanych dat v jednom ci druhem rezimu?
Napr. taký, že pre riadenie v polohovom režime sa cez zbernicu posiela 8-byte/axis, a v rýchlostnom stačí napr. len 4-byte/axis (hodnoty sú len názorné - ako to je v reále bude záležať len na implementácii od výrobcu). V prípade posielania dát pre viacero osí v jednom servo-cykle sa pri slimáčom tempe LPT môžeš veľmi "rýchlo" (pun intended) dostať k limitom priepustnosti.
Myslím, že to není pravda. Mesa funguje pořád stejně. Rozdíl je jen v tom, jakou metodou PC počítá náplň čítačů pro další servo-periodu. Takže vlastní karta zřejmě ani nebude vědět, že uživatel si nastavil jiný režim práce.
OompaLoompa píše: 19. 7. 2018, 3:22 Viem o čom hovorím, nedávno som riešil 8-axis pri 5kHz servo cykle po šifrovanej 50Mbit opto-linke (PCI/33MHz interface). Nakoniec sa tam naštaštie podarilo všetko vtesnať, ale rezervy tam na rozdávanie teda veľa neostalo..
Nevím, na jakém systému to děláš. Ale tyto parametry (5kHz servocyklus, 8 os) by se v případě Mesy daly zřejmě realizovat i na té nejpomalejší sběrnici, tj. na LPT (Mesa 7i90). Na mnohem rychlejší optice pak i s prstem v nose.
OompaLoompa píše: 19. 7. 2018, 3:22 Z toho, čo si popísal, je evidentné ...
Pěkně prosím nenavážej se do fupeho, jehož znalostí, schopností, zkušeností, ochoty poradit a problématiku zdokumentovat si mimořádně vážím.
Děkuji.
Uživatelský avatar
OompaLoompa
Příspěvky: 459
Registrován: 28. 6. 2017, 1:45
Bydliště: Západný Slovakistan

19. 7. 2018, 6:10

Mex píše: 19. 7. 2018, 4:42 Myslím, že to není pravda. Mesa funguje pořád stejně. Rozdíl je jen v tom, jakou metodou PC počítá náplň čítačů pro další servo-periodu. Takže vlastní karta zřejmě ani nebude vědět, že uživatel si nastavil jiný režim práce.
Ako som už vyššie písal - záleží na implementácii. A keďže si to práve ty, kto sa rozhodol sa tým zaoberať (úprava firmwéru a pod.), je len na tebe si to naštudovať a zistiť, čo konkrétne tam driver tej Mesy po tej zbernici posiela..

Ak to je vždy len DIR + hodnota frekvencie pre STEPGEN, a komunikácia je čisto jednosmerná (PC→Mesa) - teda prípad, kde je celé FPGA redukované len na najjednoduchšiu možnú formu generátora impulzov, tak potom máš samozrejme pravdu, a aj zmysel celej tej PID-ky je prinajmenšom veľmi otázny.
Mex píše: 19. 7. 2018, 4:42 Nevím, na jakém systému to děláš. Ale tyto parametry (5kHz servocyklus, 8 os) by se v případě Mesy daly zřejmě realizovat i na té nejpomalejší sběrnici, tj. na LPT (Mesa 7i90). Na mnohem rychlejší optice pak i s prstem v nose.
8 osí paralelne @ 5kHz cez LPT :roll: Pán bude komik :lol:

Konkrétne v tomto prípade to je Spartan-6 osadený v PCI/33MHz - čiže rovnaké FPGA, aké je použité aj vo veľa kartách od Mesy. No to nebolo hlavným limitujúcim faktorom. Tým bolo práve tých 50Mbit na tej optike (podľa teba "s prstem v nose"). Zjavne nemáš ani najmenšieho tušenia, čo všetko plnohodnotný, zabezpečený obojstranný prenos dát pre takmer dokonalé synchrónne riadenie a realtime feedback 8+ osí obnáša.. no jo :?

To ti ale samozrejme nezazlievam - nemôže byť každý vývojárom riadiacich jednotiek pre priemyselné systémy :)
Mex píše: 19. 7. 2018, 4:42 Pěkně prosím nenavážej se do fupeho, jehož znalostí, schopností, zkušeností, ochoty poradit a problématiku zdokumentovat si mimořádně vážím.
Děkuji.
Ja sa tu do nikoho nenavážam, len na rovinu sucho konštatujem fakty :o
Ak si to pochopil ako "navážanie sa", tak ma to samozrejme mrzí, no s tým už já nic nenadělám..

Ostáva len dúfať, že samotný fupe to pochopil trochu inak (a nie rovno ako navážanie sa - lebo tak to myslené určite nebolo) :?
 
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

19. 7. 2018, 7:55

... pánové ani se mi už nechtělo reagovat, ale nějako mi to nedalo, protože se to tu zase zvrhává v polemiky, které rozhodně neslouží ke správnému pochopení toho jak jsou StepGeny v MESA Firmware a HostMot2 driveru implementovány a jak to tam vlastně funguje.

Nakonec se mi zdá že MEX z pozice tazatele dané téma chápe lépe (i když s jistými rezervami) než Fupe a OompaLoompa dohromady. :shock:

Přičemž když se podívám na zkušenosti obou (Fupeho i OmpaLoompa) tak by tomu tak býti myslím nemělo :roll:

Problém je (tedy alespoň se domnívám že tomu tak je) že vedete obecnou polemiku za použití určitých tezí (které jsou většinou i správně), které však nejsou přímo aplikovatelné a jednoznačně určující jak by to mělo nebo němělo fungovat.

Jediným možným přínosným postupem je opravdu se podívat do těch zdrojáků (a to na obou stranách - tedy jak Firmware FPGA, tak HostMot2 "driveru" na straně PC). Jejich funkcionalita je natolik prorostlá, že jsou bez sebe nepoužitelné a nepochopitelné.
Dělba práce je (ani ne moc překvapivě) dle toho co které zařízení (né moc realtimeové PC versus dedikované FPGA) zvládá lépe.

FPGA se (bavím se teď konkrétně o případě StepGenů) stará opravdu čiste o "prosté čítače", které jsou:
- na jedné straně řízeny z driveru HostMot2, tedy posílány směrem z PC do FPGA
  • nastavení základích parametrů při inicializaci, jakou jsou:
    • Délka StepPulzu,
    • Délka Mezery mezi pulzy,
    • Délka pauzy po zmněně směru,
    • Vlastní mód výstupu (Step+Dir, StepLeft+StepRight, QuadratureStepping atd)
  • průběžná aktualizace rychlostního registru v rámci Servo-Threadu
- na druhé straně čtením stavových registrů, tedy směrem z FPGA do PC
  • čtení aktuální "pozice" StepGenu pro zpětnou vazbu regulátoru v rámci Servo-Threadu
Na jednu stranu to není mnoho, na druhou strau to je něco co procesor PC nikdy v takové kvalitě jako to FPGA nezvládne vzhledem k tomu že řeší zároveň "milion" všech možnách a nemožných úkolů.
V tom FPGA běží opravdu PARALELNĚ (souběžně) několik nezávislých hardwarových jednotek StepGenů :!: (které na sebe nijak nevidí, ale nijak se vzájemně v práci neruší / neovlivňují)

Mimojiné i GPIO porty jsou nastavovány a čteny v rámci Servo-Threadu.

FPGA a HostMot2 maji (v rámci nějakého enumeračního procesu, kdy se čte co je vlastně v kartě za Firmware a jaké komponenty obsahuje) zaregistrované určité množství registrů, které jsou "nastavovací" a které jsou "Datové" (bez ohledu na směr toku dat).
Nastavovací se přenáší pouze v době nastavování nějakých parametrů, nebo čtou v rámci nějakého enumeračního procesu.
Naopak "Datové" registry (bez ohledu na to jestli se zmněnily nebo ne) jsou KOMPLETNĚ přeneseny v rámci DMA přenosu v KAŽDÉM "ServoCyklu" tedy v rámci obsluhy Servo-Threadu.
Datový přenos PCI sběrnice je na to více než předimenzován, tak proč se trápits tím co přenášet, když se levou zadní zvládnou přenášet všechny data (bez ohledu na to jestli se změnily nebo ne)

To jestli běží StepGen v Rychlostním nebo Polohovém režimu FPGA skutečně nijak nepozná. Rozdíl je pouze v implementaci HostMot2 driveru, kdy v rychlostním režimu musím zajistit já správnou příkazovou rychlost abych byl tam kde mám být (a musím pro to využít nějaký regulační algoritmus tedy PID + FeedForward atd) nebo použiji Polohový režim, kde optimalizovaný regulační algoritmus psaný přímo na míru konkrétně matematicky jednoznačnĚ daného pohybu s omezením Rychlosti a Akcelerace zajistí vlastní HostMot2.

PID ZAČNE (z principu své funkce "automaticky" ZPOMALOVAT a polevovat když se blíží cíli)
  • Jak se zmenšuje odchylka klesá vliv Proporcionální složky.
  • tím že se nějakou rychlostí přibližuji k cíli, klesá vliv Derivační složky (čím rychleji se blížím tím je slabší její vliv)
  • nakonec je cíli skoro tak blízko že je jeho "korekční síla" zanedbatelná a "courá" se za požadovanou polohou. Integrační složka to sice poopraví pokud se pohybuju stále jedním směrem, ale při změně směru pak spíše chvilku škodí než se znovu "NaIntegruje" do požadované polarity aby dorovnávala "courání" - překmitává (pokud není např. algoritmus nějako uměle upraven aby nuloval integrační složku při přesném dosažení cíle).
Naopak regulační algoritmus psaný na míru polohovému režimu VALÍ NAPLNO teoretickou maximální rychlostí danou limity maximální akcelerace a maximální rychlosti DOKUD NENÍ opravdu PŘESNĚ V CÍLI.

pro úplnost nakonec dodávám že popisuju MESA kartu píchlou přímo na PCI sběrnici. Je možné že při LPT implementaci je něco trochu jinak, ale myslím (tedy prd vím), že by to mělo být na stejném principu pouze s jiným médiem (LPT místo PCI) přenostu těch samých dat. Vzhledem k tomu že se předpokládá nulová chybovost při přenosu skrže PCI, tak asi moc nehrotili dodělávat CRC a podobné srandy pro zajištění přenosu skrze LPT - asi předpokládají že je na HW úrovni zajištěn kvalitní přenost (dokonalé sťínění proti vnějšímu rušení / omezená délka LPT kabelu / dostatečné odstínění respektive dostatečné vzdálenosti a uspořdání jednotlivých žil uvnitř LPT kabelu, impedanční přizpůsobení veení pro potlačení odrazů atd)
r4cv
Příspěvky: 2681
Registrován: 8. 12. 2009, 8:32
Bydliště: Topoľčany

19. 7. 2018, 8:11

Mimojiné i GPIO porty jsou nastavovány a čteny v rámci Servo-Threadu.
s tým mám zaujímavú skúsenosť. Mám 5i25+7i76. tlačidlo pauza mám vyvedené na panel a pripojené na vstup 7i76.
Ak beží jednoduchý program, tak všetko funguje ako má, ale ak dám nejaký "adaptive cleaning" s 10.000-mi riadkov, tak čítanie vstupov trochu pokulháva. stáva sa mi, že pauza nefunguje a niekedy aj na stopku funguje oneskorene.

z panelu a klávesnice to ide bez problémov, takže to tipujem na problém - oneskorenie s čítaním vstupov.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

19. 7. 2018, 8:14

neco takoveho jsem predpokladal
nicmene potom my vyvstava otazka
paklize hm2 driver v polohovem rezimu vpodstate pripravi rychlosti ktere pozaduje od mesy a mesa jako takova je pouze programovatelny generator kmitoctu a citac vydanych kroku
jak se tenhle rezim vyrovnava s jitterem servo threadu
predpokladam ze tam i prez tohle vsechno je neco co bude algoritmem vpodstate pid regulator ktery pak tyhle drobne odchylky poresi
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

19. 7. 2018, 8:15

r4cv píše: 19. 7. 2018, 8:11
Mimojiné i GPIO porty jsou nastavovány a čteny v rámci Servo-Threadu.
s tým mám zaujímavú skúsenosť. Mám 5i25+7i76. tlačidlo pauza mám vyvedené na panel a pripojené na vstup 7i76.
Ak beží jednoduchý program, tak všetko funguje ako má, ale ak dám nejaký "adaptive cleaning" s 10.000-mi riadkov, tak čítanie vstupov trochu pokulháva. stáva sa mi, že pauza nefunguje a niekedy aj na stopku funguje oneskorene.

z panelu a klávesnice to ide bez problémov, takže to tipujem na problém - oneskorenie s čítaním vstupov.
tady za to nebudou moct gpio ale to ze ten vstup posilas do gui ktere jako takove nepracuje v realtime ale ma podstatne nizsi priority a nez to prez nej projde zpet k planovaci ktery realtime je muze to trvat
Vsechna prava na chyby vyhrazena (E)
r4cv
Příspěvky: 2681
Registrován: 8. 12. 2009, 8:32
Bydliště: Topoľčany

19. 7. 2018, 8:20

robokop píše: 19. 7. 2018, 8:15 tady za to nebudou moct gpio ale to ze ten vstup posilas do gui ktere jako takove nepracuje v realtime ale ma podstatne nizsi priority a nez to prez nej projde zpet k planovaci ktery realtime je muze to trvat
myslím, že je to pripojené na halui.program....
príkazy z gui práve idú bez oneskorenia
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

19. 7. 2018, 8:32

nevim presne s cim halui komunikuje tady bych kecal
ale dokazu si to vysvetlit jedine tak jak jsem popsal
jinak ty gpio jsou dost rychle na vetsinu veci
da se na to povesit rucni kolecko a softwarovy inkrementalni citac a podobne relativne uz rychle deje
a to to jsou vpodstate nejpomalejsi vstupy
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

19. 7. 2018, 8:47

robokop píše: 19. 7. 2018, 8:14 nicmene potom my vyvstava otazka
paklize hm2 driver v polohovem rezimu vpodstate pripravi rychlosti ktere pozaduje od mesy a mesa jako takova je pouze programovatelny generator kmitoctu a citac vydanych kroku
jak se tenhle rezim vyrovnava s jitterem servo threadu
predpokladam ze tam i prez tohle vsechno je neco co bude algoritmem vpodstate pid regulator ktery pak tyhle drobne odchylky poresi
Určitě.
Mesa na začátku cyklu přečte aktuální stavy, pak PC spočte kam má dojet na konci servoperiody a nasype ty nové obsahy čítačů do Mesy. Psal to i teď CZ_Pascal, někde na začátku tohoto threadu jsem tady dával obrázky té komunikace i s nějakým komentářem, tam bylo pěkně vidět co je čtení a co jsou zápisy. Mimo jiné tam bylo vidět i ta čtení a zápisy GPIO (o čem tady teď psal r4cv).

Takže nové obsahy čítačů vždy řeší PC, a jde jen o to, jaký algoritmus pro dosažení plynulosti, ale zase také rychlosti a pokud možná ne-překmitů, zvolí.
Podle mě je tohle dobře vyřešené u SW stepgenů, které samozřejmě musí řešit stejnou problematiku. Tak doufám, že to autoři Mesy v tom "polohovém" režimu pokud možno co nejlíp opsali.

Znovu říkám, že by to chtělo to "kurvítko latence", tj. zátěžové testovací prostředí. Tam by se pak ukázalo, který algoritmus je jak dobrý.
Čím dál tím víc vidím, že to bude stát zato zkusit to napsat.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

19. 7. 2018, 9:14

OompaLoompa píše: 19. 7. 2018, 6:10 8 osí paralelne @ 5kHz cez LPT :roll: Pán bude komik :lol:
Abych jen tak planě nekecal, tak jsem to zkusil (8os, servo-thread 5 kHz).
Je to teda fest na hraně, ale ještě to jede. To PC není žádný rychlík, je to starý Intel Atom.
Je tam vidět, že komunikace po tom pomalém LPT už zabírá opravdu hodně času.
Nahoře je jeden ze signálů STEP, dole je komunikace po LPT.
Jsou tam stepgeny pro 8os, 4 enkodéry, jedno vřeteno a nějaké I/O linky.
Pokus_8os_5kHz.jpg
OompaLoompa píše: 19. 7. 2018, 6:10To ti ale samozrejme nezazlievam - nemôže byť každý vývojárom riadiacich jednotiek pre priemyselné systémy :)
Jojo, dostal jsi mě.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

19. 7. 2018, 9:19

... když bych vzal docela hooodně špatnej jitter kolem 50000ns a byl tak drzej že budu na takovým PC provozovat stroj se zrychlením 1g tak se dostávám na chyby v polohování (vlivem zpožděné úpravy rychlost StepGenu) kolem 1um. To není myslím zase tak špatnej výsledek. :roll:

Tato chyba je pak samozřejmě docela rychle kompenzována v dalších pár ServoCyklech.

Myslím, že podobnou chybu už při těchto fofrech bude způsobovat i schopnost reakce servopohonu.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

19. 7. 2018, 9:22

v tom pripade kacirska myslenka
jakyje rozdil mezi resenim se stepgenem v polohovem modu a v rychlostim prez pidku s pouzitim feed forwardu?
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

19. 7. 2018, 9:33

robokop píše: 19. 7. 2018, 9:22 v tom pripade kacirska myslenka
jakyje rozdil mezi resenim se stepgenem v polohovem modu a v rychlostim prez pidku s pouzitim feed forwardu?
Myslím, že zrovna nějak tak podobně to mají udělané. Do zdrojáků jsem teda ale ještě nekoukal (to je ostuda).
Je tam nastavený FF1=1.0, a když se do toho drbne, tak se to celé podělá.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

19. 7. 2018, 9:47

robokop píše: 19. 7. 2018, 9:22 v tom pripade kacirska myslenka
jakyje rozdil mezi resenim se stepgenem v polohovem modu a v rychlostim prez pidku s pouzitim feed forwardu?
No to přece právě vidíš, když použiješ ten "nový" způsob řízení který je generovaný konfigurátorem.

Je to pužitelné. Největší část "signálu" toho tvoří FF1 (tedy do rychosti StepGenu posíláš rychlost jakou se pohybuje Trajectory Planner a zbytek dorovnává PIDka).

Ale všichni jsme se tu myslím shodli, že vnitřní algoritmus StepGenu (ať už toho SW nebo toho co je v HostMot2 - oni jsou myslím téměř shodné) to zvládá lépe, což je v souladu s tím co jsem psal o nějakej ten příspěvek výše. Ten algoritmus je prostě chytřejší než nějaká obyčejná univerzální PID s FeedForwardem.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

19. 7. 2018, 9:56

no prave by me zajimalo v cem je podstata toho ze je chytrejsi
z nejakeho duvodu tam tu pidku cpou prednostne tak mi to vrta v hlave
Vsechna prava na chyby vyhrazena (E)
Odpovědět

Zpět na „Ostatní elektronika“