Ovládání KM programovacím jazykem, inpout32.dll

Uživatelský avatar
Gulliver64
Příspěvky: 459
Registrován: 1. 8. 2010, 7:52
Bydliště: Kuřim

7. 7. 2014, 2:55

petr.h píše:... Teď mi už snad chybí jen jediná instrukce ... jaký imuplz mi vypne to pískání v motoru ... alá mach3 Reset?
pokud to máš připojeno podle nastavení z prvního příspěvku tak posláním "1" na pin 4 - odpojíš driver. (asi logičtější by bylo přenastavit Active low u pinu 4 na "x" a programově posílat na pin 4 "1" pro nahození driveru a "0" pro jeho odpojení).
Modelová zařízení pro slévárny, hliníkové odlitky. První CNC frézka postavená v r.2003 ."Dřeváček" - r.2010. Zapřísáhlý uživatel MACH3 ver.2.63 .
Uživatelský avatar
Hades
Příspěvky: 1206
Registrován: 11. 10. 2012, 10:59
Bydliště: Praha; Mimoň

7. 7. 2014, 7:41

lubos píše: .....až budeš chtít rychlejší pohyb, budeš muse udělat akceleraci.
protože taky neznám všechno.... Kopni do mne s tou akcelerací, nějak mi google nic nevrací, ale asi jen neumím položit ten správný dotaz...
Diky
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

7. 7. 2014, 8:45

Hades píše:Kopni do mne s tou akcelerací, nějak mi google nic nevrací, ale asi jen neumím položit ten správný dotaz...Diky
Buď si děláš srandu, nebo máš pokaženého Googla, že ti nic nevrátí na akceleraci (nebo rampu).
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

7. 7. 2014, 9:12

no a kdyyz to neda google tak to musi dat logika

treba si predstav ze by postavili auto s jednim kvaltem zubovou spojkou misto treci a provozni rychlost by byla treba 100km/h
na silnici by byl ozub aby to neklouzalo

takhle nejak zjednodusene by vypadal svet bez akceleraci, tedy rampovani
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
Hades
Příspěvky: 1206
Registrován: 11. 10. 2012, 10:59
Bydliště: Praha; Mimoň

8. 7. 2014, 9:02

Mex píše:
Hades píše:Kopni do mne s tou akcelerací, nějak mi google nic nevrací, ale asi jen neumím položit ten správný dotaz...Diky
Buď si děláš srandu, nebo máš pokaženého Googla, že ti nic nevrátí na akceleraci (nebo rampu).
super, to je vono... rampa.... díkes...
njn, já to říkám pořád, hlavní jsou ty keywords...
teensy
Příspěvky: 8
Registrován: 29. 6. 2014, 7:19

11. 7. 2014, 6:52

s knihovnou inpout32.dll + .NET jsem taky začínal, brzo zjistíš, že v .NET se jenou za čas probudí garbage collector a tvé vlákno se nedostane ke slovu po dobu desítek stepů o které tak přijdeš. Mne se také motor točil. Ale dej si na rotor značku, spusť program, který hodně plynule zrychlí na maximum a zase hodně plynule zastaví v téže poloze. Pak se znovu podívej na značku.

proto jsem nejprve switchnul do C++ a nastavil proces na high-priority. Nic naplat, ve Windows nemá proces zaručeno, že se ke slovu dostane častěji než jednou za 15 ms (time slice). Proto jsem si napsal kernel mode driver, kterým jsem si na čtyřjádru přivlastnil jedno celé jádro pro sebe a čtením instrukce rdtsc v cyklu kontroloval že se s nikým nedělím o strojový čas (instrukce vrací hodnotu registru ve kterém si každé jádro zvlášť počítá počet taktů od okamžiku spuštění - mám základní takt 2,4 GHz a v biosu zakázané automatické úpravy frekvence - na rdtsc staví např. API funkce QueryPerformanceFrequency). Zjištění mne překvapilo, beztak jsem čas od času zaspal klidně 100 tis. taktů. Takto dlouho trvají některé obslužné rutiny interruptů, které jádro kromě mého procesu čas od času obsloužilo. Proto jsem ještě mému jádru disabloval interupty a pak už jsem preiodicky ztrácel "jen" stovky taktů, což šlo na úkor HW záležitostí jako je např. flush chache a pod. To už by bylo z hlediska potřeb mého časování naprosto dostačující, ale byl jsem tím dost otrávený (mám 64-bit Windows 7, které vyžadují podpis driveru a jiné překážky) že jsem hledal jiné řešení.

Zajímal jsem se o to, jak to dělají profesionální programy. Dočetl jsem se dva zajímavé principy:

využívají DMA přenost z paměti na LPT port, takže přenost není řízený procesorem, ale hardwarem, který ničím nerušen stále stejnou frekvencí bere místo ve fyzické paměti, přenese ho na jiné místo v paměti (kam je namapovaný LPT port) a zvětší zdrojovou adresu, zatímco cílová zůstává stejná. Toto se opakuje nezměněnou rychlostí, která je řádově vyšší než frekvence pulzů pro motor. V paměti to pak vypadá tak, že je za sebou třeba 100 bytů stejných, takže při jejich přehazování na LPT se výstupní signál nemění, dalších 100 bytů má hodnotu jinou. Pokud chci frekvenci o něco vyšší, zkracuji nebo prodlužuji počty stejných bytů. Pokud je žádaná frekvence mezi 100 a 101 byty, tak to střídám, motor to ani nepozná, odchylka od správného časování je pouze setina fáze jednoho kroku. Programu pak nevadí nepravidelnosti běhu, protože s velkým předstihem donaplňuje data do cyklického bufferu po kterém DMA s ničím nerušenou pravidelností roluje.

