RAMPA na ARDUINO

Zienek · Post napisał: **Zienek** » 15 kwie 2012, 11:32

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.

markcomp77 · Post napisał: **markcomp77** » 15 kwie 2012, 13:36

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:

Kod: Zaznacz cały


OSCYLATOR|---|STER|---|SILNIK KROKOWY|-------śruba--------|SERVO|---|ENKODER|---ABZ

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

jarekk · Post napisał: **jarekk** » 15 kwie 2012, 13:38

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.

markcomp77 · Post napisał: **markcomp77** » 15 kwie 2012, 13:44

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

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

Zienek · Post napisał: **Zienek** » 15 kwie 2012, 21:29

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

GSM · Post napisał: **GSM** » 15 kwie 2012, 21:48

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

Yogi_ · Post napisał: **Yogi_** » 15 kwie 2012, 22:13

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:

Kod: Zaznacz cały

a = 16
b = 32
c = a/b

dla float i byte?
Mam nadzieję, że gcc w przelocie produkuje assembler?
I czy długość obu programów [asm] jest podobna?

GSM · Post napisał: **GSM** » 15 kwie 2012, 22:23

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

Leoo · Post napisał: **Leoo** » 15 kwie 2012, 23:43

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ł)

Yogi_ · Post napisał: **Yogi_** » 15 kwie 2012, 23:52

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:

Kod: Zaznacz cały

4. Implementation
The given parameters are: 
v0 - base speed,
v - slew speed,
a - acceleration,
F - timer frequency

and the calculated parameters are: 
S - acceleration/deceleration distance
S = (v2 - v02) / (2 . a)  [4, 16] 
p1 - delay period for the initial step
p1 = F / (v02 + 2 . a)^1/2 [17],
pS - delay period for the slew speed steps
pS = F / v [18],
R - constant multiplier
R = a / F2 [19].
The variable delay period p (initially p = p1) that will be recalculated for
each next step is: 
p = p . (1 + m . p . p) [20].
where
m - variable multiplier that depends on the movement phase: 
m = -R during acceleration phase,
m = 0 between acceleration and deceleration phases,
m = R during deceleration phase.
For accuracy purpose let's set
p = pS if p < pS or between acceleration and deceleration phases,
p = p1 if p > p1 .

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.

RAMPA na ARDUINO

Łańcuch rolkowy 06B-1 (3/8") Tsubaki 500mm

Bit Standard, płaski, C 6.3, 0.8 x 5.5 WIHA

RAMPA na ARDUINO

Łańcuch rolkowy 06B-1 (3/8") Tsubaki 500mm

Bit Standard, płaski, C 6.3, 0.8 x 5.5 WIHA

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej