Mesa 5i25 a 7i76

[CZ_Pascal]

a abych své tvrzení trochu podložil exaktněji (přecejen někteří členové fóra utrpěli i technickým vzděláním )

..... LPT V ECP módu má propustnost 2,5 MByte/s, což by na přenos hodnot stepgenů, enkodérů a případných dat pro expanzní IO mohlo stačit.

Po SPI komunikujeme rýchlosťou 15MBit, môže však byť aj menšia,

PiDiCNC 15MBit/s = 1.875MByte/s což je méně než LPT 2.5MByte -> z čehož by se dalo usuzovat že i to LPT je při správném použití dostatečné

Okamih prevzatia rýchlosti a odpamätanie pozície sa určuje v FPGA a tu je latencia na úrovni nanosekúnd.
Pre nás je dôležité iba to, aby sme nestratili cyklus, čiže aby latencia programu neprekročila cca. 0.9 ms.
Vo videu sme chceli iba ukázať, že latencia programu na Raspberry Pi2 je vyhovujúca.

Je potrebné asi zabudnúť na nazeranie na latenciu ako doposial.
Nepravideľnosť prístupu programu z PC, alebo z Raspberry Pi 2 na PiDiCNC nehrá žiadnu úlohu, pokiaľ samozrejme neprekročí vyššie uvedených cca. 0,9ms.
Hardware si sám zabezpečí latenciu na úrovni cca. 50ns.

Nevím jak kdo doposud nahlížel na latenci, ale technicky vzdělaném člověku tvrzení že "Nepravideľnosť prístupu programu z PC, alebo z Raspberry Pi 2 na PiDiCNC nehrá žiadnu úlohu" nestačí pokud to nepodložíte nějakými fakty (výpočty).

Vzhledem ke způsobu jakým LinuxCNC (a tedy i PiDiCNC) řídí polohu motorů (ať už jde o Krokové motory nebo Serva) je teoretická možná chyba od požadované daná především maximálním nastaveným zrychlením řídícího systému.

Při akceleraci 1000[mm/sec^2] a latenci 0,9[ms] dojde (může dojít) k odchylce od požadované polohy o 0,405[um]
Při akceleraci 0,5g (4900[mm/sec^2]) a latenci 0,9[ms] dojde (může dojít) k odchylce od požadované polohy o 1,98[um]

Při akceleraci 1000[mm/sec^2] a latenci 0,195[ms] dojde (může dojít) k odchylce od požadované polohy o 0,019[um]
Při akceleraci 0,5g (4900[mm/sec^2]) a latenci 0,195[ms] dojde (může dojít) k odchylce od požadované polohy o 0,093[um]

Nakolik je chyba pro dané použití (které se u hobíka liší od profíka) závažná si už každý přebere nejspíše sám

[packa]

já už delší dobu provozuji mesu7i43 - čili na lpt a jsem max spokojen,je pravda že na driverech nemůžu nastavit max mikrokrok protože bych nedosáhl rychlostí jaké chci . teď mi to jezdí 7m/min . Mě právě limituje latence která je na mé desce dost vysoká a linuxcnc mě prostě nenechá nastavit vyšší rychlost. Takže ta latence i když tam je FPGA pole které se stará o generování strep a dalších věcí tak je limitující .

[robokop]

diky za vypocet
to tedy dokazuje ze to ani v jednom pripade nehraje roli
a nevyrazuje to fakticky ani to lpt ze hry

nicmene ja to lpt pouzivat nemuzu z tech dalsich vyse uvedenych duvodu

jestli se mi povede navalit do raspberry co tu mam to linuxcnccko tak zkusim ty latence a reakce te grafiky pri vytizenejsim realtime jadru

k tomu packovi
uplne nechapu jakto ze to tak je vzhledem k vyse uvedenemu principu
dokaze to nekdo vysvetlit?

[CZ_Pascal]

