RAMPA na ARDUINO

EDIT: (Doczytałem wątek z poprzedniej strony)

(ciach)
No i co do ARMów to chyba warto poczekać na Raspberry PI - za ok 25$ układ z nowoczesnym ARMem 11 i możliwością wyświetlania obrazu w HD poprzez złącze HDMI. Ale na to pójdzie nam poczekać do wakacji, a poza tym zastosowanie tego do rampy na Arduino to strzelanei z ARMaty do motyli

PS:
Ja mam http://www.propox.com/products/t_232.html MMNet1002 z Propoxa, ale nie wiem o co chodzi, że teraz ta płytka jest o wiele droższa niż 2 czy trzy lata temu. Tu siedzi ARM AT91SAM9260.

PS2:
Co do tego modułu z Allegro, to zadziwiło mnie, że już tak tanio można to kupić. 90zł z przesyłką układ ARM z rodzinny v6 z debuggerem. http://allegro.pl/stm32-stm32f4-discove ... 92584.html
Gdybym nie miał tego Propox'a to też chętnie wciągnąłbym ten produkt.

Zienek pisze:http://www.propox.com/products/t_232.html

fajna "płyta główna"
ma wszystko do eksperymentów do kontroli więcje niż jednej osi... i to chyba mozna by całę EMC2 (linuxcnc) na tym odpalić...

miło będzie zobaczyć opis połączenia i obrazki/filmiki z eksperymentów...

warto było by opracować metodologię kontroli wyników pracy...

mi przyszedł do głowy taki prosty sposób:
-silnik krokowy podłączony do przez sterownika do układu prototypowego z ARM lub AVR z programem rampy i oscylatorem...
-oś badanego silnika podłączona do śruby napędzającej oś frezarki - a drugi koniec śruby ma na sobie enkoder (można oczywiście podłączyć enkoder bezpośrednio na osi silnika)... ja mam na drugim końcu serwo z enkoderem - więc enkoder mogę zastosować do odczytu pozycji...

Celem tego eksperymentu jest zaobserwowanie realnego wykresu rampy - jako odczyt z enkodera...

Można to zrobić na wiele sposobów.. dwa mi przychodzą do głowy:
1. odczyt wskazań enkodera wraz z jakimś wskaźnikiem czasu... i... i narysowanie wykresu na podstawie odczytanych danych (np. w arkuszu kalkulacyjnym)

2. rysowanie wykresu na ekranie oscyloskopu w czasie rzeczywistym... do tego wystarczy przetwornik częstotliwość/napięcie (częstotliwość sygnału z enkodera jest proporcjonalna do prędkości chwilowej)
taki moduł jest dość prosty w realizacji -- np. w akcesoriach występuje jako moduł sterowania falownikiem 0-10V... trzeba by tylko zmniejszyć stałą czasową na wyjściu


wersja 2) jest wygodniejsza -- bo rejestrator wykresu pracuje w czasie rzeczywistym... a jeśli oscyloskop jest cyfrakiem - to pojawiają się jeszcze możliwości przetwarzania przychodzących danych...

Zienek pisze: PS:
Ja mam http://www.propox.com/products/t_232.html MMNet1002 z Propoxa, ale nie wiem o co chodzi, że teraz ta płytka jest o wiele droższa niż 2 czy trzy lata temu. Tu siedzi ARM AT91SAM9260.

PS2:
Co do tego modułu z Allegro, to zadziwiło mnie, że już tak tanio można to kupić. 90zł z przesyłką układ ARM z rodzinny v6 z debuggerem. http://allegro.pl/stm32-stm32f4-discove ... 92584.html
Gdybym nie miał tego Propox'a to też chętnie wciągnąłbym ten produkt.

ARM9/ARM926 jest starszym i nieco trudniejszym w opanowaniu układem - dla początkujących Cortex jest bardziej strawny.

Ten moduł z Allegro jest tak tani, bo STM traktuje go jako gadżet reklamowy swojej nowej rodziny procków i sprzedaje po kosztach.

[ Dodano: 2012-04-15, 13:39 ]

markcomp77 pisze:EMC2 (linuxcnc) na tym odpalić...

