Mesa 5i25 a 7i76

[yaqwsx]

Nevíte jaké čipy používá Mesa na svých kartách pro posílení vstupů/výstupů, zpětivoltování a ochranu FPGA?

[K_73]

https://www.pericom.com/assets/Datasheets/PI5C16211.pdf" onclick="window.open(this.href);return false;

"5V I/O TOLERANCE
The FPGA used on the 5I25 has a 4V absolute maximum input voltage
specification. To allow interfacing with 5V inputs, the 5I25 has bus switches on all I/O pins.
The bus switches work by turning off when the input voltage exceeds a preset threshold.
The 5V I/O tolerance option is the default and should normally be left enabled.
For high speed applications where only 3.3V maximum signals are present and
overshoot clamping is desired, the 5V I/O tolerance option can be disabled. W3 controls
the 5V I/O tolerance option. When W3 is on the default UP position, 5V tolerance mode
is enabled. When W3 is in the DOWN position, 5V tolerance mode is disabled. Note that
W3 controls 5V tolerance on both P2 and P3 I/O connectors.
W3 also selects the pull-up resistor voltage, When 5V I/O tolerance mode is
selected, the I/O pull-up resistors are powered from 5V. When 5V I/O tolerance mode is
disabled, the I/O pull-up resistors are powered with 3.3V."

[CZ_Pascal]

Měl jsem chvilku, tak jsem se konečně pořádně podíval na EPP režim LPT. Je to docela chytře vymyšlené, funguje tam handshake na HW úrovni, takže proti propustnosti LPT běžným provozem SPP to má nesrovnatelně vyšší výkon.

Taky jsem se díval, jak na nejnižší úrovni komunikuje LinuxCNC s Mesou přes LPT port.
Až někdy budy mít trochu delší volnou chvíli, tak napíšu "přijímač" toho provozu po EPP pro laciný procesor ARM a zkusím na normálním Linuxu (bez RT jádra), jak rychle to bude schopno přenášet data, aby bylo jasné, kolik se toho dá protlačit v servo-cyklu, tj. za 1ms.

Pokud to vyjde tak, že se bude dát protlačit podobný objem dat, jaký se tam u běžné Mesa karty hrne (tady mám zatím bohužel ještě mezeru ve vzdělání, nevím, kolik tam toho chodí), tak by to rozhodně stálo za realizaci. Pak by to byla důstojná varianta k Mese, a to za směšné peníze.

To by bylo jistě fajn a věřím že přenesené množství dat není nikterak závratné. Co je ale trochu hůře realizovatelné na tom ARMovi budou čitače.

MESA používá 48 bitový čitač pro každý StepGen. Nejvýznamnějších 16 bitů tvoří polohu vyjádřenou v počtu kroků. Spodních 32 bitů tvoří dělení jednotlivého každého kroku.(tedy FixedPoint čislo 16.32)
Dá se tedy bez nadsázky říct že přesnost polohy tohoto čitače je subatomární
Pro přenos polohy mezi LinuxCNC a MESOU se ale přenáší pouze nejvýznamnějších 32 bitů (fixexd point číslo 16.16). Oněch nejspodnějších 16 bitů je tam potřeba pro dostatečnou přesnot při pomalém pohybu jelikož každý z těch 48bitových čítačů je inkrementován/dekrementován 50MHz. (tedy 50 milion-krát za sekundu)

Požadovaná rychlost je přenášená jako 32bit číslo (ona desetinná část 48-bitového pozičního čitače 16.32)

Shrnuto podtřženo pro jeden StepGen musím v ServoSmyčce přenést oběma směry jedno 32-bit číslo.

Bez nějaké hlubší znalosti jak probíhá výpočet trajektorjie a veškeré kompenzace atd ti stačí vědět že tvá HAL komponenta (používající pro EPP pro komunikaci s ARMem) má na vstupu požadovanou pozici (FloatingPoint číslo) pro každou osu a jejím výstupem zpět pro LinuxCNC je skutečná pozice (FloatingPoint číslo) pro každou osu.
Jak zajistíš aby tvá komponenta sledovala s dostatečnou přesností Vstupní pozice je čistě na tobě, stejně tak jakým způspbem zaručí aby se tak dělo i na straně připojeného HW.
Zpravidla to ale znamená něco na způsob diskrétního PID regulátoru s nějakým tím "FeedForwardem" abys to ureguloval pouze z těch vstupních informací o poloze v daném čase s tím že musíš počítat o jednu periodu dopředu. Jinými slovy počítáš jaká data musíš teď zadat abys příští periodu měl co nejmenší chybu.

[Mex]

Shrnuto podtřženo pro jeden StepGen musím v ServoSmyčce přenést oběma směry jedno 32-bit číslo.