jiné programy používají mutilemdia timer, což je HW časovač, který umí vyvolat interupt s pravidelnou periodou a nebo po při dosažení nastaveného počtu. Programy druhou možnost nevyužívají, nechají timer tikat s pravidelnou periodou, která je řádově vyšší než maximální frekvence půlsů pro motor. V obslužné rutině navěšené na interupt z timeru program akorát zkontroluje za již nastal čas pro další puls pro motor, pokud ne, provede kontrolu znovu při dalším přerušení.

Já jsem šel úplně jinou třetí cestou, ale to si nechám na příště jsem už upsaný :)
oscar
Příspěvky: 1190
Registrován: 2. 5. 2010, 8:50
Bydliště: Perníkovice

11. 7. 2014, 6:55

to zni zajimave... ne ze bych se do toho poustel, ale rad se priucim kudy ne :D
teensy
Příspěvky: 8
Registrován: 29. 6. 2014, 7:19

12. 7. 2014, 11:00

cesta, kterou jsem si zvolil já, stojí 520 Kč:

http://www.pvelectronic.eu/arduino/teen ... ensy%203.1" onclick="window.open(this.href);return false;

je to 32-bit mikrokontroler, programovaný v C++ přes USB. Jeho Windows driver se tváří jako sériový port, nicméně přenos probíhá bez ohledu na nastavení baudů s plnou rychlostí USB 2.0 (1 MB/s v obou směrech).

To ocení .NET pozitivní, protože k sériovému portu se (na rozdíl od paralelního) dostanou přes System.IO.Ports.SerialPort.

Teensy má 34 vstupně/výstupních pinů, které lze různě nakonfigurovat (digitální/analogový,vstupní/vsupní) a používat je ve stejném významu jako piny paralelního portu (t.j. STEP, DIR, ENA, apod). Kromě toho lze využít vestavěných DA/AD převodníků a snímat třeba teplotu vřetene.

Dovedy si představit, že by Teensy mohl fungovat jako interpreter GC kódu. Ale přesně to jsem nechtěl. Až svůj projekt dokončím, jednou ho zde popíšu. Já potřebuji mít nad motory úplnou kontrolu přímo z aplikace.

Teensy používám víceméně jako přesné stopky, které do driveru pošlou signál STEP přesně v požadovaný okamžik a na rozdíl od aplikace ho nepropásnou. Časování pulzů počítám na straně PC a do Teensy posílám níže uvedený proud dat (binárně, zde pro názornost textem):

čas step
00000000001 x+
00000000203 x+
00000000300 x+
00000000320 Y-
00000000400 x+

Teensy si to cachuje v paměti (jeho 64kB pojme data na 0.1 sekundy provozu dopředu). Údaj v prvním sloupci říká "až tvůj clock-counter register dosáhne tého hodnoty, vygeneruj step v zadané ose a směru". No a protože hodiny Teensyho tikají na základním taktu 72 Mhz, bavíme se zde o přesnosti časování lepší než 1e-7 sekundy.

Pokud teensy zjistí problém (např. ztrátu kroku díky zpětné vazbě), vrací aplikaci informací o pozici pulzu identifikovanou hodnotou ve sloupci čas. No a protože si předané hodnoty na straně PC ukládám, mohu se pak v té sekvenci okolo chybného místa rýpat a hledat chybu v mém časovacím algoritmu (nic pro praktický provoz :)

Ano, je to zbytečně přesné, ale účelem bylo osovobodit aplikaci od real-time problémů, kdy i milisekndové zaškobrtnutí v dodávce dat na LPT port mohlo znamenat problém. To že je výsledkem až takto přesné časování a aplikace může zaspat klidně i 100 ms, beru jako výhodu.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

12. 7. 2014, 11:17

Paráda.
Stejnou cestou šel před časem kámoš, bývalý člen tohoto fóra. Používal na to ale desku STM32F4 Discovery, která je velmi levná (cena ještě nižší než to Teensy), jede na 168 MHz a hlavně má hodně paměti RAM (192 KiB).
Dělal to taky tak, že mu to Discovery dělalo vpodstatě jen inteligentní a přesně časovaný "posuvný registr", trajektorii a vše ostatní předpočítával nadřízeny systém.
Chvilku jsem se tím s ním taky zabýval. Nakonec jsme to odložili proto, že jsme neměli dostatečné znalosti na to, jak to napojit na LinuxCNC, což bylo cílem. Vpodstatě šlo o to, aby LinuxCNC mohl jet i na mašině s velkou latencí, protože přesné časování by dělala tahle levná externí krabička, připojená přes USB/serial/Ethernet.
Odpovědět

Zpět na „Krokové motory“