Mesa 7i90

[OompaLoompa]

Chcel by som poďakovať Pascalovi za vecný príspevok, na základe ktorého je zjavné, že problematiku MESY má naštudovanú viac ako všetci mi tu dokopy. I keď reakcia v značnej miere mimo tému (PCI vs LPT implementácia), no i tak v mnohých ohladoch veľmi prínosná. Ďakujem

Zároveň by som ho touto cestou chcel poprosiť o vysvetlenie, že keď už sa rozhodol moje príspevky priamo (ale nešpecificky) kritizovať, v čom konkrétne teda vidí rozpor s tým, čo o fungovaní daných systémov napísal on sám? Lebo možno som len natvrdlý já, ale dáko tam ten údajný (bližšie nešpecifikovaný) rozpor neviem nájsť Za odpoveď vopred opäť ďakujem

Tak, a za druhé..

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)

Lenže toto vlákno, a celá diskusia v ňom, je o 7i90 - ergo implementácii cez LPT, a nie PCI zbernicu

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.

áha no je to možné, ale zhodneme sa asi len v tom, že o tom obaja "prd víme"
snáď to Mex časom z tých zdrojákov doštuduje, a podelí sa o výsledky

Vzhledem k tomu že se předpokládá nulová chybovost při přenosu skrže PCI

áha čiže o reálnych prenosoch po PCI zbernici (na bežných strojoch) v podstate nemáš moc šajn, keďže inak by si takéto dačo asi nenapísal..

je totiž úplne bežné, že z celkového počtu burst DMA transferov sa musí dakedy aj značné množstvo opakovať, čo dakedy dokáže spôsobiť aj problémy s časovaním (a aj preto je dobré si tam pre tieto prípady nechať aspoň dáku časovú rezervu)

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

áha, takže "srandy" no jo

podľa mňa je úplne jedno ako moc sa to človek snaží obhájiť či okecať - ak absencia kontrolných súčtov na zbernici nebola volbou čisto z hľadiska dákeho kritického nedostatku prostriedkov (ako je napr. priepustnosť zbernice, či procesnej kapacity systému), tak to je jednoducho neospravedlniteľné, a odsúva to dané riešenie nanajvýš tak do hobby-segmentu..
 

[OompaLoompa]

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.

Ja o voze, a ty o koze porovnávaš neporovnateľné

V mojom prípade sú len data jedného feedback packetu (teda pre jednu osu) mnohonásobne objemnejšie ako je u teba celkový transfer pre všetky osy dokopy konkrétne v tomto prípade to je 820b (včetne overheadu)

Pri 50Mbit a 5kHz cykle máš k dispozícii 10000b, a tzn. že už len samotné posielanie dát spätnej väzby zaberie bezmála 70% celkovej kapacity danej zbernice. Našťastie sa ale jedná o full-duplex, čiže prijímanie a odosielanie sa deje súčasne, a je to teda zvládnutelné - i keď tam toho priestoru nazvyš ostáva fakt len minimum.

Takže asi tolko k tvojmu porovnaniu
ale cením si tú prezentáziu - je zaujimavé vidieť, že v prípade relatívne "hlúpych" generátorov impulzov to ide aj podstatne jednoduchšie
 

[Mex]

Ja o voze, a ty o koze porovnávaš neporovnateľné

Hmm.
Napíšeš, jaký jsi umělec, když jsi dokázal rozjet 8os/5kHz na nějaké optice 50 Mbps.
Já ti na to odpovím, že nevím co používáš za systém, ale že Mesa by tohle zřejmě obsloužila i na pomalé LPT.
Napíšeš, že jsem komik, že LPT a 8os/5kHz není možné.
Já ti prakticky ukážu, že to skutečně jde.
Ty napíšeš, že mluvíš o něčem jiném.

No tak jo, jsem komik.
Měj se pěkně.

[fupe]

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.

Ja o voze, a ty o koze porovnávaš neporovnateľné

V mojom prípade sú len data jedného feedback packetu (teda pre jednu osu) mnohonásobne objemnejšie ako je u teba celkový transfer pre všetky osy dokopy konkrétne v tomto prípade to je 820b (včetne overheadu)

Pri 50Mbit a 5kHz cykle máš k dispozícii 10000b, a tzn. že už len samotné posielanie dát spätnej väzby zaberie bezmála 70% celkovej kapacity danej zbernice. Našťastie sa ale jedná o full-duplex, čiže prijímanie a odosielanie sa deje súčasne, a je to teda zvládnutelné - i keď tam toho priestoru nazvyš ostáva fakt len minimum.

Takže asi tolko k tvojmu porovnaniu
ale cením si tú prezentáziu - je zaujimavé vidieť, že v prípade relatívne "hlúpych" generátorov impulzov to ide aj podstatne jednoduchšie
 