Diky za informace.
Trochu mi uniká nutnost zadávat přesnost s takovým rozlišením, a realizovat ji v 48-bitové granulitě. Moc mi to nekoresponduje s tím, že jako jedna z dalších možností je použití analog +-10V, což v praxi odpovídá rozlišení řekněme na 12 bitů. Takže je zvláštní, že v případě digitálního řízení by byla zapotřebí několik-miliard-krát vyšší rozlišovačka.

Píšeš, že HAL má na vstupu i výstupu pozici. Pokud jsem pochopil správně předchozí příspěvky, tak Mesa ale dostává rychlostní informaci, nikoli poziční.
Takže pokud bych chtěl použít stávající HAL, určený pro Mesu, a jen na něho místo FPGA pověsil desku s ARMem, tak bych dostával rychlostní informaci. Kdežto pokud by se napsala nová HAL komponenta, tak by se dala používat poziční informace, který by se (podle mě) asi zpracovávala lépe. A byla by asi vhodnější i v případě přechodu třeba ně nějaké digitální servo (EtherCAT nebo podobné), které by se dalo řídít pozičně.

[Mex]

Nevíte jaké čipy používá Mesa na svých kartách pro posílení vstupů/výstupů, zpětivoltování a ochranu FPGA?

Nevím, co tam používá Mesa. Ale pro převod 3.3V <-> 5V se dají použít běžné obvody 74AHC (z 5V na 3.3V) a 74HCT/AHCT (z 3.3V na 5V).
Pro případné vstupy o vyšším napětí pak ještě předřadit odporový dělič a ochrannou zenerku nebo transil.

[robokop]

tak ono to bylo vzdy pouzite jako kanon na vrabce proto to ma tolik bitu proste aby tam byla obrovska vykonova rezerva a nikdy nic neschazelo
proto se mi to reseni vzdy libilo

ona ta mesa neni jen hradlove pole
to pole je a neni podle typu karty a pouzitem poli oddelene
za nim je ta dalsi karta a za ni jsou pak ty periferie cnc
a o te druhe karte je to snad jeste vic jak o te s tim hradlovym polem

[CZ_Pascal]

Diky za informace.
Trochu mi uniká nutnost zadávat přesnost s takovým rozlišením, a realizovat ji v 48-bitové granulitě. Moc mi to nekoresponduje s tím, že jako jedna z dalších možností je použití analog +-10V, což v praxi odpovídá rozlišení řekněme na 12 bitů. Takže je zvláštní, že v případě digitálního řízení by byla zapotřebí několik-miliard-krát vyšší rozlišovačka.

Je potřeba trochu popřemýšlet a čist co jsem psal. Ta brutální rozlišovačka tam není jen pro potřebu takového rozlišení z hlediska přesnosti. Ale je tam potřeba protože ty čítače pracují v akumulátorovém režimu kdy přičítám/odečítám 50 milion-krát za sekundu. Pokud bych dejme tomu používal 8 bitové rozlišení "pod" StepKrokem tak bych dosáhl nejnižší možné rychlosti 195 KHz. A protože vyšší rozlišení čitače FPGA v MESE nečiní potíže a chtěli jít nejspíše na jistotu tak použili "trochu" vyšší přesnost než by bylo možná nezbytně nutné.

Píšeš, že HAL má na vstupu i výstupu pozici. Pokud jsem pochopil správně předchozí příspěvky, tak Mesa ale dostává rychlostní informaci, nikoli poziční.
Takže pokud bych chtěl použít stávající HAL, určený pro Mesu, a jen na něho místo FPGA pověsil desku s ARMem, tak bych dostával rychlostní informaci. Kdežto pokud by se napsala nová HAL komponenta, tak by se dala používat poziční informace, který by se (podle mě) asi zpracovávala lépe. A byla by asi vhodnější i v případě přechodu třeba ně nějaké digitální servo (EtherCAT nebo podobné), které by se dalo řídít pozičně.

Musíš si uvědomit že LinuxCNC nekomunikuje přímo s MESA kartou, ale s jejím ovladačem (Tedy HostMot2). Teprve HostMot2 se stará o výpočet vnitřního zpětnovazebního regulátoru tak aby podával pokud možno co nejlepší odezvu na požadovanou polohu. To jakým způsobem komunikuje HostMot2 s MESA kartou (v našem případě víme že příkazem požadované rychlosti) je naprosto jeho věc a LinuxCNC to nemusí zajímat.

No s tím ovladačem bych ještě upřesnil že je tam více vrstev a je vložen ještě pod-ovadač HostMot_PCI (nebo jak se to přesně jmenuje) pro komunikaci s kartami šuplými do PCI sběrnice.

