Mesa 7i90

Odpovědět
Uživatelský avatar
grade065
Příspěvky: 1012
Registrován: 9. 1. 2015, 12:45

17. 7. 2018, 10:57

Ten obr. 3 není to nějaké beždění té osy?
Když snížíš akceleraci nebo tak... Jak se to změní?
Pro chlupatý koule mistra Kápě pečený na vohni!!
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

17. 7. 2018, 11:38

Tak jsem provedl první měření a.....
pohyb sem a tam v ose X o 10mm
nahoře dir, dole step
1.jpg
detail zmeny smeru.
nic neobvykleho
2.jpg
a nakonec konec pohybu, tady je trochu divny, ze v dobe, kdy uz se nehybe step, tak si dir jeste trochu zakmita, ale nema to vliv na pohyb.
3.jpg
to přičítám tomu, že jsem použil defaultni konfiguraci, kde konfigurator nahrnul PIDku. jeste zkusim bez ni.


M
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

17. 7. 2018, 11:50

tak po odstraneni PIDky se to na konci chova "normalne"
4.jpg
M
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 11:56

Odpovědi na všechny vznesené otázky:
- Ne, ten odstup mezi jehlami není stejný. Tady to tak zrovna náhodou vyšlo, ale občas je to úplně jinak, někdy tam není jehla vůbec, někdy je jich tam třeba 5 různě poházených atd.
- Kořen mandragory jsem nezkoušel, a to je zřejmě chyba. Díky za tip. Doufám, že ho v Kauflandu vedou.
G-kód je velmi sofistikovaný:

G21 G90 G17 G40 G49 G64 P0.03
M7
G0Z20
G0X0Y0S24000M3
G1X200Y200F24000
G1X0Y0
M2

Nastavení stepgenů je takové, aby to generovalo při plném fofru STEP na frekvenci 2 MHz.
MAX_LINEAR_VELOCITY = 300.0

MAX_VELOCITY = 200.0
MAX_ACCELERATION = 10000.0
STEPGEN_MAXVEL = 250
STEPGEN_MAXACCEL = 12500
DIRSETUP = 200
DIRHOLD = 200
STEPLEN = 200
STEPSPACE = 200
STEP_SCALE = 10000

- Ne, ten 3. obrázek není normální brždění osy. Normální je to první zabrždění, ale ten opětovný rozjezd a opět zabrždění (navíc s nesmyslným přepnutím DIR uprostřed) tam rozhodně nepatří.

Když jsem se na to vyspal, tak mi připadá, že snad jediné možné vysvětlení je, že při přenosu po LPT dochází k občasným chybám. Pokud by to byla chyba při přenosu PC->Mesa, tak by to mohlo udělat tu jehlu, při chybě čtení, tj. Mesa-> PC by to zase mohlo zblbnout driver Mesy, který by si myslel, že je jinde než ve skutečnosti je.
Některé protokoly (třeba LBP16) umí zabezpečení pomocí CRC, ale zde u přenosu po LPT se to bohužel nepoužívá.

Takže udělám několik pokusů:
- vyrobím krátký LPT kabel (teď ho mám dost dlouhý, použil jsem nějaký hotový koupený kabel)
- pokud to nepomůže, tak to připojím na jiné LPT, zkusím třeba použít PCI LPT kartu (která už díky úpravám driveru funguje)
- zprovozním zase svůj bastl-tester DIR/STEP, který jsem si kdysi dělal, ten se připojí na výstupy DIR/STEP všech os a počítá, kde by se vřeteno mělo nacházet

Díky všem za odpovědi.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 11:58