linuxcnc mě prostě nenechá nastavit vyšší rychlost. Takže ta latence i když tam je FPGA pole které se stará o generování strep a dalších věcí tak je limitující .

Kdo tě nenechá nastavit vyšší rychlost? Wizard ?(nepoužívám takže nevím jestli něco takového dělá)
Popiš trochu přesněji co ti brání, nebo jak se problém projevuje když to "přeženeš"

Max Mikrokrok znamená co ? (256 mikrokroků na jeden celokrok ?) Jaké stoupání šroubů máš ?

[Mex]

LPT V ECP módu má propustnost 2,5 MByte/s, což by na přenos hodnot stepgenů, enkodérů a případných dat pro expanzní IO mohlo stačit.

Plný souhlas. Předběhl jsi mě, napsal bych to samé. I když možná ne, abych nedráždil robokopa.

Při akceleraci 1000[mm/sec^2] a latenci 0,9[ms] dojde (může dojít) k odchylce od požadované polohy o 0,405[um]
...

Jak jsi to prosím počítal?
Já do fungování LinuxCNC vevnitř nevidím (mrzí mě to a stydím se za to). Ale tak nějak idealisticky jsem si myslel, že v servo-threadu nasype procesor do FPGA zadání, co má další 1ms dělat, a to FPGA (nebo jiný externí subsystém) už si to tu milisekundu šéfuje sám.
Pokud by to tak skutečně bylo, tak pak skutečně na latenci moc nezáleží, protože to FPGA to (předpokládám) dostane s předstihem, takže pokud to nepřesáhne nějakou mez, tak by to mělo být OK.

Jestli je to jinak, tak mě prosím oprav (nebo někdo jiný).

Díky.

[robokop]

pro stepgen v hradlovem poli plati:

ten hardware v tom poli generuje pouze nastaveny kmitocet podle nejakeho registru ktery se periodicky updatuje z nadrazeneho systemu
ve stejnou chvili si nadrazeny system vycita pozici z citace vydanych impulzu aby vedel kde je

software nadrazeneho systemu v te same periode porovnava kyzenou a skutecnou hodnotu a podle toho patricne meni pozadovany kmitocet ktery ma pole generovat

deje se tak periodicky v intervalech podle nastaveni v linuxcnc
ty intervaly mohou mit nepresne casovani ovlivnene tou latenci, predpokladam tedy pouze spozdeni o maximalni hodnotu te latence

z hlediska tehle komunikace evidentne o nic nejde

z hlediska softwarovych stepgenu a napriklad jejich vystupu na LPT to ovlivnuje maximalni rychlost generovani kroku protoze ta latence ovlivnuje spozdeni kazdeho jednoho kroku
onehda jsem to pocital a vychazelo pri striktnim zachovni casovani tedy delky a odstupu pulzu step a dir dle dokumentace driveru krokacu neco kolem 9 KHz max frekvenci kroku (a to je sakra malo)
samozrejme se na to kasle a pak se muzou obcas pri vetsi latenci ztratit nejake kroky a cim vetsi ten hazard je tim vic takze to treba leta nemusi byt patrne a pri nejakem jinem programu to zacne delat chyby

[Matko]

PiDiCNC

Áno, v podstate je to tak ako píšete.
CZ_Pascal to napísal veľmi presne a jeho výpočet o maximálnych chybách polohy je správny.
Je však potrebné uviesť, že k uvedeným chybám môže dôjsť iba počas zrýchľovania a v prípade pohybu po úsečke iba v smere pohybu, teda v smere úsečky a nedochádza k chybe v tvare trajektórie pohybu. V prípade zrýchľovania po kružnici, samozrejme môže dôjsť aj k nepresnosti v tvare trajektórie. Táto chyba je však podstatne menšia ako chyby z uvedeného výpočtu ( v závislosti na polomery kružnice ).

[robokop]

dalo by se zkusit to nacteni nejakeho vetsiho 3d g kodu?