Koukam, že zatimco co jsem chlastal pivo na zahradce, tak se to tu docelo rozjelo.

A já si celou dobu myslel, že se bavíme o mese 7i90 na LPT a ono ne. Tak to pak chapu že se asi nedohodnem.
To víš, my hobíci, co tomu nerozumej, protože né každej navrhuje optický zbernice a komunikacni protokoly pro ne, pouzivame jenom ty hloupy generatory pulzu.

Rozčiluješ se, že nekdo porovna LPT a PCI a sam sem tahas nejaky opticky NASA projekty a snazis se nam tvrdit že to všechno delame blbe. MEX ti jasne ukazal, ze to co jsi tvrdil ze nelze, tak že to jde. JA vim, ze je tezke priznat neci pravdu, ikdyby byla podložena, ale to je každýho věc.
Jednodussi je tvrdit že jsi to myslel jinak.
Všem děkuji za prinosne informace, je potreba si je trochu prefiltrovat a korigovat,ale zase jsem o neco moudrejsi.
Martin

[fupe]

Projíždím forum na linuxcnc a našel jsem nasledují.
PCW je člověk, který rozumí jak LCNC tak MESE, pro kterou pise soft.

PID is used with velocity control instead of the built in driver position mode for a couple of reasons:
1. The PID feedback is more robust with respect to host servo thread jitter and has smaller following errors (better performance)
2. The structure is the same for open and closed loop ( Closed loop just substitutes encoder feedback for stepgen feedback)

Note the step/dir system _always_ uses feedback, its just more hidden and less adjustable in the position mode

Testoval jsem to na realné mašine, pravda je tomu asi 2-3 roky a ta PIDka se chovala divne, osa dojizdela do polohy klidne 0,5 vteriny. To je jestli dobre pocitam 500 servo-cyklu. Nebyl jsem schopnej ji nijak naladit a defaultni hodnoty p=1000 ff1=1 byly na nic. Tak nevim.
M

[robokop]

Troufam si rict ze chyba musela byt jinde
Me pidka v linuxcnc drzi velmi pekne
Dokonce se odvazim tvrdit ze lepe jak u nejakych renomovanych vyrobcu sys.

[Mex]

Projíždím forum na linuxcnc a našel jsem nasledují.
PCW je člověk, který rozumí jak LCNC tak MESE, pro kterou pise soft.

PID is used with velocity control instead of the built in driver position mode for a couple of reasons:
1. The PID feedback is more robust with respect to host servo thread jitter and has smaller following errors (better performance)
2. The structure is the same for open and closed loop ( Closed loop just substitutes encoder feedback for stepgen feedback)

Note the step/dir system _always_ uses feedback, its just more hidden and less adjustable in the position mode

Testoval jsem to na realné mašine, pravda je tomu asi 2-3 roky a ta PIDka se chovala divne, osa dojizdela do polohy klidne 0,5 vteriny. To je jestli dobre pocitam 500 servo-cyklu. Nebyl jsem schopnej ji nijak naladit a defaultni hodnoty p=1000 ff1=1 byly na nic. Tak nevim.
M

Prosím tohle (z čeho cituješ) bylo ale předpokládám o použití PID v celém procesu, včetně jeho mechanické části, ne? Tj. použití PID pro servo v rychlostním režimu s pravítky nebo vytaženým enkodérem.
Nebo to platilo i jenom pro tu elektronickou část, tj. pro úkolování stepgenů?

Opravdu se obávám, že jsme si zavedli terminologii, které jsme pak trochu podlehli. Z použití PID v úkolování stepgenů jsme automaticky usoudili na "rychlostní režim", ale ono to asi tak úplně nebude. Podle mě se autorům obsluhy Mesy prostě nějaká část modulu PID hodila, tak ji použili, i když to zřejmě vpodstatě jako běžná PID vůbec nefunguje.
No a teď jsme to plynule začali prolítat ještě s rychlostním režimem skutečného serva, kde už se opravdu uplatňuje skutečná PID regulace.

Ale samozřejmě je možné, že jsem úplně mimo.
Díky.

[fupe]

Je to odpověď na otázku, proč pncconf používá pid pro systém se step/dir........
Takže presne to co jsme tu resili.
https://forum.linuxcnc.org/49-basic-con ... 5i25-7i76
M

[Mex]

Takže je to podle očekávání, i tady borec pomíchal skutečnou PID přes celý systém (tj. servo v rychlostním režimu s pravítky/enkodérem) a obsluhu stepgenů.
Zdánlivě podobný problém, protože se v obou případech vyskytuje klíčově slovo "PID", ale ve skutečnosti dvě rozdílné kauzy.

Podstatný je až úplný závěr threadu:

