Schrittmotor Rampen für Rn Stepp 297

Hallo zusammen,

nachdem ich mich nach diesem Thread für einen Schrittmotor für meine Regelung entschieden habe, bin ich jetzt dabei, dem Motor das Drehen beizubringen.

Ich möchte jetzt zunächst für die Ansteuerung des Motors Beschleunigungs- und Bremsrampen programmieren (GCC). RN Control gibt das Taktsignal an RN Stepp 297 weiter. Durch diese beiden Quellen habe ich mir erstmal ein Grundverständnis für die Rampenprogrammierung angelesen:

1. http://www.embedded.com/columns/tech...equestid=56271
2. http://www.atmel.com/dyn/resources/p...ts/doc8017.pdf

Die Application Note 446 von Atmel ist schon recht gut. In der gezeigten Anwendung wird jedoch nur beschrieben, wie Beschleunigungs- und Bremsprofile mit vorher festgelegten Schrittzahlen gefahren werden können. In meiner Anwendung ist die absolute Schrittzahl vorher aber nicht bekannt. Ich möchte also nur die Änderung der Geschwindigkeit in den Rampen angeben, die erreichte Geschwindigkeit soll danach einfach beibehalten werden.

Zur Zeit habe ich nur einfache Rampen programmiert, wobei der Timerwert mit einem festen Wert in- bzw. dekrementiert wird.

Code:

---

ISR (TIMER1_COMPA_vect)
{
        if (OCR1A != Sollwert)
        {
                if (OCR1A > Sollwert)
                {
                        TIM16_AddOCR1A(-10);       
                }               
               
                if (OCR1A < Sollwert)
                {
                        TIM16_AddOCR1A(10);       
                }
        }
}

---

Ich würde allerdings gerne lineare Beschleunigungsrampen benutzen. Der Motor soll gegenwärtig bis max. 150 Steps/s machen können (Halbschritte).

Mir ist leider noch nicht klar, wie ich die Taktsignale als Rampen berechnen kann, ohne die Schrittzahlen angeben zu müssen. Ich würde gerne so schnell wie möglich beschleunigen/bremsen auf einen variablen Sollwert.

Hat jemand vielleicht schon Erfahrungen bei dieser Problematik?

Schönen Gruß,
Jake

moin moin,

bei meiner Fräse fahre ich mit einer sin^2 Rampe, linear hat Sprünge in der Beschleunigungskurve. Anbei mal eine Exceltabelle zur Verdeutlichung.

Mit Gruß
Peter

So wie das Programm ist, kreigt man etwa ein Quadratische Beschleunigung. Wenn der Motor schon langsam ist, wird auch nur langsam erhöht.

Für eine lineare Rampe müßte man die Schrittweite um die die OCR Werte geändert werden von der Zeit abhängig machen die seit dem letzten Aufrzf vergangen ist - das ist gerade der Wert im OCR register. Also die Schrittweite proportional zum Wert im OCR register:
Man muß dann nur noch etwas am Ende aufpassen, da kann ein kleinerer Schritt nötig sein.

wie soll bei einer linearen Rampe der Übergang von der Rampe zum linearen teil der Bewegung erfolgen? Einfach von Rampe auf linear umschalten ist ein Sprung in der Beschleunigungskurve.

>>da kann ein kleinerer Schritt nötig sein
das Problem habe ich nicht.

Wenn man den Wert fürs OCR Register schrittweise (nach Schritt) erniedreigt, bzw. erhöht, kann es halt passieren das man am Ende einen Etwas kleineren Schritt machen muß weil man sonst nicht auf die dann vorgegeben Geschwindigkeit kommt. Durch die ungleichen intervalle kann man sich nicht darauf verlassen immer in einem Festen Raster zu bleiben.
Für die Funktion ist das keinerlei Problem, man muß nur beim programmieren dran denken.

Wenn man eine Lineare Beschleunigung haben will, gibts einen harten Übergang von konstanter Beschleunugung auf konstante Geschwindigkeit.
Einen besonders weichen lauf kreigt man damit nicht, vor allem wenn es in Mechnik Umkehrspiel gibt.

>>einen Etwas kleineren Schritt

wie bitte ist der kleine Schritt definiert???

Wenn man mit solchen unscharfen Hilfsmitteln arbeiten muss, taugt der Algorithmus nichts.