Mesa 7i90

[packa]

a náhodou by ses o to s námi nechtěl podělit ?
Občas by se mi něco takového opravdu hodilo.

[Mex]

Zatím jsem to pojal jako bastl (taky jsem použil termín "ubastlil jsem"). Pro případnou veřejnost by se tam napřed asi musel dodělat trochu komfort nastavování.

Ono to není tak triviální, jak to na první pohled může vypadat. Pro malé rychlosti (do nějakých 100-200 kHz) se to se slušným procesorem dá udělat i jen SW. To byla i moje předchozí verze.
Ale pro trochu vyšší rychlosti už se to musí čítat pomocí HW. Ty čítače musí být nejmíň 24-bit, optimálně ale raději 32-bit. Skládat to z diskrétních součástek by bylo moc elektroniky.
Takže to chce použít nějaké čítače, integrované v MCU. Jenže ty obecně nebývají obousměrné. Aspoň se mi nepovedlo najít žádný běžně dostupný procesor, který by uměl přímo čítat obousměrně podle externího signálu DIR. Daly by se udělat takové šílenosti, jako použít pro každou osu 2 čítače, kde každý by čítal jeden směr. Ale na to zase většinou není v těch procesorech dostatek čítačů.

Ale čítače v různých ARMech umí připojit kvadraturní signály. Tyhle čítače jsou většinou jen 16-bitové, rozšíření na 32-bit už se různýma fintama dá udělat.
No ale pak je třeba před to ještě předřadit převodník DIR/STEP na IRC. Ten už se musí poskládat z diskrétních součástek. Ani to není úplně triviální, protože IRC nese víc informace než DIR/STEP, takže i teoreticky ten převod není přímočarý.

Až budu velký kluk, tak udělám ještě verzi s FPGA. Nakoupil jsem si teď nějaké desky, které budou základem pro "DIY Mesu", tak jako cvičný úkol by nebylo marné z nich udělat extrémně rychlý tester.

[OompaLoompa]

Ospravedlňujem sa zúčastneným za dlhšiu odmlku - dovolenky, čas, atď.

K tej Mex-fupe "straw man" argumentácii sa vyjadrovať nebudem. Priznám sa, že súťaže vo vytrhávaní z kontextu mi moc nejdú, tak radšej férovo uznám porážku akoby som to tu mal zasie*ať ďalším balastom

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 aký iný výsledok si od tohto experimentu vlastne očakával?

Veď presne za týmto účelom tam tá PID-ka je!
MESA posiela spätnú väzbu o počte/smere vygenerovaných impulzov, a PID-ka v LinuxCNC si to už na tú "nulu" (v sume) doreguluje.

Tzn. že tvoj experiment nijak inak ani dopadnúť nemohol. Teda dokým by nenastalo dáke iné "katastrofálne" zlyhanie - ale to je len málo pravdepodobné..

A btw - nepíšeš či daný experiment bol robený v defaultnom (rýchlostnom), alebo až po úprave - v polohovom režime Toto by si mohol upresniť ďakujem

Vadilo mi tam zpochybnění smyslu regulace (ať už PIDkou nebo čímkoliv)

No to by bolo celkom ironické keďže prvotným dôvodom mojej reakcie v tomto vlákne bolo práve zpochybňovanie zmyslu/funkcie danej regulácie daktorými zúčastnenými..

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.

Asi by som to mal upresniť - samotný prenos po zbernici nespolahlivý nie je, keďže CRC (v zmysle kontroly chýb) je totiž už súčasťou prenosového protokolu.

Prenosy sú nespolahlivé v tom zmysle, že nedokážeš vždy zaručiť prenos z hľadiska časového. Zadáš IRQ pre DMA/burst transfer, a systém ti to jednoducho odmietne (dôvodov môže byť viacero), tak musíš zadať ďalší - až dokým to nebude úspešné. V daktorých prípadoch to môže byť aj 20-30 či viac pokusov - a to už dokáže celkom nepekne nabúrať tvoj časový "harmonogram".

