Arduino steruje ploterem.

Ewentualnie pomysł na szybko jak zrobić w prosty sposób rampę - ale zależny od taktowania UC.

Startując od zera możesz dodawać nop'y spowalniając kolejne kroki, i zmniejszać liczbę nop'ów aż do uzyskania pełnej prędkości gdy w ogóle nie dajesz nop'ów.

Przy hamowaniu tak samo - w ten sposób liczba kroków i odległość będzie taka sama, zmieni się czas wykonania.

Zastanów się nad jeszcze jedną rzeczą - używasz w kodzie typu float, najczęściej niestety jest to morderca wydajności...

Znacznie szybciej można obsłużyć int odpowiednio przemnożony (np. 1000 razy) dla wystarczającej dokładności obliczeń.

Zienek pisze:Interpreter jeszcze na komputerze to może być dobry pomysł.
Z komputera do kontrolera przychodziły by instrukcje nie w formie gkodu, a ilości kroków do wykonania dla każdej osi w danym interwale czasowym i ich zwroty.
Np. teraz przez 100ms:
X+ 50 kroków
Y- 25 kroków
Z+ 10kroków.
Wtedy sterownik ustawiłby polaryzację dla DIR, oraz:
co drugą milisekundę sterownik 'pikałby' na plus dla STEP X,
co czwartą na minus dla STEP Y
co dziesiątą dla STEP Z.

Podział kroków tak samo jak u mnie. z tym ze u mnie jest szybciej. Bo toz max prędkością jaką procesor poda. Ni ma obsługi Dir bo zsterownik silnika jest na l293. Ale użycie Dir mocno upraszcza kod.

mam ciekawy pomysł - dla ARM-arduino (due)
może przenieść trochę oprogramowania z linuxnc (emc2) do wnętrza uC
tj. stworzyć dwa wątki - szybki i wolny
szybki wątek odpowiada za generowanie impulsów --- gotowy kod - to stepgen
wolny watek odsługuje równe statystyki... odpowiada za obsługę kolejki napływających gcodów (interpreter gcodów można by zassać również linuxcnc)

oczywiście wszystko bez systemu operacyjnego... jedynie trzeba zaprogramować dwa timera do obsługi wątków..

Zienek pisze: Np. teraz przez 100ms:
X+ 50 kroków
Y- 25 kroków
Z+ 10kroków.
Wtedy sterownik ustawiłby polaryzację dla DIR, oraz:
co drugą milisekundę sterownik 'pikałby' na plus dla STEP X,
co czwartą na minus dla STEP Y
co dziesiątą dla STEP Z.

He he A jak obliczysz:
X23 Y17 Z7
Hi hi hi

Ja bym pomyślał o jakiejś luźnej interpretacji algorytmu Bresenhama.
Z tym, że nie do rysowania linii (przestrzeń x,y), tylko do znajdowania najodpowiedniejszego kwantu w czasie (przestrzeń f,t).

Do przemyślenia.

Algorytm Bresenhama szczególnie się nadaje do sterowania ploterami,
po to został wymyślony:
"J. E. Bresenham. Algorithm for computer control of a digital plotter"

Najważniejsze, że działa na liczbach całkowitych - jest szybki i prosty.

Pewną wadę stanowi to, że w wersji bazowej ilość obliczeń zmienia się
w zależności od kierunku kroków.

Ja wymyśliłem coś innego.

if (STEP_X > STEP_Y){
A_1 = STEP_X / STEP_Y ;
float A = STEP_X / STEP_Y ;
if (A_1 < A) { A_1 = A_1 + 1 ; }
r = STEP_Y - (STEP_X/A_1);
if ( r > 0){ A_2 = STEP_X / r ;
r = STEP_Y - (STEP_X/A_1) - (STEP_X/A_2) ;}
if ( r > 0){
A_3 = STEP_X / r ;
}
a = A_1 ;b = A_2 ; c = A_3;

Na "piechotę" to jest tak:
X =23 Y = 17
A_1 = int (23/17) = 1,35 zaokraglam do dwóch. Zawsze zaokrąglam w góre gdy nie wychodzi wartość całkowita.
Reszta = 17 - (23/2) = 6
A_2 = (23/6) = 3,8 zaokraglam w górę czyli 4
Reszta = 17- int(23/2)- int(23/4)
Reszta = 17 - 11 - 5 = 1
A_3 = 23/1 = 23
Czyli co A_1 , A_2 , A_3 Wystąp.
X leci od 1 do 23, a Y co drugi, co czwarty i co dwudziestytrzeci krok...
1| Pierszy krok nic
2|_ co drugi czyli 1Y razem jeden
3 | nic
4 |__ Co drugi i co czwarty czyli 2Y razem trzy
5 | Piąty nic
6 |_ szósty co drugi czyli 1Y razem cztery
7 | siódmy nic
8 |_ _ Ósmy co dwa i co cztery czyli 2Y razem sześć
9 | nic
10 |_ co drugi czyli 1Y razem siedem
11 | nic
12 |_ Co drugi i co czwarty czyli 2Y razem dziewięć
13 | nic
14 |_ co drugi czyli 1Y razem dziesięć.
15 | nic
16 |__co drugi i co czwarty czyli 2Y razem dwanaście
17 | nic
18 |__ co drugi czyli 1Y razem trzynaście
19 |nic
20 |_ _co drugi i co czwarty czyli 2Y razem piętnaście
21 | nic
22 |_ co drugi czyli 1Y razem szesnaście
23 |_ co dwudziesty trzeci razem 1Y czyli siedemnaście.

I podobnie dla osi "Z" i gotowe.
I ciekawe, wystarczy trzy razy podzielić i każda liczba dzieli się przez każdą.

baxter12 pisze:Ja wymyśliłem coś innego.

Warto takie przeliczenia zrobić sobie w arkuszu kalkulacyjnym zadając odpowiednie ruchy i policzyć czasy, drogi, przyspieszenia - wtedy będzie widać czy pomysł tego dzielenia jest coś wart. Względem braku rampy być może tak.

Ewentualnie można słuchać ja działają silnik, nagrać filmik i nam tu pokazać.

Jeden z Kolegów z forum pytał mnie czy udał mi się wymyślić algorytm obliczenia ruchów przy cięciu okręgu.
Chciałem sie oprzeć na Równaniu okręgu w płaszczyźnie kartezjańskiej.
I tak na szybko wymyśliłem coś takiego:
r0wnanie okręgu tak na szybko, to w zasadzie równanie boków trójkąta prostokątnego.
tak więc dla pierwszej ćwiartki algorytm będzie wyglądał tak:
(przepraszam że w zapisie Basicowym, ale tak jakoś mi najłatwiej)
For a= np. 01 (zależnie od założonej dokładności obliczeń)
to "r" step 0.1
b= pierwiastek (a kwadrat - b kwadrat).
next "a"
I to na początek.
Trza to rozpisać na 4 ćwiartki.
Trza to zaopatrzyć w możliwość rysowania łuków dowolnej długości, np. przez dopisanie algorytmu porównywania obliczonej wartości "a" z wartością "a' docelowego punktu.
To tyle.

Ja od niedawna też zacząłem się bawić Arduino i mam takie pytanie odnośnie sterowania silnikami krokowymi. Czy jest możliwość ciągłej pracy silnika krokowego ? Silnik obraca się po przyciśnięci przycisku do momentu jego zwolnienia, a nie przesuwa się o zadaną ilość kroków ?
I drugie pytanie czy istnieje możliwość zatrzymania silnika w trakcie wykonywania obrotu o zadaną ilość kroków ? jeśli tak to jakim poleceniem ?