Algorithmus zum parallelen Ansteuern von Schrittmotoren

[Joe23]

Hallo zusammen,

ich beschäftige mich gerade mit einem Deltaroboter, der über 3 Schrittmotoren angesteuert wird. Die Hardware ist soweit bestellt, jetzt kümmer ich mich gerade um die Software.

Hardware:

3 Schrittmotoren von Nanotec, 3 NM
3 Steuerungen mit den Eingängen Enable, Takt, Richtung
PC mit Parallelport

Software:
Visual Basic C++ 6.0

Ich bin gerade am Schreiben der Ansteuersoftware für die Schrittmotoren und stehe gerade auf dem Schlauch.

Ich habe mir bereits ein Steuerprogramm für einen Schrittmotor geschrieben. Dieser wird über die parallele Schnittstelle angesteuert und Dreh sich um eine bestimmte Schrittanzahl in eine bestimmte Richtung.
Zudem habe ich abhängig von der Start-/Stopfrequenz des Schrittmotors und einer variablen Rampe eine Beschleunigungs- und Bremsrampe implementiert. Die Generierung des Taktes erfolgt über einen Softwaretimer.

Dies funktioniert soweit alles bestens...

Mein Problem ist momentan, das ich diese Ansteuerung auf 3 Schrittmotoren erweitern will...

Dies wäre insofern bei folgenden Zuständen kein Problem:

- Die Motoren laufen nacheinander
- Die Motoren laufen synchron, d.h. die Motoren laufen parallel aber jeder Motor dreht sich um die gleiche Schrittanzahl
- Die Motoren laufen parallel mit unterschiedlichen Schrittanzahlen, aber es gibt keine Beschleunigungs- und Bremsrampen, d.h die Drehzahl der Schrittmotoren ist kleiner als die Start-/Stopfrequenz.

Ich würde aber gerne den Optimalen Fall umsetzten...alle 3 Motoren drehen sich gleichzeitig mit unterschiedlichen Schrittanzahlen in unterschiedliche Richtungen, und jeder Motor hat eine Beschleunigungs- und Abbremsrampe...im Prinzip kommt das einer CNC-Software gleich...

Ich bin nicht auf der Suche nach einem fertigen Programmcode, sondern nur auf der richtigen "Programmstruktur". Kann ich mit einem Timer drei Motoren ansteuern, oder benötige ich 3 Softwaretimer? Wie setzte ich das Programm von der Logik her um?

Hat jemand von euch Erfahrung in dem Thema? Wurde das hier schon einmal diskutiert/vorgestellt?

Wäre um Hilfe dankbar.

PS: Mir ist durchaus klar, das es so etwas (CNC-Steuerprogramme) fertig zu kaufen gibt, bzw. als Freeware verfügbar sind.

Z.B.: http://www.easgmbh.de/index.php?area...enlos_freeware

Ich möchte aber später mein eigenes Ansteuerprogramm des Roboters schreiben, und daher nicht auf fertige Software zurückgreifen, die ich nicht ändern/manipulieren kann.

Gruß

[RedBaron]

Moin,

ich baue gerade eine manuelle Fräse in eine motorgesteuerte um, habe also ein ähnliches Problem. Mein Ansatz ist (noch) ein anderer:
1) Ich werde den (dreidimensionalen) Fahrweg berechnen. Diesen werde ich schrittweise (timergesteuert) abfahren. Bei jedem Schritt müssen die Schritte der Motoren berechnet und nachgefahren werden.
2) Der Trick soll sein, die Steps so klein zu machen, dass während eines Timersteps maximal ein Motorstep notwendig sein wird. D.h. pro Timerstep ein Motorstep oder keiner.
3) Wenn eine Anlaufphase (Rampe) benötigt wird, muss die entlang des Fahrwegs berechnet werden (nicht entlang der Achsen). Eine Rampe benötigt man aber nur, wenn große Massen bewegt werden. Schrittmotore an sich kommen ohne aus.
4) Ich denke, dass ich mit einfachen Fahrwegapproximationen auskommen werde (Geraden- und Kreisabschnitte).

Beim Deltaroboter sollten eigentlich immer nur Geraden als Fahrweg auftauchen, die Verbindungline zwischen Start- und Zielpunkt. Da kann man gut mit einer Vektordarstellung der Geraden arbeiten:
F = S + c * (Z - S).

