chuťovka pro znalce Linuxcnc

[RaS]

mám servodriver kterej ukazuje počet došlých pulzů od 0-99999 na jednu otáčku jeden pulz je 0,5mikronu takže jedna otáčka je 5mm
když nastavím pozici XYZ v linuxcnc na 0,0,0 a resetuju servodrivery tak ukazují počet pulzů 0,0,0... za tohohle stavu pustím program nebo si hraju se šipkami na klávesnici a když dám nakonci hraní/programu dojet do polohy XYZ 0,0,0 tak serva ukazují opět 0,0,0 tzn ,že ty serva jsou tam kde byly na začátku, že nedošlo k žádnému rušivému pulzu prostě vše tak jak má být...
jenže když vezmu MPG kolečko a hraju si s ním doprava doleva různé osy tak mi to načítá "falešné" pulzy a stroj se odchyluje od skutečné původní nuly, jenže počet pulzů z MPG kolečka odpovídá skutečnému počtu pulzů, které počítá program (prostě otočím kolečkem o 10doprava pak o 10doleva a na stroji je zase 0 ale na driveru je třeba 100 a skutečná poloha ačkoliv stroj ukazuje nulu je třeba o 0,02mm posunutá..)
takže ani MPG si negeneruje žádné chybné impulzy, protože je linuxcnc vše počítá správně..

a aby to bylo ještě víc na palici, tak to nedělaj všechny osy, osa Z to nedělá vůbec, osa Y to dělá chaoticky doprava a doleva takže se to ve finále neprojeví skoro vůbec, ale osa X to načítá víceméně skoro pořád jen na jednu stranu takže ta odchylka narůstá...když přehodím kabeláž mezi sebou tak se to otočí takže to ani servodriverem být nemůže..
prostě z počítače leze jinej počet pulzů než by měl v režimu MPG přestože se program tváří že je to OK..

v čem je problém?

přišel jsem nato naprostou náhodou kdy se mě zdálo že fixluje sonda a měří pokaždé něco jiného..

[CZ_Pascal]

Předpokládám že skuteční znalci se brzy ozvou s vysvětlením.

Do té doby bych se podíval jaký je nastaven mód pro to MPG kolečko.
Jestli si to dobre pamatuji tak jsou k dispozici alespon dva - poziční a rychlostní (Pozition mode/ Velocity mode).

zjednodušeně řečeno :
Poziční se snazi dojet presne na pozici kam dojelo MPG (osa pojede dal i kdyz MPG davno stoji dokud nedorazi do "cile")
V rychlostnim modu jedu pokud se toci MPG. Ve chvili kdy se MPG zastavi tak zastavi i osa (bez ohledu na to zdali se MPG netocilo treba nekdy rychleji nez stihala dana osa jet)

[RaS]

ale pozice MPG a pozice v linuxcnc je naprosto stejná.. to že by to nestíhalo tím to není určitě...

[Radek-B]

Nic na palici v tom nevidim, proste bud stracis anebo nacistas pulzy na vedeni kterym ridis pulzne drivery.
Kdyz je stracis , tak to muze byt zpusobeno tim ze pulzy generujes prilis kratke anebo prilis rychle pro vstupni optocleny.
Kdyz je nacitas , tak to zpusobuje ruseni, ruzne indukcni smycky.
Anebo mas uplne na dve veci to vedeni kterym to krmis.

Pokud to chces overit jednoduse softwarove, tak si vytvor enkoder v LINUXCNC a to co poustis do driveru si zaroven nalinkuj z-5 do toho enkoderoveho vstupu.
Enkoderu dej takovy scale aby odpovidal tomu zobrazeni na driveru. Timto si presne zobrazis to co posilas ven do driveru. A enkoder v EMC musi ukazovat vzdy stejne hodnoty jako enkoder driveru.

RADEK

[RaS]

ale když nastavím MPG stupnici na 0 a vynuluju osu tak ať s tím jezdím kam jezdím tak se to pořád shoduje, takže z MPG do mesy na vstup encoderu doleze stejnej počet pulzů, pokud by to ztrácelo tak bych dojel MPGem na stupnici 0 a linuxcnc by mi ukazoval něco jiného přece ne?
a pokud by to bylo v kabeláži tak proč se to přenáší z osy na osu podle toho jak ty kabely prohodím, dělá to vždy nejvíc osa X a klidně můžu tahat ty pulzy po drátech k Zku které předtím tu chybu nedělalo a najednou po přehození dělá.. ..

[RaS]

paradoxem je taky to, že když MPGem točím v nastavení 0,1mm/krok tak to neudělá v podstatě nikdy, a když to přenastavím na 0,01 tak to začne chybovat nejmarkantněji.. připadá mi to že je to závislé na rychlosti otáčení toho MPGu.. jenže nechápu proč jen jedna osa?

[packa]

a nemáš někde nějaké hrabaté číslo , myslím počet pulzů na mm , třeba použitím řemnic a podobně ?? ono to pak určitě trochu zaokrouhluje

[CZ_Pascal]

..... připadá mi to že je to závislé na rychlosti otáčení toho MPGu....

Právě proto jsem chtěl at skontroluješ nastavení modu toho MPG jestli není náhodou v rychlostním modu (od kterého bych očekával že se takhle divně může chovat)

(ale klidně vyzkoušej ještě dalších sto jiných věcí - není vhodné jít hned na první pokus k pravděpodobné příčině.... )