Nie widziałem RTAI dla Armów ( ostatnio chyba ktoś grzebał ale nie wiem czy skończył). Poza tym wtedy skłaniam się już jednak do PC'ta.

jarekk pisze:Nie widziałem RTAI dla Armów

musi wreszcie zostać to zrobione --- jest ktoś chętny?

markcomp77 pisze:

jarekk pisze:Nie widziałem RTAI dla Armów

musi wreszcie zostać to zrobione --- jest ktoś chętny?

Na tym forum ludzie się pytają że jak mają sterownik z komputera, to co jeszcze potrzebują, żeby silnik się kręcił, a wy pytacie o RTOS'y ...

markcomp77 pisze: mi przyszedł do głowy taki prosty sposób:

A ja dwa dni temu myślałem, żeby zaproponować budowę stanowiska pomiarowego ale se pomyślałem "e tam, wyśmieją za zbytnie komplikowanie problemu", ale cóż widzę, że w tym kierunku to brnie.
Swoją drogą śni mi się po nocach od dawna stanowisko do badania charakterystyk krokowców/serw.

Pozdrawiam,
GSM

GSM pisze:

markcomp77 pisze:

mi przyszedł do głowy taki prosty sposób:

A ja dwa dni temu myślałem, żeby zaproponować budowę stanowiska pomiarowego ale se pomyślałem "e tam, wyśmieją za zbytnie komplikowanie problemu", ale cóż widzę, że w tym kierunku to brnie.

Heh... ten temat wypączkował z https://www.cnc.info.pl/topics65/silnik ... t35539.htm więc pewnie nie raz dyskusje będą się stykać, teraz należałoby dołączyć do rozważań trzeci : https://www.cnc.info.pl/topics14/dro-dl ... t35312.htm ,przy okazji wyjdzie jak szybko można "kręcić korbką" .

Tak czytam ten Leibramp.pdf i chodzi mi po głowie poskładanie arkusza albo skryptu Octave, żeby zobaczyć naocznie jak to się zmienia i być może wygenerować tablicę dla 8-bitowców - bo co racja to racja - trybu float to one nie lubią. Ktoś mógłby porównać w avr-gcc coś takiego: dla float i byte?
Mam nadzieję, że gcc w przelocie produkuje assembler?
I czy długość obu programów [asm] jest podobna?

Yogi_ pisze:I czy długość obu programów [asm] jest podobna?

Porównywanie float i byte to jak porównywanie piły spalinowej i noża elektrycznego do mięsa, chyba że ogólnie chodzi o zmienne bez przecinków.
Tak czy inaczej nie mam co porównywać, wynik jest jasny.
Jak uda mi się uruchomić GCC tutaj (małe problemy z komputerem) to zaraz sprawdzę dokładnie.
A tak apropos DRO, niech kolega się nie martwi. Zliczanie impulsów z enkodera w przerwaniu(-ach) zrealizować można (wręcz należy) na liczbach całkowitych. Wyświetlanie zaś i przeliczanie pozycji (w wątku głównym) może być na floatach, odświeżanie ekranu (nie mówi o częstotliwości multipleksowania tylko o odświeżaniu danych) na poziomie 10 razy a sekundę wystarczy i float wtedy nie zatka mikrokontrolerka.

Pozdrawiam,
GSM

markcomp77 pisze:mi przyszedł do głowy taki prosty sposób:

Osobiście zakończył bym projekt na "-------śruba--------" z prostej przyczyny. Jeśli po wykonaniu ruchu przeciwnego oś wróci na tą samą pozycję, to niczego nie trzeba sprawdzać (zakładam, że programista wie co napisał)

GSM pisze:A tak apropos DRO, niech kolega się nie martwi. Zliczanie impulsów z enkodera w przerwaniu(-ach) zrealizować można (wręcz należy) na liczbach całkowitych.

Tu akurat kolega się nie martwi. Chodziło mi o kolejny zazębiający się temat.
Bardziej tym: Całość http://hwml.com/LeibRamp.pdf .
Ośmiobitowego procka może to zaboleć I ten "variable delay period" bym stablicował, w zależności od ilości (bo na tę chwilę nie mam pojęcia) albo w programie albo wepchał do eeproma.