F: Punkt auf dem Fahrweg, S: Startpunkt, Z: Zielpunkt, c: freier Parameter.
Wenn man c nun in kleinen Schritten von 0 nach 1 variiert, fährt man mit F entlang der dreidimensionalen Geraden von S nach Z.
(In "normalen" Koordinaten Fx = Sx + c * (Zx - Sx). dito für Y- und Z-Achse).
Die Koordinaten von F muss man nun beim Delta in Motorschritte umrechnen. Bei einer Rampe wird die Geschwindigkeit, mit der sich c ändert langsam gesteigert.

5) Ich hoffe, dass das funktioniert.

[Joe23]

Hallo RedBaron,

danke für deine Ansichten zu dem Problem.

Zu 1.) Du machst also irgendeine Art von Bahninterpolation. D.h du legst zwischen dem Start- und dem Endpunkt eine Bahn, dies kann im einfachsten Fall eine Gerade sein, im extremeren Fall z.B ein Radius oder Kreis...

Zu 2.) Dann teilst du diese Bahn in viele kleine Schritte, d.h. abhängig von deinem Schrittwinkel, Mikroschritt sowie der Übersetzung und der Spindelsteigung sind die Schritte so klein, das maximal ein Schritt gefahren werden muss.

Das hat für mich zwei Effekte:

A) Es muss maximal ein Step pro Schrittmotor ausgeführt werden. Mit der gleichen Ansteuerfrequenz kann das dann natürlich parallel ausgeführt werden. Abhängig von den Verfahrwegen kann es halt dann mal sein, das nur ein Schrittmotor angesteuert wird, und die anderen beiden Stehen bleiben..

B) Durch diese weise kann keine Rampe umgesetzt werden, da im ungünstigsten Fall nach einem Schritt der Schrittmotor 1 noch einen zweiten Schritt macht, somit könnte ich das Zeitintervall verkürzen (=Rampe) aber leider der Schrittmotor 2 schon wieder stoppen muss. D.h. das ganze funktioniert bis zur Start-/Stopfrequenz, aber höhere Geschwindigkeiten sind bei dieser Variante nicht möglich.

Zu 3.) Ich glaube nicht das eine Rampe anhand des Fahrweges berechnet werden kann, denn du reduzierst ja deine Bahn in Unterschritte. Wenn du die Unterteiluing noch feiner machst, dann passiert ja, das sich die Schrittmotoren z.b die ersten 3 Schritte überhaupt nicht rühren, das die Auflösung so klein ist, das ein Step halt mindestens z.B. 3 Unterschritte benötigt. Am Prinzip ändert sich also nichts. Es wird ein Step gemacht, und danach eine Wartezeit implementiert (z.B. Timer). In der heutigen Zeit sind die Rechnersysteme so Leistungsfähig, das sämtliche Berechnungen während der Pausenzeit passieren. Die einzige Möglichkeit das ganze schneller zu machen ist also den Takt anzupassen, aber dies geht nur bis zur Start-/Stopp Frequenz.

Prinzipiell hast du mit der Aussage recht, was große Massen angeht...dies ist aber eine Sache der Dimensionierung. Bei meinem Deltaroboter gibt es keine Zahnriemen oder zusätzliche Getriebe, die Arme hängen direkt auf den Schrittmotoren. Dies ist zwar nicht förderlich für die Dynamik oder Genauigkeit, aber für das Spiel des Roboters. Mit 1/4 Mikrostep lassen sich hier noch eine Auflösung am Eneffektor von 1,5 Millimeter erziehlen (Schrittmotortoleranz + Schrittabweichung). Aber dafür habe ich kein Getriebespiel (Kugelgelenke müssen natürlich vorgespannt sein).
Das kann man sich ja alles ausrechnen. Abhängig von den Beschleunigungs- Reibungs. und Massenträgheiten kann ich zeimlich exakt das erforderliche Motormoment errechnen. Durch das Parallelgestänge habe ich fast keine Masse am Roboter , daher sind hier nur ca. 0,3 Nm an Drehmoment ausreichend. Meine Schrittmotoren haben ein dynamisches Drehmoment von ca. 2,7 Nm bis zu einem Drehzahlbereich von 100 U/min, damit ist für dynamische Positionierprozesse genügend Leistungsreserve für Beschleunigung. Mehr Drehzahl wird auch nicht benötigt, denn die Ausleger sind ja auf der Motorachse befestigt, und für einen Fahrweg von z.B. 20 cm wird ein Ausleger nicht mehr als 90 Grad auf einmal gedreht.
Daher vermute ich fast, das ich mit der Start-Stopfrequenz ohne Rampe leben kann, aber warum nicht ordentlich mit Rampen umsetzten?

