wie beschleunigt/bremst ihr stepper?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Würde den Knick nicht überbewerten. In der Beschleunigungsphase wird ab Null mit konstanter Beschleunigung bis zur vorgesehenen Marschgeschwindigkeit beschleunigt, bei Erreichen derselben wird die Geschwindigkeit einfach beibehalten. Das Abbremsen ist schon von daher anspruchsvoller als der Controller vorrausberechnen muss ab wann die Geschwindigkeit veringert werden muss um punktgenau im Ziel anzukommen.Das Ganze dann im Mikroschrittbetrieb. Aber sei gewarnt: das kann ausarten. Schau mal im Mikrocontrollerforum diesbezüglich nach. Viel Raum und Zeit für Experimente.
      Mach's praktisch: lerning by doing
    • Die Punktlandung ist das nächste. Was ich weiß, ist meine Weglänge in Anzahl steps. Dann die Pause zwischen den steps beim Start, die Pause zwischen den steps bei Höchstdrehzahl. Aus diesen Werten kann ich gemachte steps und noch zu machende steps errechnen, bzw während dem Lauf mitführen. Wenn ich im gleichen Maße Beschleunige, wie ich Bremsen will, dann kann ich aus der aktuellen Pause zwischen den steps den Bremsweg errechnen (oder mitzählen) und mit den Reststeps vergleichen. Dann hab' ich den Punkt, wo ich das Bremsen beginnen muss.
      Was ich jetzt noch nicht verstehe, wenn ich die Pausen zwischen den steps nach jedem step um einen gleichen Teil verringere, dass das nicht zu einer gleichmäßigen Geschwindigkeitszunahme führt.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Mach dir's nicht selbst schwer, probier's einfach aus.
      Will man das Ganze präzise machen ist man auf die aufwändigen Motion Controller ICs angewiesen, wie z.B:elektroniknet.de/markt-technik…nd-3d-drucker-148735.html

      Bei diesen speziellen IC's nimmt dir die Hardware ne Menge Rechenarbeit ab, alle Achtung was die Halbleiterhersteller hier vorgeleistet haben.

      The post was edited 1 time, last by oscar: Ergänzung ().

    • tschoeatsch wrote:

      Was ich jetzt noch nicht verstehe, wenn ich die Pausen zwischen den steps nach jedem step um einen gleichen Teil verringere, dass das nicht zu einer gleichmäßigen Geschwindigkeitszunahme führt.
      Jetzt hab' ich's endlich gerallert.
      Und ich probier jetzt einfach mal rum. Ich werde berichten...
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Michael wrote:

      Die Beschleunigungsrampen musst du weiterhin in Software machen.
      da ist der Hund begraben,
      Aus Oscars Beitrag glaubte ich zu lesen, dass dieser Chip den Job übernimmt, er schrieb ja, dass die Hardware die rechenarbeit übernimmt, und das konnte ich nicht nachvollziehen, also wo ist der Vorteil gegenüber der konventionellen Lösung?

      Mein Problem liegt darim, dass der Rechenaufwand für die Rampe (gem. Atmel-Note) den Atmega so auslastet, dass er ins Stolpern kommt.
      Gruß
      Hans
    • Hans_L wrote:

      Mein Problem liegt darim, dass der Rechenaufwand für die Rampe (gem. Atmel-Note) den Atmega so auslastet, dass er ins Stolpern kommt.
      Dann solltest du Delay vermeiden. Wie das geht, kannst du dir ja im Lexikon mal anschauen unter "Statemachine Tutorial".
      Deine Fahrten kann man ja gut in 4 Zustände aufteilen, die da beispielsweise SpeedUp, SpeedDown, Stop und Run sein können.
      Das kann dann nebenher als Paralleler Prozess von der Hauptschleife aufgerufen werden. Damit die Rampe dann aber linear beschleunigt oder bremst bedarf es einer Zeitbasis. Da kann man bestimmt einen bestehenden Timer mitbenutzen.

      Wenn du genaueres wissen möchtest, dann einfach nachhaken.
    • Hans_L wrote:

      Mein Problem liegt darim, dass der Rechenaufwand für die Rampe (gem. Atmel-Note) den Atmega so auslastet, dass er ins Stolpern kommt.
      Stell doch ma deine Software hier ein, dann können wir sicher ein paar Tips geben.

      djmsc wrote:

      Wenn ich das richtig im Datenblatt gelesen habe, geht das mit dem DECAY-Pin.
      Decay hat nichts mit der Rampensteuerung zu tun.
      In dieser H-Brücke kann man den Motor in der PWM-Pause kurzschließen (slow decay) oder nur kurz kurzschließen und dann loslassen (fast decay)
      Das hat Einfluss auf die Steifigkeit bei der Bewegung des Schrittmotors.
      Mit PWM ist hier die interne PWM gemeint zur Erzeugung der verschiedenen Ströme für den Mikroschrittbetrieb.
    • Mitch64: Ähnlich mache ich das eigentlich auch.

      Ich baue eine Anfahrtabelle, ganz old shool, in der die Pausenzeiten zwischen den Pulsen stehen.
      (Die Pulslänge ist bei den China-Steppertreibern wichtig, die Pulszeiten müssen eine Mindestlänge habe, ich schalte das immer mit einem festen Wait zwischen An und Aus)
      Da kann man dann eine Rampe mit oder ohne Kurvenverlauf per Hand coden und ablegen.
      Die Rampenwege nenne ich immer "Attack", "Decay" und "Sustain" in der Mitte, ganz wie in der Musikelektronik.
      Vor dem Fahren rechne ich die beiden Rampen, also deren Pulszahl, aus der Gesamtlänge raus und hole die Pausenzeiten, also die Schritt-Waits, aus der Tabelle.
      Der Sustain ist auch ein Wert aus der Tabelle, nämlich der letzte der Tabelle.
      Beim Attack lese ich die Tabelle vorwärts, beim Sustain halt einfach rückwärt aus.

      Ist bei der Erstellung zwar etwas probieren, aber es funktioniert dann super.
      Am besten testet man erstmal die ideale Schrittgeschwindigkeit aus und nimmt den Pausenwert dann als miximalen Tabellenwert (also den Sustain-Wert).
      Den Rest kann man vorher berechnen oder per Hand machen. Der Fahrweg kann auf auf Papier skizziert werden und die Stützpunkte dann für ein Stepwait-Polygon hergenommen werden.