Keď sme takýto prípad posledne riešili, snažili sme sa daný problém izolovať - a skončilo to celkom prozaicky - na "inovátorskom" poňatí BUS-masteringu v prípade PCIex-PCI bridge čipu od "skvelej" čínskej ASMedie (konkrétne AMS1083). Tento čip je ale bohužiaľ celkom populárny - hlavne v oblasti platformy mini-ITX (často využívanej pre LinuxCNC) - čiže treba s tým bežne počítať

MESA s tým problém nemusí mať, lebo tam tie prenosy asi nebudú tak objemné, a tým pádom ani časovo tak kritické (ergo je tam na to dostatočná rezerva).

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"

Tak s týmto sa samozrejme nedá nesúhlasiť

Pomer cena/výkon sa s "profi" segmentom moc nedá zrovnávať - hlavne keď tam už len samotná riadiaca jednotka môže kludne byť aj 10000€ Tu MESA víťazí na plnej čiare - bez debát.
--------------------------------------------------

PS: na MEXa: Ako nakoniec dopadlo skúmanie "výpadkov" tej PWM-ky? Za info vopred ďakujem

[Mex]

Testy pomocí toho (zatím ještě) bastlu probíhaly v režimu bez PID. Tedy podle zde dříve zavedené terminologie "v polohovém režimu", i když to vlastně žádný pohový režim v pravém slova smyslu není.
Vyřazením PID odpadly různé překmity při změně směru, opožděné dojíždění na konci pohybu atd. Prostě teď se výstup stepgenu chová jako podle učebnice, úplná paráda. Takže PID jsem z obsluhy Mesy definitivně vyřadil.
Jedinou šanci na reparát by PID mohla dostat jen v případě, že až/jestli někdy dodělám to testovací kurvítko latence, tak kdyby se při nepříznivém časování ukázala její potřeba.

A že to testování muselo dopadnou dobře? No tak to teda fakt nemuselo. Jakákoli chyba při přenosu po dlouhé sběrnici bez kontroly integrity dat, a to v hodně svižném tempu, by výsledek okamžitě rozhodila. I když by to v praxi při reálném frézování možná ani nemuselo být poznat. Tenhle test to ale nekompromisně ukáže. Popravdě řečeno když to dopadlo tak dobře, tak jsem raději všechno ještě jednou zkontroloval, protože jsem tomu až příliš ideálnímu výsledku nechtěl věřit.

Nemůžu si teď vybavit, co jsi myslel výpadkem PWM, takže poslední dotaz neumím zodpovědět.

[OompaLoompa]

Testy pomocí toho (zatím ještě) bastlu probíhaly v režimu bez PID. Tedy podle zde dříve zavedené terminologie "v polohovém režimu"

No tu pozor - ono aj v tom "polohovom režime" tam stále dáka tá korekčná "PID"-ka je, len v tomto prípade (control-type 0) nie je riešená externe (cez PID komponent), ale je "skritá" ako súčasť samotného drajvera. V žiadnom z prípadov sa nejedná o plnohodnotné využítie celého P+I+D regulačného procesu, no to nie je vôbec podstatné..

Prostě teď se výstup stepgenu chová jako podle učebnice, úplná paráda. Takže PID jsem z obsluhy Mesy definitivně vyřadil.

Fakt, že ti na úplnom konci sedia "kontrolné súčty" ešte automaticky neznamená, že v rámci jednotlivých servocyklov sa všetko generuje presne tak ako má hlavne v prípade chybovosti pri prenose dát (v spojitosti s už spomínanou absenciou kontroly) by to mohlo byť celkom rodeo

A že to testování muselo dopadnou dobře? No tak to teda fakt nemuselo. Jakákoli chyba při přenosu po dlouhé sběrnici bez kontroly integrity dat, a to v hodně svižném tempu, by výsledek okamžitě rozhodila.

