Schrittmotor ansteuern mit Atmega8 asm

Axel H. schrieb:
> Kann mir jemand einen Tipp geben, wo die Ursache zu suchen ist?

Obwohl du mit Mikroschritten arbeitest, kann ein ohne Last laufender 
Schrittmotor trotzdem in Resonenzen kommen und Schritte verlieren.
Ausserdem schreibst du nicht, wie schnell du die Impulse erzeugst, 
vielleicht zu schnell für eine sinnvolle Beschleunigung. Bei schneller 
Impulsfolge muss man eine Beschleunigungsrampe berücksichtigen.

Belaste (und dämpfe) also erst mal deine Motorwelle, meist reicht es, 
sie mit den Fingern zu bremsen damit der Motor sauberer läuft.
Beschleunigst du schnell, setze mal das Tempo herunter.

Hallo,

der Motor ist im Moment unbelastet. Im Programm habe ich verschiedene 
Gewindigkeiten vorgesehen. Auch bei niedriger Geschwindigkeit (0,5 
Umdr./s)ist das Problem vorhanden.

Ein Rampe habe ich (noch) nicht. Weiß im Moment noch nicht wie ich das 
in asm realisieren kann. Schalte also mit dem enable-pin den Motor 
ein/aus.

Axel

Axel H. schrieb:
> Motor stoppt. Der Motor macht aber nur ca. 80Grad. Für eine ganze
> Umdrehung muss ich 2250 Impulse ausführen. Nach meinem Verständnis
> müsste auch eine Verdoppelung der Impulse die doppelten Umdrehungen
> bedeuten. Aber der Motor macht bei 4500 Impulsen ca. 750 Grad.
>
> Kann mir jemand einen Tipp geben, wo die Ursache zu suchen ist?

 Doppelte Anzahl Impulse <> doppelte Anzahl Schritte = verlorene
 Schritte.

 Da die Differenz bei Verdoppelung kleiner wird, liegt dein Problem
 in Anfahren ohne Rampe.
 Langsamer anfahren oder Tabelle benutzen.

Axel H. schrieb:
> Ich habe jetzt ein Programm in ASM geschrieben.Ich steuere damit die
> Pins PUL, DIR und ENA an. Die Frequenz für PUL erzeuge ich mit TimerO.

Mit welcher Frequenz bist du am PUL dran? Hast du bedacht, dass du eine 
Mindestpulsweite beim M542 brauchst? Hab das Datenblatt dazu nur 
überflogen aber da hab ich was von 1.5 us Mindesbreite gelesen.

Hallo,

habe jetzt 2 Fehler gefunden:
1. Ich mache bei jedem Timer-Interupt einen Flankenwechsel zur 
Pulserzeugung. D.h. für eine Umdrehung brauche ich also 2000 Impulse.
2. Ich hatte einen Fehler bei meinem Zähler um 255 Schritte.

Beides habe ich korrigiert und jetzt werden die Umdrehungen korrekt 
erreicht.

Gerne würde ich aber, wie schon empfohlen, 2 Rampen implementieren. Kann 
mir vielleicht jemand beschreiben, wie die Rampen mit einer Tabelle 
funktieren? Ich versuche das das selber in asm umzusetzen. Noch ein 
Hinweis: Mit einem Drehencoder kann ich verschiedene Drehzahlen 
einstellen.

Danke für einige Tipps.

Axel H. schrieb:
> Gerne würde ich aber, wie schon empfohlen, 2 Rampen implementieren. Kann
> mir vielleicht jemand beschreiben, wie die Rampen mit einer Tabelle
> funktieren? Ich versuche das das selber in asm umzusetzen.

 Nur als Beispiel beim Anfahren:
 Schrittzähler = 0
 Solange der Schritzähler < 100, Werte aus Tabelle[Schrittzähler]
 nehmen und inc Schrittzähler, ansonsten Full Speed fahren.

 Beim Abbremsen:
 Schrittzähler = 50
 Solange der Schritzähler > 0, Werte aus Tabelle[Schrittzähler]
 nehmen und dec Schrittzähler, ansonsten Halt.

 P.S.
 Lange her, dass ich etwas mit Schrittmotoren gemacht habe, ob die
 100 bzw. 50 Schritte reichen oder zu viel sind, weiss ich nicht mehr.

Hallo,

heißt das, wenn ich 50 Geschwindigkeitsstufen habe, ich brauche für die 
Anfahrrampe eine Tabelle von 50 Zeilen mit jeweils 100 Werten?