ja tu ted zkousim linuxcnc na jednickovem raspberry a je to desne pomale
prijde mi jako by to bylo nejak spatne zkonfigurovane, nakompilovane jadro
i elementarni veci jako otevreni nabidky v GUI bere desne systemovych prostredku
natoz kdyz pustim linuxcnc

[Mex]

pro stepgen v hradlovem poli plati:

Jasně, u SW stepgenů je to jasné, a tam je to fakt jenom nouzovka.

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.

Z hlediska latence je podstatné, jestli je to double-buffered systém nebo ne. Pokud ano, tak se latence vůbec neprojeví (při max. latenci v rámci jednoho kroku). Pokud ne, tak toho použití FPGA zas tak moc neřeší a k ideálu to má dost daleko.

Každopádně díky za osvětu.

[robokop]

jj vse se opravi pri naslednem "refreshi"
ono to vlastne funguje stejne jako analogova serva
tam se taky posila jen informace o rychlosti ktera je zadana
a z pravitek se cte poloha
a nad tim v jadru linuxcnc je PID kontroler

kdyz se tedy treba posle mirne chybna rychlost (v dusledku latence) tak se to v dalsim refreshi projevi jako odchylka a ta se kompenzuje stejne jako odchylka z nejakeho vnejsiho vlivu

akorat ta vazba rychlostni servo sroub stul masina pravitka je u stepgenu resena citacem vygenerovanych pulzu na vystup ( v ramci toho pole)
ten se cte coby zpetna vazba o poloze

[packa]

pokud nastavím větší rychlost než mi dovoluje pncconf tak při pohybu osy když dosáhnu té max rychlosti a dál zrychluji tak se mi schodí pohony a vyskočí hláško "axis 1 following error , zítra zajdu do dílny a opíšu kroky a nastavení driverů. a ano myslel jsem si že mesa nebude závislá na latenci , ale je .
Když jsem si hrál s pícnc tak se při vyšších rychlostech stávalo že se pohyb osy vlek za tím co zobrazovalo raspbery a nakonec se to schodilo podle nastavené hodnoty ferror

[yaqwsx]

to Mex: Vývojáři LinuxCNC razí filozofii, že všechno (čti všechny zpětné vazby) by se mělo počítat přímo v jádru systému - tzn. na CPU. Proto je real-timová složka OS nevyhnutelná. Má to své výhody i nevýhody, pro mě výhody převyšují (zejména proto, že upravit jakékoliv chování systému je relativně bezbolestné, netřeba studovat speciální HW, využívá se co nejvíce general-purpose HW a není problém portovat na nové systémy). Co mám zkušenost, tak i spousta profi řídicích systému funguje na obdobném principu. Přirozeně to kopíruje i klasickou regulační smyčku, kdy jsou jednotlivé PID regulátory (polohový, rychlostní, momentový) postupně navěšeny na sebe.

Toto je také důvod, proč LinuxCNC nepodporuje žádný speciální HW pro interpolaci. Pouze "hloupé" Mesa karty.

[yaqwsx]

PS: Teď mě napadlo - víte o tom, že na tohle by stačilo vlastně na tomto fóru neskutečně zatracované USB? USB 2.0 posílá data po mikrorámcích. Při použití isochronních přenosů každých 125 us může jít po sběrnici od zařízení (resp. do zařízení) datový paket tuším až o délce 1024 bytů (nedám za přesné číslo ruku do ohně, ale rozhodně po tom jde tahat 32 bit audio na 700 kHz). Je garantováno, že data dojdou včas, není ale garantováno, že při přetížení sběrnice data dojdou.

[robokop]

ono to usb je zatracovano zejmena protoze selhava tam kde je vetsi ruseni coz v pripade cnc je prakticky vzdy
to ze se da posilat takhle "synchronne" je pro me novinka
ale nikdy jsem to nijak do hloubky nestudoval

[yaqwsx]

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í...