[AVR GCC Kurs2] Stepper-Interface

**TiPpFeHlEr** · August 17, 2008 at 3:00 PM

also so ??

void check_step(void)
{
if (X.State &(1<<NXT))
{
PORTA |= (1<<PA6);
X.State &= ~(1<<NXT);
check_accel(&X, Xtarget);
PORTA &= ~(1<<PA6);
}

if (Y.State &(1<<NXT))
{
PORTA |= (1<<PA4);
Y.State &= ~(1<<NXT);
check_accel(&Y, Ytarget);
PORTA &= ~(1<<PA4);
}
}

**TiPpFeHlEr** · August 17, 2008 at 3:01 PM

so nun kommen keine fehler mehr!!

mfg maik

Hendrik Hölscher · August 17, 2008 at 3:07 PM

Jaaa - aber die Richtung ist derzeit auch futsch.

Ich denke, wir gehen den einfachten Weg und prüfen die Speeds auf positive oder negative Werte und setzen die Geschwindigkeit entsprechend.

Abgesehen davon ist auch noch ein Denkfehler bei den Steps...
(Derzeit halten wir nicht an.)

Nicht wirklich schön aber richtig wäre somit:

Code

if (X.State &(1<<NXT))
	{
	check_accel(&X, Xtarget);
	if (X.Speed > 0)
		{
		PORTA |= (1<<PA6); //Schritt
		PORTA |= (1<<PA?);  //pos. Richtung
		}
	else if (X.Speed < 0)
		{
		PORTA |= (1<<PA6);
		PORTA &= ~(1<<PA?); //neg. Richtung
		}
	X.State &=  ~(1<<NXT);
	PORTA &= ~(1<<PA6);
	}

Display More

**TiPpFeHlEr** · August 17, 2008 at 3:12 PM

öhmm... ok

und wie??

also anhalten sollte er schon sonnst sind die kabel bald zu kurz und reissen

mfg maik

Hendrik Hölscher · August 17, 2008 at 3:16 PM

Yep:

Deswegen schau mal oben, was bei einer Speed von 0 passiert...

Fehlt nur noch die Skalierung der Sollwinkel auf 16it:

DMXsoll= ch1*255+ch2
WinkelSoll= (DmxSoll*MaxSchritte)/2^16

Da "*255" einem Linksschieben um 8bit entspricht (Val<<8)
und einem Teieln durch 2^16 ein Rechtsschieben um 16bit
(Val>>16)

Funktioniert so etwas mit:

Code

uint32_t tmp= ((uint32_t)DmxField[0]<<8) +(uint32_t)DmxField[1];
tmp= ((tmp * X.Max)>>16);
Xtarget= tmp;

Das (uint32_t) ist ein sogenannter TypeCast:
Damit werden die Daten von DmxField auf 32bit aufgeblasen, damit es bei der späteren Multiplikation nicht zu Überläufen kommt.

**TiPpFeHlEr** · August 17, 2008 at 3:19 PM

also so

void check_step(void)
{
if (X.State &(1<<NXT))
{
check_accel(&X, Xtarget);
if (X.Speed > 0)
{
PORTA |= (1<<PA6); //Schritt
PORTA |= (1<<PA7); //pos. Richtung
}
else if (X.Speed < 0)
{
PORTA |= (1<<PA6);
PORTA &= ~(1<<PA7); //neg. Richtung
}
X.State &= ~(1<<NXT);
PORTA &= ~(1<<PA6);
}

if (Y.State &(1<<NXT))
{
check_accel(&Y, Ytarget);
if (Y.Speed > 0)
{
PORTA |= (1<<PA4); //Schritt
PORTA |= (1<<PA5); //pos. Richtung
}
else if (Y.Speed < 0)
{
PORTA |= (1<<PA4);
PORTA &= ~(1<<PA5); //neg. Richtung
}
Y.State &= ~(1<<NXT);
PORTA &= ~(1<<PA4);
}
}

**TiPpFeHlEr** · August 17, 2008 at 3:20 PM

oben passiert bei speed 0 --- nix, besser gesagt er führt den letzten befehl aus
hab ich aber auch überhaupt nicht gesehen:D

mfg maik

Hendrik Hölscher · August 17, 2008 at 3:29 PM

Fehlt nur noch die Skalierung der Sollwinkel auf 16it in der DMX-Auswertung:

DMXsoll= ch1*255+ch2
WinkelSoll= (DmxSoll*MaxSchritte)/2^16