Stejně tak je na Tobě při tvorbe HW abys z požadavku pozičního řízení svému HW posílal informace v jakékoliv podobě a složitosti abys dosáhl nějaké rozumné regulační chyby. Ta je tam z principu věci vždy, ale je na tobě abys vymyslel dostatečně inteligentní a robustní algoritmus pro minimalizaci této chyby. (a pokud to znamená třeba brutální rozlišení pozičního akumulátoru tak proč ne když to HW zvládá )

Vzhledem ke komplexnosti a specifikúm HAL ovladače pro MESU to není ideální způsob snažit se pověsit na její ovladač. Daleko jednodušší a rozumnější je napsat si vlastní HAL modul pro komunikaci s tvým zařízením. Ten HAL modul MESY neřeší pouze StepGeny (jak jistě víš) a nahodit do toho ARMu plnou funkcinoalitu by nejspíše nebylo tak snadné. Já tady pořád popisuju pouze komunikaci týkající se StepGenů, ale ono těch "modulů" v té MESE je o dost více a každý z nich v servosmyčce komunikuje a přenáší svá specifická data.

Takže bych šel cestou postupovat po malých krůčcích.
V první řadě ve vlastním modulu poslat pozici (nebo cokoliv) tvému a ARMu a bez jakéhokoliv starání se o výstup StepKroků na motory tu samou informaci hned poslat zpět jakožto výsledek skutečné polohy. A koukat nakolik tuto zdánlivě triviální úlohu tvůj HW zvládne.
Pokud rozchodíš tohle tak teprve pak má smysl uvažovat o dalším kroku. Tedy postarat se aby tvůj HW generoval StepKroky a Směr do driveru KM (nebo Serva). Ve výsledku se vůbec nemusíš omezovat na StepKrokování a můžeš rovnou komunikovat s Driverem na nějaké sběrnicové úrovni (CAN, RS485, EtherCAT) to už je šumafuk, ale ten první krok je zásadní

[yaqwsx]

To Mex: Co se týká zpětivoltování a výkonového posílení, tak mě překvapovalo, že každý pin může fungovat jako vstup i výstup (znám jenom řešení, kdy se obousměrně zpetivoltuje, ale nemůžu tahat větší proudy).

A ke stepgenům: je celkem jedno, jak to Mesa implementuje (šla jednoduchou cestou inkrementálního počítání a aby nedocházelo ke kumulační chybě, tak musí používat tak obrovskou přesnost). Je potřeba implementovat stejné rozhraní jako SW stepgeny, které můžou fungovat ve vícero módech: http://linuxcnc.org/docs/html/hal/rtcomps.html

To CZ_Pascal: Osobně mě překvapuje jenom 16 bitů v celočíselné části - vždyť to je velmi málo a nemůže to na stroje s větším rozjezdem chtít stačit...

[robokop]

hadam ze tech 16 bitu nehraje roli
stejnetak jako v jinych komponentach v halu kdyz to pretece tak to hal umi resit jako preteceni toho registru a pocita s tou hodnotou dal v nejakem sirsim registru
napriklad u hal komponenty HID jsem mel pouzity na rucni kolecko teensy s 8bit registrem kterej porad pretejkal a systemu to bylo jedno
pokud vim tak nektere IO oddelovaci kary s encoderovymi vstupy jsou nejak multiplexovane a predpokladam ze pouzivaji kratke citace na zachovani polohy mezi jednotlivymi refreshi a taky to teda musi pretejkat a maji to poresene

[yaqwsx]

U MPG je mi to jasné - tam tě v následujících dvou iteracích zajímá pouze rozdíl, ale do a ze stepgenů se posílá/vyčítá absolutní poloha.

[robokop]

a neni tam nejaka korekce na preteceni a neladuje se to do sirsich registru?
tj ze by se pri kazdem refreshi taky resila jen diference

[CZ_Pascal]

.. pokud tech 16 bitů nepřetočíš celých během jedné servoperiody (tedy nepožaduješ rychlost vyšší než 32,7 metrů za sekundu), tak není problém aby Ovladač MESY (Tedy HostMot2) přetečení ošéfoval.
LinuxCNC už se dozví polohu jako FLOAT tak jak očekává a nic neřeší.

Jak jsem psal, je to jen o tom jak se tvůrce hardware a jeho ovladače postaví k problému a jak jej vyřeší. LinuxCNC to pak může být vcelku jedno.

[robokop]

jj chapu je to spis otazka hostmotu
psal jsem ze i jinde v linuxcnc jsem tohle potkal a bylo to vyresene

[RaS]

32,7m/s to je skoro 2km/minutu, 120km/hodinu .. kdybych býval vědět že má mesa takové "výrazné" omezení tak bych do toho nikdy nešel

[robokop]

uz asi potreti se budu opakovat ale libi se mi na tom jak robustne je to navrzene