[RaS]

..... připadá mi to že je to závislé na rychlosti otáčení toho MPGu....

Právě proto jsem chtěl at skontroluješ nastavení modu toho MPG jestli není náhodou v rychlostním modu (od kterého bych očekával že se takhle divně může chovat)

(ale klidně vyzkoušej ještě dalších sto jiných věcí - není vhodné jít hned na první pokus k pravděpodobné příčině.... )

to je kde konkrétně?
ale nedává mi smysl proč linuxcnc ukazuje správně ale generuje jinak, přece mpg jde do linuxcnc a ten generuje pulzy pro drivery na základě toho co ten mpg udělal ne? takže když mpg řekne udělej 100pulzů tak linuxcnc pošle 100pulzů a posune hodnotu osy o 100pulzů, nechápu proč by měl mpg dát jinej počet pulzů než přečetl program..

[RaS]

a nemáš někde nějaké hrabaté číslo , myslím počet pulzů na mm , třeba použitím řemnic a podobně ?? ono to pak určitě trochu zaokrouhluje

mám celé čísla, nicméně i kdybych neměl tak by to zaokrouhlovalo a kecalo i při běhu normálního programu

[RaS]

jenom ještě ke konfiguraci, je to celé na MESe 5i20ce, na ni je nakonfigurovanej encoder do nějž vedou AB signály z MPGu žádnej pomalej port nic..

[RaS]

..... připadá mi to že je to závislé na rychlosti otáčení toho MPGu....

Právě proto jsem chtěl at skontroluješ nastavení modu toho MPG jestli není náhodou v rychlostním modu (od kterého bych očekával že se takhle divně může chovat)

(ale klidně vyzkoušej ještě dalších sto jiných věcí - není vhodné jít hned na první pokus k pravděpodobné příčině.... )

takže všechny osy to maj nastaveno stejně v defaultu na 0, axis.0(1,2).jog-vel-mode 0 ověřeno tím to není.. ani jsem nevěděl že tam takovej nějakej parametr je..

[fupe]

Asi bych hledal chybu jak pise Radek-B nekde mezi dratama a driverem popripade v signalech z encoderu. Tam si asi kabely neprohazoval.
Zkusil bych pouzit jeden encoder z mesy v režimu counter-mode=1 a prodratovat do nej signaly step-dir pro driver a porovnavat rozdil mezi tim co napocita encoder a co driver.
softwerovej encoder neumi pocitat step-dir, ale jenom hrany na jednom kanalu, takze nepouzitelny pro jezdeni tam a zpatky.
Pokud se hodnoty budou rozchazet, tak se nekde v dratech-driveru ztraci kroky, nebo keca encoder, kdyz budou stejny tak bych teprve presel na hledani chyby nekde v linuxcnc

Nebo druha varianta
protahnout vystup z encoderu na servu pres driver jeste do mesa encoderu a porovnavat pozadovanou hodnotu v linuxcnc s namerenou z encoderu.
Tuhle metodu sem pouzival, kdyz mi to zlobilo uplne stejne jako tobe , ale i pri normalnim jezdeni (muj driver neumi zobrazit co napocital), abych zjistil ze sem uplne blbej a mam povolenej sroubek na encoderu a pri velkych akceleracich se to proste malinko protocilo.
Tahle druha varianta ma tu vyhodu, ze resi celej retezec linuxcnc - stepgen - driver - motor - encoder - linuxcnc a porovnavas to na stejnym miste.
Samozrejme muzes obe varianty spojit a to by bylo, aby nevylezlo na svetlo bozi, kde je zakopanej pes. Me ten povolenej sroubek potrapil celou sobotu, nez sem natahal draty poupravil konfiguraci a jiny kraviny. Resil sem tou dobou ruseni (kompletni predratovani masiny) a myslel sem ze uz sem to ruseni vyresil a najednou to zase blblo se stejnejma priznakama, nastesti to bylo z uplne jinyho duvodu, kterej me hned nenapadnul. Ale zase ta detska radost, kdyz clovek zamyka garaz a ono to zase dela co ma.
Jediny co me mate na tvym pripadu je, ze to nezlobi kdyz jede program, nebo kdyz pouzivas sipky.


Martin

[RaS]

mě právě zaráží to, že při šipkách a vlastním programu to nechybuje takže se dá říct že se pulzy neztrácí, a pokud se tedy ztrácej nebo vytvářej falešné pulzy na kabeláži k mpgu (kterou jsem jako jedinou nevyměnil a neprohodil neboť je to jeden kabel) tak mě hlava nebere proč to program počítá správně tak jak to skutečně je?

[fupe]

zkousim s tim jezdit na virtualnim stroji a vsechny hodnoty sedej.
podivej se jestli sedi hodnoty axis.0.joint-pos-cmd vs jog-counts x jog-scale. zacinal sem v nule, takze je to bez offsetu.

mpg kolecko nedela nic jinyho, nez ze meni podle otaceni hodnotu joint-pos-cmd (motor-pos-cmd) ktera pak jde dal do stepgenu, kterej si ridi rozjezdy atd.
to znamena ze by melo byt jedno jestli jezdis sipkama nebo koleckem. Zkousel sem menit i hodnotu jog-counts skokove (nekonecne rychly otaceni koleckem) a stejne to jede podle rampy na stepgenu.
nevidim zadnou souvislost proc ti to blbne.....
M