CNC Fórum

Mex píše:Ale o tom HW generátoru jsem měl lepší mínění. Myslel jsem si, že se tam kromě požadovaného počtu kroků a jejich rychlosti posílá i rampa.
Ale podle toho, co píšeš, to tak není. Pak by to bylo o dost hloupější, než jsem si myslel.

Neposílá se požadovaný počet kroků (to by bylo MESE k ničemu), ale pouze rychlost.
Zpětně se čte skutečná poloha na submikronové úrovni (reálné kroky - tedy to co se posílá do driveru - jsou moc "zaokrouhlené" pro rozumný výpočet).

Rampy se dějí pouze skokově, ale vzhledem k velikosti "rychlostního skoku" to většině driverů fyzikálně vůbec nevadí, pouze to možná chytřejším driverům které se snaží započítat do své proudové smyčky i zrychlení nejspíše znesnadňuje život (tady spíše hádám než že bych si byl 100 jistej že jsou drivery chytré i na této úrovni)

Mňo a jak už jsem tu někde i psal, právě posílání hodnoty akcelerace jsem chtěl do MESY dopsat, ale nějako na to nemám čas (vzhledem k tomu že to už není uplně triviální tak mi to jakožto amatérskému programátorovi nejde během času který mám k dispozici ).

Jinak i to o dost hloupější chování než sis myslel je docela krásně funkční.

yaqwsx píše:Jojo, je to běžná věc - u USB se nejčastěji využívají kontrolní přenosy, bulk přenosy (garantované doručení dat, není garantována odezva - používá se např. u externích disků), interrupt přenosy (zpravidla HID zařízení) a isochroní (webkamery, zvukové karty - zařízení se u plánovače sběrnice přihlásí k dané periodicitě dat a je mu zarezervována kapacita sběrnice).

S rušením USB nemám zkušenosti, skutečně je to tak vážné? Viděl jsem totiž už i USB zařízení pro medicínská a automotive provedení...

Problém je u těchto izochronních přenosů nejspíše jejich FIFO buferování, kdy skutečne můžes odesílat/přijímat data v přesně pravidelných intervalech, ale doba od "nasamplování" dat a jejich "doručení do cíle" je nespíše vadou na kráse která degraduje uzavření polohové smyčky na/za hranici použitelnosti.

Bylo by potřeba to skutečně prověřit a njspíše prošlápnout po milionté slepou uličku

Nejhorší možné zpoždění je 1 rámec (1 ms). Běžně se používají zpětnovazební smyčky na místo v bufferu pro zvukové karty s vlastním zdrojem hodin. Pravda, např. na Windows je při klasickém přístupu z user space zpoždění 16 ms, ale při přístupu z kernel space lze docílit minimálního zpoždění. Jak je to na Linuxu netuším (psal jsem pouze ovladače pro Windows).

Každopádně tímto nenavrhuji realizovat něco přes USB - jen když už v tomto tématu uvádíme věci "na pravou míru", tak mi přišlo vhodné tento fakt zmínit právě kvůli zde často omílanému stereotypu "USB nemůže fungovat". Říkám, že teoreticky může, jen je třeba jej správně použít.

I tak bych chtěl mít doma konečně Mesa kartu, abych si měl s čím hrát. Tvrdě narážím na limity LPT s SW stepgenů.

s tim rusenim je dost problem
v realu i bez ruseni vyzkousej jak se ti bude chovat vse co mas doma na USB na 5m usb prodluzce nedejboze dvouma za sebou
zhruba tak se to pak chova na pulmetrovem kabelu kterej je v rozvadeci s 5KW menicem

proto jsem si poridil prevodnik na 232 kterej je na FTDIcku a nema kabel tedy dela druhou vec co nesnasim a to ze vylamuje ten usb konektor ale porad lepsi nez se dvakrat do minuty znova pripojovat k PLC nebo obcas uplne restartovat pc kvuli zamrzlemu USB radici protoze vedle sepnul nejakej stykac

Z USB nemám veľkú skúsenosť, takže sa nemôžem vyjadriť.
Zvažujeme však možnosť komunikácie cez NET sieť. Pod Windows s tým máme veľmi dobré skúsenosti s vlastnym driverom nemáme problém vykonať aj 3000 prenosov/sekundu z našich meracích zariadení.
Pod Linuxom však nemáme s drivermi veľké skúsenosti. Asi urobíme niekoľko pokusov a potom sa rozhodneme.

existuje EtherCAT stack pro linux ktery zajistuje softwarovy master pro sbernici
jako slave jsou dostupne hotove IO v cene do 300,-Kc

to by bylo mohlo byt velmi robustni reseni

S EtherCATom sme tiež oboznámení a dokonca sme riešili aj vlastný máster na klasickom PC pod Windows. Sme aj členovia ich klubu.
S týmto prepojením pre PiDiCNC sa viac stretávame pri jeho použití v systémoch ako CODESYS, kde je požiadavka na slave moduly vo väčšej vzdialenosti od centra.

k tomu usb ze si to nevymyslim
tady to treba nekdo resi:
http://www.eetimes.com/document.asp?doc_id=1279704" onclick="window.open(this.href);return false;

