Spoko pomyslalem na skróty. "nie chce sterować" rozum jako "nie chce sterować tak jak zwykle steruje się krokowcem". To co on chce zrobić ja (używając znów skrótu myslowego) potraktowalem jako zasilić silnik krokowy aby zaczął się kręcić. A nie sterować.
Tak więc zgadzamy się ale o tym dotychczas nie wiedzieliśmy. .
A niez tymi inżynierami nie kumam, bo ja wiedzę na tajnych kompletach zdobywam.
Pozdrawiam

markcomp77 pisze:PWM też może być dla krokowca, ale....
ale przy tzw. sterowaniu napięciowym, które wymaga wyliczania wartości siły elektromotorycznej silnika (czyli znajomości Ka - współczynnika prądnicowego)

Racja, ale chłopakowi nie chodzi o sterowanie. Ma sie kręcić, a potem zatrzymać. Czy tam ruszyć.

Można to zrobić, ale nie korzystając z polecenia STEP . Należy wysterowac piny.

Kurze mało sie znam, a ludzie mnie pytają. Fajnie.

EDIT
Można by jeszcze użyć PWM i ew komendy Tune do regulacji częstotliwości.

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

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

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.

ezbig pisze: Ja kiedyś programowałem dużo w asemblerze. Co prawda było to ze 20 lat temu na Atari 65XE.

Hmm. Wtedy Amiga była moją miłością. Na Amosie cały program do obsługi firmy popełniłem. Dla nieobznajomionych, to był taki Basic który sie potem kompilowało..
Jestem stary dobry rocznik 1963.. he he he na "kalejdoskopie Techniki" wychowany..

Nie myśl EZBIG że poczułem sie urażony, daleko mi do tego. Jestem dumny z tego choćby że mój program "wygenerował" 3 strony postów. I to na tak poważnym forum. Wiele mi pomogliście.
Zauwazyłes jak rozliczam kroki.
czy opłaca się dopisać trochę kodu, aby te kroki były stopniowo coraz szybsze?
Czy trza by było napisać od nowa, aby rozliczac kroki odległościowo?
Z tym że arduino ma ograniczenie.
Komenta stepper step zamraża procesor. Wiec "klasyczna " rampe można by było zastosowac, w prosty sposób, tylko do ruchu w jednej płaszczyźnie. Lub sterować silnikami "na piechotę" wysyłając sygnały do portów. Ale czy to ma sens? Biorąc pod uwagę możliwości obliczeniowe Atmegi?
Może zakończyć rozbudowe programu o krańcówki. I już. Cudów chyba się z tego prcesorka nie wykrzesa.

[ Dodano: 2013-09-09, 22:37 ]

Zienek pisze:Interpreter jeszcze na komputerze to może być dobry pomysł.

Chciałem to zrobic na Processingu. Nie umiałem bo:
Processin nie ma komend odczytu z pliku linia po linii.
Wczytuje cały plik i przy dużym pliku blokuje kompa na kilka minut.
A potem nie ma komend aby rozebrac plik tekstowy, linia po linii, albo aby odszukać znak i zwrócic jego miejsce w ciągu.
Zwróc uwagę jak prostacko mam rozwiazany odczyt danych z seriala, tak umiałem, tak zrobiłem. cały czas się obawiałem czy Atmega da sobie rade z obliczeniami. zdawłem sobie sprawę ŻE NIE DA SOBIE RADY, no bo niby dlaczego WSZYSCY przenosza obliczenia do kompa?

Przepraszam że post pod postem.

Raven pisze:Rozpędzanie się i hamowanie osi jest trochę bardziej skomplikowane - nie możesz tego liczyć na krokach a na odległości do pokonania.

Ano właśnie, w moim programie zdaje sie nie ma to racji bytu. Myślałem nad rozliczaniem kroków za pomocą zmiennej prędkości silnika, ale zarzuciłem to dla rozliczania krokowego.