Zu 4.) Beim Delta Roboter ist der Endeffektor immer parallel zum Boden, aber es können natürlich wie bei einer CNC sämtliche Bahnen abgefahren werden, von Linearfahren bis hin zu Kreisinterpolationen in 3 Ebenen

Gruß

[RedBaron]

Hallo Joe23,

das Problem taucht nur dann auf, wenn die bewegten Massen so groß sind, dass der Schrittmotor es nicht schafft, diese innerhalb eines Schrittes (Schrittdauer) auf die gewünschte Geschwindigkeit zu bringen. In diesem Fall muss man mit einigen Steps mit größerer Intervalldauer beginnen, die dann immer kleiner wird. (Ich habe hier noch einmal das Rampenprinzip zusammengefasst). Oder gibt es einen anderen Grund? z.B. die Bewegung von Flüssigkeiten in offenen Behältern, die überschwappen könnten?

Im Regelfall ist der Fahrweg so beschaffen, dass die Motoren mit unterschiedlicher Geschwindigkeit laufen müssen! Einige laufen schneller, die anderen laufen dann je nach Bahn ggf. sehr langsam. Vielleich nur ein einzelner Motorstep während der gesamten Bewegung. Das lässt sich nicht ändern, der Schrittmotor kann immer nur einen ganzen Step oder keinen. Wenn alle Motoren gleich schnell laufen sollen, sind die Möglichkeiten des Fahrweges doch recht eingeschränkt, oder?
Die Option der Halbschritte verringert das Problem vielleicht ein wenig, löst es aber nicht.

Die Rampe ist nur bei den schnell drehenden Motoren sinnvoll. Die anderen sind ja schon langsam. Warum sollten die noch langsamer gemacht werden?

Mit langen Timersteps kann man auf jeden Fall problemlos die Bahn abfahren. Es kann also nur darum gehen, die Geschwindigkeit zu erhöhen. Da ist der schnellste Motor maßgeblich. An diesem muss die Länge der Timersteps ausgerichtet werden (das gilt auch bei den besagten Flüssigkeiten).

---

Ich hätte da noch einen ganz anderen Punkt. Der Takt für Motorsteuerung kommt vom PC und du benutzt Windows (wenn ich das korrekt aus deinem ersten Post ableite). Wie kriegst du das hin, dass du bei einer akzeptablen Taktrate landest? Bei meinen Versuchen bin ich nie unter etwa 20 mSec pro Takt gekommen (entsprechend 50 Schritte pro Sekunde). Und das auch nur dann, wenn ich dem Prozess höchste Priorität zugeteilt hatte (es liegt nicht daran, dass ich einen alten, langsamen Rechner habe ).

Viele Grüße

[Peter1060]

moin moin,

>>etwa 20 mSec pro Takt gekommen (entsprechend 50 Schritte pro Sekunde).

Was hast Du als Zeitbasis genommen? Die Ticks kommen alle 18,xxms.
Es gibt auch noch einen 1ms-Timer, war glaube ich in der WinAPI mmsound.
Welche Programmiersprache?

Als Tip: Für grade Bahngerechnungen den Bresenham anwenden, die Achse mit dem längsten Weg wir mit der Fahrgeschwindigkeit getaktet, die anderen sind langsamer.

Mit Gruß
Peter

[Joe23]

Hallo Redbaron,

das mit der Massenträgheit ist klar...das ist nicht das Thema. Beide Fälle können zum Schrittverlust führen...zu große Beschleunigungen und ebenso auch undefinierte Lastwechsel....

Zum Thema Fahrweg. Ich weiß was du mit den Geschwindigkeiten meinst, aber das ist in deinem Fall so wie du es mir beschrieben hast nicht richtig....

Prinzipiell ist es ein Ziel jedes Roboters eine bestimmte Bahn (z.B. Gerade abzufahren). Dazu gibt es eigentlich zwei Hauptverfahren:

A) Das Multi-Point-Verfahren, hier wird die Bahn in einzelne Segmente unterteilt, und die einzelnen Punkte nacheinander angefahren.

B) Dynamische Geschwindigkeitsregelung. Hier bewegen sich alle Motoren synchron, d.h alle Motoren starten zum selben Zeitpunkt und stoppen auch zum selben Zeitpunt. Abhängig von der Bahn wird hier dynamisch die Geschwindigkeit/Richtung geändert.

Es gibt auch noch Sonderfälle, z.B. PTP (Point to Point), hier laufen alle Achsen asynchron mit maximaler Geschwindigkeit. Das Ergebnis ist natürlich eine Art Schlangenbahn. Ziel ist es blos möglichst schnell von A nach B zu kommen.

Nach deinen Beschreibungen hab ich gedacht, du willst Variante A umsetzten. Damit kann ich aber nicht unterschiedliche Geschwindigkeiten realisieren, sondern nur die Taktfrequenz für den gesamten Vorgang ändern (es wird ja immer nur ein Step betrachtet), oder täusche ich mich da?
Im Prinzip läuft das auf ein ähnliches Prinzip hinaus, weil über den Durchschnitt der gesamten Strecke eine unterschiedliche Anzahl von Schritten durchgeführt wurde, und über das Verhältnis von Schrittanzahl zu Schrittpausen sich unterschiedliche Geschwindigkeiten abbilden. Dies entspricht aber nicht der Variante B. Dies ist aber auf Grund der Schrittmotoren und dem Schrittwinkel denke ich auch nicht realisierbar, da ich den Motor nicht beliebig langsam laufen lassen kann.

Ich habe heute noch einmal gesteste mit einem alten Stepper. Dort liegt die Start-/Stopfrequenz ohne Last mit Vollschritt bei ca. 400 hz. Diese wird natrülich mit Last nach unten gehen, aber genaueres weiß ich nur nach der Montage des Roboters. Ich denke für meine Applikation benötige ich keine Rampen, da mit einer Frequenz von angenommen 200 hz und einem typischen Positionierwinkel von 90 Grad liege ich schon bei 250 ms pro 90 Grad Verfahrwinkel. Dies entspricht einen Verfahrweg von ca. 150 mm. Das sollte an Dynamik locker für einen Hobbyroboter reichen.

Richtig: Taktsteuerung erfolgt vom PC mit Windows XP über die parallele Schnittstelle.
Die Generierung der Signale erfolgt über einen Softwaretimer, unter Berücksichtigung der Systemfrequenz und der Systemzeit. Ich verwende ein Tastverhältnis von Puls/Pause von 0,5 und versuche die Brechnungen nach dem Timeraufruf so gering wie möglich zu halten.
Lief heute bei 2,5 ms/Takt problemlos. Niedrigere Takte hat der Schrittmotor nicht vertragen, da die Start-/ Stoppfrequenz überschritten wurde.

Du kannst mir deine Email-Adresse zukommen lassen, dann schicke ich dir mal mein einfaches Ansteuerprogramm. Ist nichts besonderes, aber es scheint auch bei größeren Taktraten zu funktionieren.

P.S: Ich habe einen Standartrechner 2,4 Ghz mit Windows Xp, Neuinstalliert ohne Internetzugang, Virenscanner, oder andere Nutzloser Software...ist halt nur ein Bastelrechner. Aber ich habe noch nie an Prozessprioritäten rumgedreht.

Gruß

[Joe23]

Ergänzung:

Der verwendete Softwaretimer ist eigentlich nur durch die Systemfrequenz und der Berechnungszeit bzw. Zeit für das Ausführen der Befehle in der Timerroutine limitiert.

Theoretisch dürften damit auch Taktraten weit jenseits von einigen 1000 Hz zu realisieren sein, die Limitierung passiert wohl irgendwann durch das Betriebssystem selbst, bzw. es kommen halt irgendwann keine regelmäßigen Pulse mehr, da die Berechnungszeit für die Timerroutine bzw. für andere Prozessoraktivitäten irgenwann größer als der Takt selbst sind. Da der Timer nicht Hardwarebasierend ist, muss irgendwo die Grenze sein.

Für so etwas wäre mal ein Oszilloskop interessant

Gruß

[RedBaron]

Moin,