Viď vyššie. Tá korekčná "PID"-ka tam stále je, a aj na základe výsledkov tvojich testov evidentne funguje docela dobre

Nemůžu si teď vybavit, co jsi myslel výpadkem PWM, takže poslední dotaz neumím zodpovědět.

Strana 5-6 tohto vlákna:

Umíte prosím dosáhnout 100% PWM např. při řízení vřetene?
Mně to funguje tak, že když mu dám plný signál, tak tam na PWM výstupu (který by měl být v té chvíli trvale v log. 1) sem-tam vyběhne nějaká špička do nuly. Je to zanedbatelné, místo 100% to pak vychází na nějakých 99.99%, ale stejně je to zvláštní. Připadá mi to, jak by v návrhu toho PWMgenu vnikal nějaký hazard.

Ja som písal, že by to mohlo byť ošetrenie pre systémy s fail-safe (lebo to je celkom bežná vec) ... neskôr to Fupe overil aj na inej MESE, s rovnakým výsledkom.

Tak by ma aj celkom zaujímalo, či to teda nakoniec bol len ten fail-safe, alebo dáka fw/sw či iná "porucha"

[Mex]

Umíte prosím dosáhnout 100% PWM např. při řízení vřetene?
Mně to funguje tak, že když mu dám plný signál, tak tam na PWM výstupu (který by měl být v té chvíli trvale v log. 1) sem-tam vyběhne nějaká špička do nuly. Je to zanedbatelné, místo 100% to pak vychází na nějakých 99.99%, ale stejně je to zvláštní. Připadá mi to, jak by v návrhu toho PWMgenu vnikal nějaký hazard.

Ja som písal, že by to mohlo byť ošetrenie pre systémy s fail-safe (lebo to je celkom bežná vec) ... neskôr to Fupe overil aj na inej MESE, s rovnakým výsledkom.
Tak by ma aj celkom zaujímalo, či to teda nakoniec bol len ten fail-safe, alebo dáka fw/sw či iná "porucha"

Aha, to už jsem pustil z hlavy, proto jsem si na to nevzpomněl.
Když mi pak fupe potvrdil, že to dělá stejný bordel i jinde, už jsem se tím nezabýval.
Podle těch nepravidelných a vůbec podivných pulzů to není "fail-safe", ale jen "fail", tedy přesněji "fail in design".
Na praktické funkčnosti to nic nemění, takže už to neřeším. A když to na mě vykoukne na osciloskopu, tak se podívám z okna a tvářím se, že to nevidím.

[r4cv]

A když to na mě vykoukne na osciloskopu, tak se podívám z okna a tvářím se, že to nevidím.

To sa budem musiet naučiť. Môže to byť praktické.

[OompaLoompa]

A když to na mě vykoukne na osciloskopu, tak se podívám z okna a tvářím se, že to nevidím.

Ale vážne - docela by ma zarazilo, ak by si takúto "hrúbku" v kóde za celú tú dobu nikto nevšimol
hlavne ak zvážime, že sa jedná o open-source platformu, a že sa táto "chyba" zjavne vyskytuje naprieč celým MESA portfóliom

Taktiež stojí za zamyslenie, že ak by tam táto "chyba" nebola, tak by daný PWM výstup v spojitosti so zariadeniami, ktoré implementujú fail-safe, jednoducho nebol použiteľný..

Podle těch nepravidelných a vůbec podivných pulzů

Mne k tomu napadá iná teória

Čo ak je max. hodnota PWM v kóde obmedzená nie na celých 100%, ale práve len na dákych tých 99.99% lebo v takom prípade by sa tie "jehly" (nuly) na výstupe taktiež vyskytovali zdánlivo náhodne/sporadicky

Zabezpečila by sa tým kompatibilita s fail-safe, a zároveň by to bolo aj velmi jednoduché a efektívne riešenie..

A možno tým vývojárom MESY len moc verím

[Mex]