When the PID is used with the stepgen only (no external feedback) the PID loop insures that the hardware
step generator always generates the proper number of pulses at the proper times despite delays caused by direction
changes, timebase differences between the CPU clock and the step generator clock, and delays between reading
the position and writing the velocity

Tady prostě jen narazil problématiku stapgenů na klasické kopyto, aniž k tomu napsal, proč a jestli předchozí způsob bez PID měl nějaké neduhy.

[robokop]

Jen pro upresneni
Pidku na synchronizaci stepgenu v rychlostnim modu mam na jednom stroji
A je tam nastavene tusim jen P a FF1 jestli si dobre pamatuju.
To je dost rozdilne od nastaveni pidky se servem a pravitky

[CZ_Pascal]

....
Zároveň by som ho touto cestou chcel poprosiť o vysvetlenie, že keď už sa rozhodol moje príspevky priamo (ale nešpecificky) kritizovať, v čom konkrétne teda vidí rozpor s tým, čo o fungovaní daných systémov napísal on sám? Lebo možno som len natvrdlý já, ale dáko tam ten údajný (bližšie nešpecifikovaný) rozpor neviem nájsť Za odpoveď vopred opäť ďakujem

No neber to prosím hned osobně. Zajisté sis v mé odpovědi všimnul podivení, že zrovna Ty nebo Fupe někde napíšete zásadní "botu". Semtam je to i tím že si to po rychlém přečtení špatně vyložím. A i já nezřídka v rychlosti napíšu hovadinu

Tak tedy konkrétně. Asi jsem se tak nějako chytl tohodle :

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.

Vadilo mi tam zpochybnění smyslu regulace (ať už PIDkou nebo čímkoliv), což tak nějako naznačovalo že netušíš která bije - a to mi bylo vcelku divné a donutilo k reakci.
Po druhém přečtení však vidím, že se ten "otazník" vztahoval k podmínce že by ta komunikace byla opravdu jednosměrná (což není pravda) - pro jednosměrnou komunikaci by opravdu ta regulace tady postrádala smysl neboť by bez zpětných dat nebylo na základě čeho regulovat. (asi zafungovala únava a rychločtení a možná i "cizí" jazyk ).

Tak, a za druhé..

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)

Lenže toto vlákno, a celá diskusia v ňom, je o 7i90 - ergo implementácii cez LPT, a nie PCI zbernicu

No z mého pohledu to není zdaleka jen o 7i90 přes LPT, ale řeší se tu dotazy které jsou společné všem (nebo alespoň většině) MESA kartám využívajících řízení StepDir.
Řešení této problematiky vývojáři z MESY (bez ohledu na to zdali to řídím skrze LPT nebo PCI) je myslím natolik podobné že jsem se rozhodl podělit se o své poznatky s kartamy připojenými přes PCI sběrnici (konkrétně tedy 5i20, kde byl řadič PCI zvlášť a použit "starý" Spartan II nebo 5i24, kde je Spartan6 který obsahuje přímo ve svém Firmware jednoduchou imlementaci PCI řadiče)

Vzhledem k tomu že se předpokládá nulová chybovost při přenosu skrže PCI

áha čiže o reálnych prenosoch po PCI zbernici (na bežných strojoch) v podstate nemáš moc šajn, keďže inak by si takéto dačo asi nenapísal.

je totiž úplne bežné, že z celkového počtu burst DMA transferov sa musí dakedy aj značné množstvo opakovať, čo dakedy dokáže spôsobiť aj problémy s časovaním (a aj preto je dobré si tam pre tieto prípady nechať aspoň dáku časovú rezervu)

No přiznám se bez mučení že nejsem vývojář hardware pro PCI sběrnice a docela jsem věřil že ten přenost zase tak nespolehlivý není. Asi nejsem sám kdo se rozhodl mu věřit a věří mu i vývojáři FIrmwaru těch MESA karet. CRC se používá pouze pro kontrolu správnosti Firmware, ale při běžném přenosu nikoliv. Zatím jsem nikde v žádné diskusi nenaznamenal že by někdo řešil probém se spolehlivostí MESA karty píchlé do PCI slotu. Ty MESA karty tam spokojeně jednou "šnečí" rychlostí 33MHz, kdežto současné PCI by měly jet spolehlivě minimálně na 66MHz. (Některé serverové verze jsou hnány přes 133MHz až na 266MHz. Tam už je jasné že v tom fofru se semtam může nějaký ten bit "splést".)

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

áha, takže "srandy" no jo

no nemusíš mě hned chytat za slovo - to bylo myšleno odlehčeně. Důležitost spolehlivosti přenosu dat samozřejmě nění nic zanedbatelného.