Peter, danke für den Bresenham-Tipp. Ich will es später mit einem AVR machen, da ist Multiplikation nicht gut. Die mmsound werde ich mir bei Gelegenheit einmal anschauen. Bei meinen bisherigen Versuchen (Visual Basic) ist mir immer der Prozess- bzw Thread-Wechsel dazwischen gekommen. Ich hab's noch einmal ausprobiert, aktuell lande ich bei im Mittel etwa 15 mSec. Ich möchte aber hier nicht mehr viel weiter forschen. Später will ich sowieso mit einem µC arbeiten. Ich muss mit meiner Zeit haushalten.

Joe, wieso kann man einen Schrittmotor nicht beliebig langsam laufen lassen? z.B. ein Schritt pro Jahrhundert ('mal vom Korrodieren der Geräte abgesehen )?

Was ist eine "Start/Stopp-Frequenz"? Ich habe meine Motoren bisher immer so angesteuert:
-Spannung auf vorgesehene Spule(n)
-warten (entsprechend der Schrittfrequenz)
-Spannung auf die Spulen für den nächsten Step
-warten
-...
Da habe ich keinen "Stopp".

Zur Bahn: Mit Schrittmotoren kann man nur diskrete Punkte ansteuern. Wenn man einen Step ansteuert "schnappt" der Motor praktisch in die nächste Position (wenn ihn größere (Massenträgheits-) Widerstände daran nicht hindern). In den Grafiken von http://de.wikipedia.org/wiki/Bresenham-Algorithmus kann nur von einem Mittelpunkt eines Kästchens zum Mittelpunkt des nächsten gelangen (oder von Ecke zu Ecke, je nach Vorliebe). Mit diesen Sprüngen muss man die gewünschte Bahn approximieren. Das kann man nicht besser machen. Es geht also nur Variante A), Multi-Point.

Anders ist der Fall, wenn man große Massen bewegen will. Hier wirken die Massen als Schwungmasse (Tiefpass, oder so (ich bin nicht so fit Regeltechnik)) und man kann eher von einer kontinuierlichen Bewegung sprechen. Zur (geregelten) Überwindung der Beharrungskräfte sind dann aber Kalkultationen zu den Kräften (bzw. Momenten) notwendig und nicht zu den Geschwindigkeiten. Nehme ich jedenfalls an...

Viele Grüße

PS: Meine E-Mail-Adresse findest du in den privaten Nachrichten.

[Joe23]

Hallo RedBaron,

# Joe, wieso kann man einen Schrittmotor nicht beliebig langsam laufen lassen?

Aus dem Grund der magnetischen Rasterung. Die Einzige möglichkeit ist den Takt entsprechend zu reduzieren. Für mich läuft der Motor aber nicht, sondern steht still bis ein weiterer Takt kommt. Dann aber kann ich die Geschwindigkeit wie der Motor von einem Schritt zum anderen springt nicht arg reduzieren...somit kann ich im Vergleich zu DC oder AC Motoren keine kostant langsame Geschwindigkeit erreichen.
Mikroschrittauflösungen von kleiner 1/16 oder 1/32 halt ich auch eher für Schwachsinn, da die meisten Motoren diese nicht auflösen können. Der Motor dreht sich halt einfach nicht mehr.

Start-Stop_Frequenz ist die Frequenz, bei der der Schrittmotor problemlos aus dem Stand anläuft und auch wieder zu Stillstand kommt, ohne Schrittverlust natürlich. Diese hängt von dem Motoren selbst ab, den erforderlichen Drehmomenten, das Massen sowie die Beschaltung und die Leistungsfähigkeit des Netzteils. Vorteil ist, das wenn man unter dieser Frequenz bleibt, keinerlei Rampen benötigt. Diese liegt z.B. bei meinem Testmotor bei ca. 333 Hz. Für CNC Maschinen mit Spindeln werden ja für höhere Verfahrgeschwindigkeiten weitaus höhere Taktraten benötigt. Da kommt man dann um Rampen nicht herum.

Das Programm für den Schrittmotor hab ich dir geschickt, gib mir bitte bei Gelegeneheit eine Rückmeldung ob du mit diesem Programm mehr erfolgt hattest.

Gruß

[RedBaron]

1) danke
2) Ausführungen verstanden, muss ich d'rüber nachdenken
3) melde mich