Čo ak je max. hodnota PWM v kóde obmedzená nie na celých 100%, ale práve len na dákych tých 99.99% lebo v takom prípade by sa tie "jehly" (nuly) na výstupe taktiež vyskytovali zdánlivo náhodne/sporadicky

Zabezpečila by sa tým kompatibilita s fail-safe, a zároveň by to bolo aj velmi jednoduché a efektívne riešenie..

Ono to tak nějak možná bude, že z nějakého technologického důvodu nebude 100% skutečně 100%, ale o fous míň. Nebo tam bude v případě 100% nějaký hazard, který občas vyjde a občas ne. Oboje je teoreticky špatně, ale ani jedno z toho nemá v praxi žádný zásadní dopad, řekl bych.

Ale nerozumím té úvaze o kompatibilitě s fail-safe. Pokud se něco dělá fail-safe, tak jsou většinou podmínky pro testovatelnost funkčnosti dost přísně stanovené, testovací okno má definované parametry atd. Takže nechápu, jak by to kladně nebo záporně mohl ovlivnit nějaký nevypočitatelný hazard, který navíc může být podobný reálné situaci, kdy místo 100% tam prostě zadám třeba těch 99.98%.

[OompaLoompa]

Ale nerozumím té úvaze o kompatibilitě s fail-safe. Pokud se něco dělá fail-safe, tak jsou většinou podmínky pro testovatelnost funkčnosti dost přísně stanovené, testovací okno má definované parametry atd. Takže nechápu, jak by to kladně nebo záporně mohl ovlivnit nějaký nevypočitatelný hazard

Tiež sa mi nezdá, že by to vývojári "vedome" riešili práve takto spomenul som to len ako jednu z možností

Keď si ale pozrieš toto:

tak je jasné, že zas až tak nepravideľné to asi nebude.. práve naopak

Fail-safe v prípade PWM býva u jednoduchších zariadení riešený tak, že pokiaľ je na vstupe konštantne log1 po určitý max. časový interval, riadiaci obvod to vyhodnotí ako poruchu a zastaví, až dokým sa modulácia na vstupe neobnoví. Či sú na to dáke normy/štandardy - to netuším (ale asi ano).

Z obrázku hore je vidno, že max. interval "bez modulácie" je cca 0.3ms, čo by malo byť viac ako dostatočné na zaistenie "kompatibility" s väčšinou zariadení implementujúcimi vyššie spomínaný fail-safe.

Zaujímavé by bolo ešte preskúmať možnú závislosť tých intervalov od nosnej frekvencie. Prípadne aj šírku pulzov (aká vlastne je? ). Takto z jednej statickej vzorky se nahouby veští

[robokop]

treba to je nejak do jiste miry kompatibilni s prevodniky ktere mesa pouziva na svych oddelovacich deskach kde resi analogovy vystupy
nepamatuju si podrobnosti z tohoto vlakna jen me to blesklo hlavou
jestli jsem mimo tak to ignorujte

[atlan]

Nieje to chyba merania? Gnd sondy pripojene na zlom mieste. A uz to fici.

[OompaLoompa]

Nieje to chyba merania? Gnd sondy pripojene na zlom mieste. A uz to fici.

Keďže to namerali obaja, a na rôznych MESA kartách, tak asi nie. To by musela byť iná náhoda

Jedine že by šírka toho pulzu bola na hrane toho, čo im tie čínske logické analyzátory "za-pět-babek" dokážu zaznamenať (prosím brať s humorom ), a tým pádom to takto vynechávalo. Ale to je tiež len veľmi hypotetická úvaha

treba to je nejak do jiste miry kompatibilni s prevodniky ktere mesa pouziva na svych oddelovacich deskach kde resi analogovy vystupy

Ak som tomu správne pochopil, tak tento signál už je priamo z výstupu danej karty. Predpokladám, že na tých čisto "oddelovacích" deskách by to mohlo vyzerať podobne, no je možné, že tam to riešili inak, a výstup bude "čistý" kto vie, nech odpovie

[robokop]

vystup z tech desek uz je analogovy