Da "*255" einem Linksschieben um 8bit entspricht (Val<<
und einem Teieln durch 2^16 ein Rechtsschieben um 16bit
(Val>>16)

Funktioniert so etwas mit:

Code

uint32_t tmp= ((uint32_t)DmxField[0]<<8) +(uint32_t)DmxField[1];
tmp= ((tmp * X.Max)>>16);
Xtarget= tmp;

Das (uint32_t) ist ein sogenannter TypeCast:
Damit werden die Daten von DmxField auf 32bit aufgeblasen, damit es bei der späteren Multiplikation nicht zu Überläufen kommt.

**TiPpFeHlEr** · August 17, 2008 at 3:34 PM

ok jetze gings mir zu schnell8o

wir sind also mit dem stepper fertsch??
und kommen nun zur dmx auswertung??

hab dann nämlich noch ne frage zur rampe. wie lang ist sie im moment??

mfg maik

Hendrik Hölscher · August 17, 2008 at 3:57 PM

Die Rampe dürfte 50 Einträge haben.

Anbei die ganze Geschichte.

**TiPpFeHlEr** · August 17, 2008 at 4:03 PM

hmm... was heist 50 einträge ??
wieviele steps sind das oder wieviele msec???
weil der mh eine sehr grosse rampe braucht.

hatte mal getestet bei 600hz takt braucht er je. ca 400msec von 0Hz auf 600Hz und wieder von 600Hz auf 0Hz damit lief er sehr gut.

mfg maik

**TiPpFeHlEr** · August 17, 2008 at 4:07 PM

ebenso ist für mich noch nicht klar wie schnell der motor nun laufen würde?
oder wie langsam??

mfg maik

**TiPpFeHlEr** · August 17, 2008 at 5:27 PM

so habe aus dem code mal ne *.hex gemacht und auf den atmel geladen.

sieht noch nicht gut aus, meine dmx led am transceiver blinkt??im gleichen takt wie led1 von hennes transceiver. ebenso der stepper, summt im takt der led's.

hab also erstmal ausgemacht und nicht weiter getestet.

mal schaun wann henne wieder da ist:D

mfg maik

Hendrik Hölscher · August 17, 2008 at 5:27 PM

Bei 50Einträgen geht die Rampe über 50Steps.

Die Endgeschwindigkeit ist abhängig von dem von Dir gewählten Beschleunigungsfaktor und der Tabellengröße.

Viele Grüße,
Hendrik

Die Tabelle hatte ich mit Matlab erzeugt. Ich versuche mal, die Formel zu finden...

**TiPpFeHlEr** · August 17, 2008 at 5:31 PM

oha

da müssen aber ein paar mehr steps her
und die tabelle muss grösser werden

soll ja nich rucke beim anfahren oder bremsen

mfg maik

Hendrik Hölscher · August 17, 2008 at 6:02 PM

anbei das Matlab-Script:

Code

%acceleration ramp for stepper control
clear all
clc


disp('parameters:');
clock= 8e6              %crystal frequency [Hz]
prescaler= 8            %prescaler of Timer
steps= 200              %motor steps for one revolution
microsteps= 16          %microstepping factor
accel= 400              %acceleration [U/s^2]
table_size= 50


alpha= 1/(steps*microsteps);
tick= prescaler/clock;


c_o= (sqrt(2*alpha/accel))/tick
lines= 1;
cols= 1;
for i=1:table_size
    c= c_o*(sqrt(i+1) -sqrt(i));
    if (cols > 16)
        cols= 1;
        lines= lines+1;
    end
    table(lines, cols)= round(c);
    graph(i)= round(c);
    cols= cols +1;
end
plot(graph)


fid = fopen('C:\eigene Programme\Rev3_0\StepperPos\table.txt','w');         %Pfad, wo Tabelle abgespeichert wird.
for i=1:size(table,1)
   fprintf(fid,'%d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d,  %d, \r\n',table(i,:));
end
fclose(fid);

Display More

Die Formeln zur Berechnung stammen aus einer Application Note von ATMEL. (Ich glaube es war die linear speed control...)

**TiPpFeHlEr** · August 17, 2008 at 7:31 PM

ich habe da auch was gefunden

zum thema rampe:
[url=http://www.fernando-heitor.de/component/opti…pic,469.msg2149]http://www.fernando-heitor.de/component/opti…pic,469.msg2149[/url]

eine berechnung der werte im atmel ?? geht das von der rechen zeit her??
so ähnlich hatte ich mir das auch gedacht, das er einfach bei jedem schritt die frequenz um einen bestimmten wert erhöht oder verringert.

wenn die rampe also 100 steps lang ist , und bei jedem step um 5 Hz erhöht wird, kommt mann von 0 auf 500 hz in 100 steps.
das wäre natürlich linear.

mfg maik

Hendrik Hölscher · August 17, 2008 at 7:39 PM

Da Du in einem AVR mit Wurzeln, Brüchen und trigonometrischen Funktionen nicht weit kommst, macht man sowas mit Lookup Tables.

meine Quelle und mein Script dafür habe ich Dir gegeben.

**TiPpFeHlEr** · August 17, 2008 at 8:10 PM

also die Application Note von ATMEL habe ich gefunden.

aber ich habe kein matlab. auch ein download der trialversion davon ist fehlgeschlagen.

oki lassen wir de rampe erstmal weg
wie gehts weiter, habe eine hex file erzeugt mit winavr, aus der make-file von avrstudio.
habe diese nun mit ponyprog übertragen. sie geht aber nicht!!
die rote led (led1) blinkt, der motor summt im takt dazu, und auch die dmx-led meines interfaces blinkt im gleichen takt.

mfg maik

Hendrik Hölscher · August 17, 2008 at 8:24 PM

Meine hex verhält sich nicht so.

Wenn eine LED deines Transmitters im gleichen Takt wie der Transceiver blinkt, spricht das für ein HW-Problem.

Nimm mal den Motortreiber ab und spiel mein Kompilat auf.

We proudly present: The release of DMXControl 3.3.3!