Tak když se v servocyklu opravdu posílají jenom rychlosti a zpět čtou reálně vykonané počty kroků, tak té komunikace je velmi málo. To jenom k tomu použití LPT pro komunikaci PC-FPGA. Tohle prostě musí dát LPT s velkou rezervou.

Navíc tohle by se s velkým přehledem dalo generovat i procesorem, na to není třeba FPGA. Komunikace jednou za milisekundu a na základě toho generování pulzů o definované rychlosti timerem je bez problémů.

Jinak k tomu USB: místo isochronního přenosu bych na to použil bulk a řešil to raději redundatním vysíláním stejného rámce opakovaně. Za 1ms se jich dá odeslat 8, takže určitě nějaký dojde včas.

A k té spolehlivosti USB: určitě tady bude někdo, kdo používá USB SmoothStepper nebo jiný interpolátor třeba k Machu. Tak by mohl poreferovat, jak je to se spolehlivostí.

CZ_Pascal píše:Zpětně se čte skutečná poloha na submikronové úrovni (reálné kroky - tedy to co se posílá do driveru - jsou moc "zaokrouhlené" pro rozumný výpočet).

Chápu to správně, že se zpět posílá počet realizovaných kroků a zlomek posledního kroku, který už byl sice vyslán, ale ještě je "v progresu" ?

Mex píše:Tak když se v servocyklu opravdu posílají jenom rychlosti a zpět čtou reálně vykonané počty kroků, tak té komunikace je velmi málo. To jenom k tomu použití LPT pro komunikaci PC-FPGA. Tohle prostě musí dát LPT s velkou rezervou.

Souhlasím, ale i tak se mi PCI zamlouvá více.

Mex píše: Navíc tohle by se s velkým přehledem dalo generovat i procesorem, na to není třeba FPGA. Komunikace jednou za milisekundu a na základě toho generování pulzů o definované rychlosti timerem je bez problémů.

S tím souhlasím, na druhou stranu FPGA ti dává o něco přesnější kontrolu (v hlavě si dělám odhady na požadované pulzy STEP-DIR pro vysoké mikrokovoání a na to nestačí 16 bit PWM a nevím o procesorech, které by měly velký počet 32 bit PWM kanálů na časovačích) a mnohem větší svobodu v tom, co implementovat, v jakém počtu. Mesa karty se mi líbily v tom, že je to hotové řešení, které je bez práce a komponenty jsou skládat, jak se shodí. Pokud by se ale našel někdo, kdy by se pustil do HW modulu postaveného na nějakém ARMu a psaní HAL modulů, rád se připojím (a myslím, že mám co nabídnout). Jen se časově necítím na to táhnout sám.

Mex píše: Jinak k tomu USB: místo isochronního přenosu bych na to použil bulk a řešil to raději redundatním vysíláním stejného rámce opakovaně. Za 1ms se jich dá odeslat 8, takže určitě nějaký dojde včas.

Eh, to právě ne. To buď dojdou všechny nebo žádný - z principu USB a jeho plánování. Když už, tak isochroní.

EDIT: Tak on už se někdo do něčeho pustil: http://pekka.eu/cnc/

yaqwsx píše:S tím souhlasím, na druhou stranu FPGA ti dává o něco přesnější kontrolu (v hlavě si dělám odhady na požadované pulzy STEP-DIR pro vysoké mikrokovoání a na to nestačí 16 bit PWM a nevím o procesorech, které by měly velký počet 32 bit PWM kanálů na časovačích) a mnohem větší svobodu v tom, co implementovat, v jakém počtu.

Jasně, FPGA řešení je teoreticky o dost výkonnější.
Ale zase modul se STM32 koupím pod 3 USD. A pro většinu nekosmických nasazení bude generovat stejné průběhy, jako to FPGA.

Jinak čítače skutečně bývají častěji 16bit, ale zase je k nim 16bit předdělička. Navíc si nemyslím, že zrovna tohle by bylo úzké místo. Pokud pojede čítač ze 36 MHz, tak i bez předděličky se dostanu s pulse-rate dolů až na nějakých 500 Hz. Takže pokud o něco jde, tak spíš o granulitu (rozlišovačku).

ARM od Atmelu, který je na ArduinoDue, má docela dost 32bit čítačů (konkrétně 9), v tomhle je o dost líp vybavený, než třeba procesory STM.

yaqwsx píše:To buď dojdou všechny nebo žádný - z principu USB a jeho plánování. Když už, tak isochroní.

Jo, to máš pravdu. Teda asi ne zrovna kvůli plánování, ale kvůli potvrzování.
Takže několikanásobný isochronní.

Ano, nápad postavit stepgen např. nad STM32 se mi hodně líbí a mám velkou chuť jej realizovat. Dokonce i takovou, že zkoumám jak se vlastně z HAL modulu komunikovat s okolním světem. No co už, bakalářka asi půjde stranou

yaqwsx píše:Ano, nápad postavit stepgen např. nad STM32 se mi hodně líbí a mám velkou chuť jej realizovat. Dokonce i takovou, že zkoumám jak se vlastně z HAL modulu komunikovat s okolním světem. No co už, bakalářka asi půjde stranou

No já jsem na tom podobně. Schází mi znalost HALu a komunikace s externím modulem na straně LinuxCNC.
Proto tady loudím informace od těch, co o tom něco ví.

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.