Axel

Axel H. schrieb:
> heißt das, wenn ich 50 Geschwindigkeitsstufen habe, ich brauche für die

 Da sind Zeiten für deinen Timer drin.
 Und beim abbremsen brauchst du (meistens) weniger Schritte.

> Anfahrrampe eine Tabelle von 50 Zeilen mit jeweils 100 Werten?

 Es geht auch mit 2 Zeilen a 50 Werten.

Hallo,

schau dir das mal an:
http://www.atmel.com/images/doc8017.pdf

Ist zwar in C, aber das lässt sich sicher umsetzten.
Sehr gut erklärt und funktioniert prima.
Ich habe das schon auf den XMega portiert und auf den AVR32.
Beides hat sehr gut funktioniert.
Man muss bei den Berechnungen ein bisschen aufpassen, dass man bei 
Anpassungen auch den Datentyp mit anpasst, so dass es keine Überläufe in 
den Variablen gibt.

Gruß, Jens

Jens W. schrieb:
> Ist zwar in C, aber das lässt sich sicher umsetzten.
> Sehr gut erklärt und funktioniert prima.

 Mag sein, aber unnötig und langsam.
 Auch mit 16-bit Werten braucht eine Tabelle nur 200 Bytes bei
 100 Schritten.

 Das ist weitaus weniger als der nötige Code für die verschiedenen
 (und meistens unnötigen) Berechnungen.
 Von der Geschwindigkeit gar nicht zu reden.

 Wenn 2000 Schritte anzufahren sind, dann werden Schritte 0-99 aus
 der Tabelle gelesen, Schritte 100-1949 mit Fullspeed gefahren und
 die Schritte 1950-1999 wiederum aus der Tabelle geholt, nur absteigend
 und mit 2 x decrement.

 Ich hatte damals sogar 2 Tabellen drin - eine für unbelasteten und
 eine für belasteten Zustand. Zwei Stunden hin- und hergefahren, die
 richtigen Zeiten gefunden und das wars dann.

 Oder PC die Zeiten ausrechnen lassen und neue Tabelle flashen.

Hallo,

Das ist eine recht pauschale Aussage.
Man kann nicht einfach behaupten es sei unnötig, wenn man die 
Anforderungen nicht kennt. Für deine Anwendung mag es sein, dass es 
nicht notwendig ist. Du konntest offensichtlich damit leben, dass die 
Beschleunigung nicht konstant ist.
Und langsam. Naja, dass ist so die Frage. Schnell genug um die Schritte 
zu berechnen ist es auf jeden Fall.
Und wenn der Controller wartet, bekommst du auch kein Geld zurück. Also 
lass ihn doch was tun.
Oder in deiner Anwendung war es so, dass es zu langsam war. Je nach dem 
was der sonst noch so zu tun hat. Das muss man eben im Detail 
betrachten.

Egal, lass uns nicht streiten. Ich wollte nur einen alternativen Ansatz 
aufzeigen.
Halten wir fest: Tabelle oder der Ansatz aus der AVR-Note ist beides 
möglich.

Grüße und schönes Wochenende, Jens

Hallo,

Super! Danke für eure beiden Lösungsvorschläge. Ich schaue mir beide mal 
genau an und werde dann sehen, was ich mit meinen bescheidenen 
Asm-Kenntnissen umsetzen kann.

Kann gut sein, dass ich nochmal nachfragen muss.

Axel

Jens W. schrieb:
> Egal, lass uns nicht streiten. Ich wollte nur einen alternativen Ansatz
> aufzeigen.
> Halten wir fest: Tabelle oder der Ansatz aus der AVR-Note ist beides
> möglich.

 Nöö, kein Streit, mein Punkt war Schnelligkeit und Codesize.
 Wenn es mit der Zeit und Grösse hinhaut - OK, kein Problem.
 Aber gerade bei uC sind die beiden Sachen problematisch, deswegen...

> Du konntest offensichtlich damit leben, dass die
> Beschleunigung nicht konstant ist.

 Nein, ich habe nicht mit einem konstanten Wert gerechnet (addiert),
 sondern die berechneten Werte in eine Tabelle gepackt, danach durch
 ausprobieren noch ein bisschen an die Grenzen rangezogen und das
 wars dann.

 Deswegen zwei Tabellen, eine für belastet und eine für unbelastet.