podľa mňa je úplne jedno ako moc sa to človek snaží obhájiť či okecať - ak absencia kontrolných súčtov na zbernici nebola volbou čisto z hľadiska dákeho kritického nedostatku prostriedkov (ako je napr. priepustnosť zbernice, či procesnej kapacity systému), tak to je jednoducho neospravedlniteľné, a odsúva to dané riešenie nanajvýš tak do hobby-segmentu..

No ale ona to vzhledem k cenové hladině je více-méně "hobby-segment".
Jenom je ta implementace (a teď mám na mysli hlavně tedy ty PCI verze) natolik podařená, že poměrem cena/výkon dává naprdel i "profi-segmentu"

Držím palce a těším se co "vypadne" z MEXe - docela by se mi líbilo zbavit se závislosti na občas nedostupných MESA kartách. Jen mi to LPT tak nějak nejde moc "pod nos" v porovnání s PCI. Jako udělá to hodně muziky, ale určité limity už tam jsou tak nějak "cítit ve vzduchu".

[CZ_Pascal]

A je tam nastavene tusim jen P a FF1 jestli si dobre pamatuju.

A já myslím (jestli si to dobře pamatuju) že tam opravdu defaultně (tedy skrze konfigurátor) nic víc ani není.

"2. The structure is the same for open and closed loop ( Closed loop just substitutes encoder feedback for stepgen feedback)"

Tohle je podle mě ten jediný důvod proč tam defaultně cpou ten regulátor a rychlostní mód StepGenů. Už se to snaží udělat až moc univerzálně předchystané na úkor kvality nastavení. Zřejmě předpokládají že si to zkušenější nastaví lépe a ti méně zkušení ani nepoznají že se jim zhoršily parametry - jiné vysvětlení mě nenapadá.

[Mex]

Ubastlil jsem si tester signálů pro krokáče/serva, případně vstup z enkodérů.
Spouštěcím momentem bylo, když si Mesa na LPT portu při dlouhém kabelu sem-tam něco vymyslela.
Tak jsem na výstup stepgenů napojit tester, který simuluje připojené motory a zobrazuje polohu, kde by se reálná osa nacházela, tj. jestli stepgeny generují to co mají generovat.

Dělal jsem to už dřív, když jsem kdysi řešil problémy se svojí starou frézkou. Ale tehdy jsem to napsal jen pomocí SW, což pro běžné krokáče rychlostně vyhovělo, ale pro rychlé výstupy už by to nestíhalo.
Teď jsem to udělal pomocí HW, takže to může čítat pulzy s max. frekvencí 5 MHz na každé ose. Po výměně jedné součástky by se to dalo zvednout dokonce na 10 MHz, ale to už je asi zbytečné, i těch 5 MHz vyhoví s rezervou.

Výsledky pokusů jsou příjemné. Použil jsem pro test velký g-kód s cca 275 tis. řádků. Na mé reálné frézce jel nějakých 10 hodin. Tady jsem pořádně osolil rychlosti a akcelerace, navíc jsem nastavil hodně velký počet kroků na milimetr. Takže stepgeny jely na frekvenci 2 MHz. Tou vysokou rychlostí to simulované frézování trvalo cca hodinu a čtvrt. Pustil jsem to 10x, což odpovídá cca 100 hodinám činnosti reálné frézky.
A za celou dobu Mesa neztratila ani jediný krok!
Takže spokojenost, i při celkem dost dlouhém LPT kabelu (cca 70cm) to jede spolehlivě. A to jsem to ještě provozoval přes PCI I/O kartu se svým upraveným driverem, takže i ten už teď považuju za spolehlivý.

Jako obvykle, když jsem to dodělal a otestoval, tak jsem se sám sobě divil, jak jsem dosud bez toho mohl fungovat.

[packa]

Ahoj to je zajimavé , můžeš popsat jak to přesně funguje ? tam jako zavedeš step a dir a čítáš od nuly do milionů a zpět a musíš být na konci na nule ?

[Mex]

Ano, v podstatě tak, jak píšeš.
Průběžně to zaobrazuje polohu všech os, podobně, jako je třeba na obrazovce v LinuxCNC nebo Machu. A tahle poloha, načtená z výstupů stepgenů, by se měla rovnat té, kterou zobrazuje ten LinuxCNC nebo Mach.
Tedy že ty virtuální krokáče nebo serva stojí na přesně stejné pozici, o jaké si LinuxCNC nebo Mach myslí, že by tam měly stát.

Samozřejmě za letu se to těžko dá očima kontrolovat. Ale ono to stačí i jen na konci, kdy po návratu na Home musí i ten tester ukazovat přesně nulu. Jakákoli chyba přenosu (v případě Mesy) nebo vypadlý krok (v případě SW stepgenu na PC, které má problém s latencí) se taky okamžitě projeví.