fupe píše: 17. 7. 2018, 11:38 Tak jsem provedl první měření a.....
No jo, no.
Ty máš prostě dobře vychovanou Mesu. Na rozdíl od té mojí puberťačky. :-(

To zakmitávání a případně dojíždění na konci mi to v rychlostním režimu Mesy dělalo stejně, v polohovém režimu to zmizelo.
Ještě dodatek - ty jehly na signálu DIR mi to dělá v obou režimech, polohovém i rychlostním.
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

17. 7. 2018, 3:40

To záleží jak tu kartu předchozí majitel vychoval. Možná na ní byl moc hodnej a ona zvlčela.
Mě to připadá jako nejaký rušení, on je ten protokol dost rychlej a tím padem i nachylnej na rušeni a jestli mas metrovej kabel......
Co me zaráží, je absence kontrolnich součtů. Jeden byte navic by nikoho nezabil. Treba ten priblblej sserial pouziva crc. A dokonce i funguje, ale nezkousel jsem co se stane, kdyz mu posles jiny crc, jestli si rekne znova o stejny data, nebo je zahodi, to musim vyzkouset.

jeste sem odpoledne tu moji (RaSovu) mesu trápil a to co poisujes sem ani jednou nezaznamenal.
Nedalo by se podivat v dobe, kdy to blbne jak si povidaji? jestli posila PC do karty a naopak to co ma?
Ten protokol mas uz zmaknutej.
M
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 4:14

S tou výchovou máš určitě pravdu. Já prostě neumím být na ženské přísný. Usmějou se na mě, něco trochu poodhalí a jsem v háji, odpustím jim všechno. Ach jo, už se asi nezměním.

Napřed zkusím ten krátký kabel. Pokud se to spraví, tak je jasné, kde je problém. Pak kouknu i na ta data, ale nemusí to nic ukázat. Analyzátor to může vzít jako ještě OK, ale FPGA už to třeba vyhodnotí jinak.

Ta absence jakékoli kontroly je opravdu trochu nedomyšlená. Teda spíš trochu dost.
Díky.
Uživatelský avatar
OompaLoompa
Příspěvky: 459
Registrován: 28. 6. 2017, 1:45
Bydliště: Západný Slovakistan

17. 7. 2018, 6:32

Mex píše: 17. 7. 2018, 2:32 Dělá to s jak s originálním firmware od Mesy, tak i s mým upraveným. Měnil jsem kabely, logický analyzátor, několikrát udělal OFF/ON jak Mesy tak LinuxCNC, ale funguje to pořád stejně blbě. :-(
A čo tak to skúsiť aj s dákymi normálnimi hodnotami akcelerácií, a nie tie tvoje 100g srandy? :D

Ja viem, papier (či v tomto prípade súbor s parametrami) znesie všetko, no treba si uvedomiť, že každá PID-ka je navrhovaná, ladená a testovaná len pre určitý rozsah parametrov :!: a i keď o tom reálne houno viem (daný firmvér/drajver som neštudoval), dovolím si predpokladať, že soudruzi z Mesy sa pri vývoji a testovaní tej PID-ky zameriavali skôr na hodnoty REÁLNE, a nie čisto teoretické - poťažne vycucané z prsta (akcelerácia 10g+ a pod.) :roll:

Neviem, možno sa mýlim, no minimálne tie divné pre/do-kmity na koncoch by mohli byť spôsobené práve týmto :?

Čo sa týka náhlych zmien DIR signálu ("jehly") uprostred pohybu konšt. rýchlosťou, tak to vyzerá skôr na iný problém. Mohla by to byť už spomínaná chyba komunikácie, no nechce sa mi veriť, že by súčasťou payloadu nebol žiaden kontrolný prvok :o tak natvrdlí zas soudruzi z Mesy nemohli byť :? či?

Ešte pár slov ohladom tej PID-ky..

Jej potreba vychádza zo samotnej podstaty riadenia polohy v rýchlostnom režime. Bez nej by sa ti reálna pozícia stroja po chvíli vždy rozchádzala s virtuálnou pozíciou v programe. Ide hlavne o to, že komunikácia PC ⇄ MESA nie je instantná, a časy prenosu paketov taktiež nie sú konštantné, ale fluktujúce v závislosti od mnohých predvídateľných aj nepredvídateľných parametrov (latencia systému, čakanie po IRQ, chyby v komunikácii vedúce k nutnosti opakovania prenosu, a pod.). A toto všetko je ešte umocnené v prípade prenosu cez relatívne pomalé LPT (lebo viac-menej platí, že čím rýchlejšia zbernica, tým menší dopad na celkové časovanie).

Pointa je v tom, že ak sa prenos údajov nasledujúceho servo-cyklu opozdí napr. o 0,2ms znamená to, že ti STEPGEN po dobu práve tých 0,2ms potenciálne bežal na nesprávnej frekvencii, a teda reálna poloha stroja je už momentálne iná, ako virtuálna :!: Tento rozdiel je samozrejme nutné v nasledujúcich servo-cykloch kompenzovať, a práve za týmto účelom tam tá PID-ka je. Predpokladám, že takouto PID-kou sa to vývojári rozhodli riešiť aj z dôvodu, aby bol celý proces týchto korekcií maximálne transparentný, a nebola potreba do riešenia danej problematiky zaťahovať vyššie vrstvy.

Howgh :D
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 7:13

Tak jsem vyrobil krátkou kabeláž a problémy zmizely.
Takže považuji za prokázané, že:
1 - dlouhý kabel je problém
2 - konstruktéři Mesy jsou tak trochu gumy

Tedy poučení - je třeba použít krátký kabel.
A chtělo by to napsat svému europoslanci, aby v Europském parlamentu prosadil zákon, že do Evropy se musí dodávat jen zabezpečené karty. Když se může regulovat zakřivení banánů, tak můžou regulovat i něco potřebného. Jinak by se mohlo stát, že nám naše CNC bude vrtat křivé laufy a pak třeba místo na zlé Rusy budeme střílet na hodné Ukrajince (zrovna jsem při tech pokusech čuměl na bednu).
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 7:34

OompaLoompa píše: 17. 7. 2018, 6:32 Ešte pár slov ohladom tej PID-ky..

Jej potreba vychádza zo samotnej podstaty riadenia polohy v rýchlostnom režime. Bez nej by sa ti reálna pozícia stroja po chvíli vždy rozchádzala s virtuálnou pozíciou v programe. Ide hlavne o to, že komunikácia PC ⇄ MESA nie je instantná, a časy prenosu paketov taktiež nie sú konštantné, ale fluktujúce v závislosti od mnohých predvídateľných aj nepredvídateľných parametrov (latencia systému, čakanie po IRQ, chyby v komunikácii vedúce k nutnosti opakovania prenosu, a pod.). A toto všetko je ešte umocnené v prípade prenosu cez relatívne pomalé LPT (lebo viac-menej platí, že čím rýchlejšia zbernica, tým menší dopad na celkové časovanie).

Pointa je v tom, že ak sa prenos údajov nasledujúceho servo-cyklu opozdí napr. o 0,2ms znamená to, že ti STEPGEN po dobu práve tých 0,2ms potenciálne bežal na nesprávnej frekvencii, a teda reálna poloha stroja je už momentálne iná, ako virtuálna :!: Tento rozdiel je samozrejme nutné v nasledujúcich servo-cykloch kompenzovať, a práve za týmto účelom tam tá PID-ka je. Predpokladám, že takouto PID-kou sa to vývojári rozhodli riešiť aj z dôvodu, aby bol celý proces týchto korekcií maximálne transparentný, a nebola potreba do riešenia danej problematiky zaťahovať vyššie vrstvy.
Už jsem to tu psal. Podle mě je použití PID v dané aplikaci nevhodné.
Regulátor PID funguje dobře (a byl pro to i navržen) v systémech se setrvačností nebo dopravním zpožděním. Není vhodný pro kompenzaci náhodných a nepredikovatelných chyb. A to je právě případ Mesy, kdy odchylky od přesného časování (jitter) mají náhodný charakter.
SW stepgen nic takového nepoužívá a funguje výborně. Stejně tak funguje dobře i Mesa, když běží v polohovém a nikoli rychlostním režimu, tedy bez té PID.
Uživatelský avatar
grade065
Příspěvky: 1012
Registrován: 9. 1. 2015, 12:45

17. 7. 2018, 7:36

A dlouhý a krátký je konkrétně jak?
Pro chlupatý koule mistra Kápě pečený na vohni!!
Uživatelský avatar
OompaLoompa
Příspěvky: 459
Registrován: 28. 6. 2017, 1:45
Bydliště: Západný Slovakistan

17. 7. 2018, 8:05

grade065 píše: 17. 7. 2018, 7:36 A dlouhý a krátký je konkrétně jak?
tak to bude spíš otázka pro ženy.. či? :lol:
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

17. 7. 2018, 8:08

Teď (krátký) má cca 1/2 metru, ještě trochu prodloužený odbočkou do tvaru T o dalších 20cm k logickému analyzátoru.
Předtím měl cca 1.5 metru plus těch 20cm k analyzátoru.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

18. 7. 2018, 1:34

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.
Mám to nastaveno jako řízení vřetene 0-24000 RPM. Až to nějakých cca 23999 RPM to funguje správně, ale pro vyšší otáčky už tam zůstává to plnění PWM na nějakých těch 99.995%, tedy teoreticky otáčky nějakých 23999.5 RPM. V praxi je to samozřejmě zanedbatelné, ale stejně je to zvláštní.
Mám to blbě nastavené nebo je to normální?

Nastavení PWM: základní frekvence PWM je 20 kHz, OUTPUT_SCALE je 24000, typ 1.
Stejně blbě to funguje i pokud použiju jako základní frekvenci nějakou soudělnou, např. 24 kHz nebo 12 kHz, případně použiju SCALE třeba 2000.
Díky.
Uživatelský avatar
OompaLoompa
Příspěvky: 459
Registrován: 28. 6. 2017, 1:45
Bydliště: Západný Slovakistan

18. 7. 2018, 4:21

Mex píše: 18. 7. 2018, 1:34Mně 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.
To bude fail-safe, resp. ošetrenie pre zariadenia s fail-safe, ktoré pri konštantnej hodnote na vstupe PWM idú automaticky do poruchy.

Mohol by si prosím ešte upresniť, či zámenou kábla za kratší sa teda vytratili všetky problémy (včetne dojazdov a pre-kmytov), či bol tým myslený skôr len ten bordel (jehly) na DIR? :roll: Ďakujem.
Odpovědět

Zpět na „Ostatní elektronika“