Algorithmus zum parallelen Ansteuern von Schrittmotoren

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ß

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.

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ß

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? :-k
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 O:)).

Viele Grüße

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

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ß

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ß

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.

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ß

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

Hallo Redbaron,

ich hab in zwischen noch einmal über die Sache nachgedacht...

Ursprünglich bin ich bei der Ansteuerung von den 3 Achsen von den Motoren selbst ausgegangen. D.h ich habe mich auf die Motoren konzentriert und versucht die maximalen Geschwindigkeiten und Beschleunigungen zu begrenzen.

Mittlerweile sehe ich die Sache vom Endeffektor aus. Wenn ich mir z.B. eine Gerade nehme, dann schaue ich nicht auf die Motoren selbst, sondern direkt auf die Bahn. -> Beschleunigungsrampe vom Startpunkt aus und Bremsrampt am Zielpunkt. Limit ist hier dann der Motor mit den meisten Schritten. Der wird maximal beschleunigt und auch rechtzeitig abgebremst. Die anderen Motor laufen logischerweise entweder langsamer oder genauso schnell, daher kann hier kein Schrittverlust vorkommen.

Das läuft dann auf deinen ersten Ansatz hinaus, das die Timerwerte sich ändern (Beschleunigung), aber nicht bezogen auf die Schrittanzahl sondern der Bahn des Endeffektors.

Nur wie siehts das bei PTP Bewegungen (jede Achse fährt mit maximaler Geschwindigkeit) oder mit einer Kreisbahn aus, wo auch Richtungswechsel vorkommen?

Gruß

moin moin,

anbei mal eine kurze Übersicht zu meiner Fräsensteuerung.
Als Erläuterung:
Linear/Cirlce errechnen den nächsten Schritt und geben den an FiFo weiter, ist der Platz0 nicht im Fifo frei wird gewartet.
Ausgelesen wird Platz 19, der Rest durchgeschoben, das Byt wird an die Motore gesendet. Mit dem Zeiger auf den Fifo wird aus der Sin^2-Tabelle der Zeitwert geholt und mit der Wurzel aus der Summe der angesteuerten Motore wird der InterrupTimer geladen.
Der Timerinterrupt löst dann die nächste Übertragung aus.
Ist Linie/Circle mit der Berechnung fertig wird in der FiFo-Steuerung ein Bit gesetzt und der Fifo abwärtszählen ausgegeben. Dabei wird die Sin^2 Tabelle rückwärts (zu langsameren Zeitwerten) ausgelesen und somit der Bremsvorgang eingeleitet.

Mal ganz in Ruhe durchdenken, es funktioniert jedenfalls ganz gut bei meiner Fräse.

Mit Gruß
Peter

Hallo Peter,

vielen Dank für deine Darstellung des Problems, aber ich stehe immer noch auf dem Schlauch...

Ich fasse mal das zusammen, was ich deiner Grafik bzw. deinem Post an Infos entnehmen konnte:

- Du hast zwei verschiedene Funktionen (Linear, Circle). Diese führen dir eine Bahninterpolation durch. D.h. du unterteilst die gesamte Wegstrecke in einzelne Stückchen, die Aufteilung ist so klein das maximal ein Schritt ausgeführt wird, oder auch keiner. Den enstehenden Fehler auf Grund der Schrittweite kannst du z.B durch den Bresenhamalgorithmus halbieren. Ergebnis dieser Funktion ist entweder Tabelle mit vordefinierten Fahrbefehlen oder eine Online-Berechnung. In deinem Fall füllst du die Verfahrtabelle (FiFo) online mit den berechneten Werten. Der Output dieser Funktionen ist für jeden ich nenne es mal Verfahrschritt ein Taktsignal für alle 3 Motoren und die jeweilige Richtungsinformation (z.B. 1, 0, 0, 1, 1, 1) (Motor 1 einen Schritt weiter, Motor 2 steht, Motor 3 steht, Motor 1 Richtung vor, Motor 2 Richtung vor, Motor 3 Richtung Vor).
- Aus deiner Verfahrtabelle (FiFo) liest du immer die letzte Position aus, schiebst alle anderen durch und füllst diese mit deinen online Brechnenden Werte auf
- In der Tabelle sind berechnete Sin2-Werte für die Beschleunigung sowie den Bremsvorgang interlegt. Diese verwendest du programmgesteuert. Am Anfang vermutlich parallel zu den Fifo-Nummer von 1-19 zum Beschleunigen, dann konstant mit der Position 19 und wenn kein neuer Wert mehr online aufgefüllt wird (Flag wird von Lin/Circ gesetzt) rückwärts von 19-1 zum Abbremsen.

Was mir noch nicht klar ist, was es mit der Wurzel über die Summe der angesteuerten Motore auf sich hat. Könntest du das bitte noch etwas näher ausführen.

Ansonsten hab ich das Prinzip sowei verstanden, kann mir auch gut vorstellen das das mit einer Linearbewegung funktioniert, aber bei Circ habe ich so meine Zweifel...Grund dafür sind die Richtungsänderungen der Achsen.
Bei einer Linearfahrt laufen alle Achsen in eine bestimmte Richtung, ich beschleunige am Startpunt und Bremse am Zielpunkt ab. Je nach Bahn könnte ein oder zwei Achsen nicht mit maximaler Geschwindigkeit laufen.
Wenn ich dieses Prinzip auf eine Kreisbahn übertrage, beschleunige ich auch am Anfang und bremse am Schluss ab. Aber hier habe ich zwischendurch Richtungswechsel der Achsen. Vor diesen Richtungswechsel müssen die Achsen abgebremst werden, um einen Schrittverlust zu vermeiden. Passiert dieses dann automatisch auf Grund der geringen Streckenänderungen?
Ich meine kann es sein das die Motoren durch eine Reihe von Nullimpulsen (alternative Motoren machen einen Schritt, der Motor mit Richtungswechsel macht keinen) wegen der geringen Streckenänderung automatisch abgebremst werden?

Gruß

Zitat:

---

Zitat von Joe23

Wenn ich dieses Prinzip auf eine Kreisbahn übertrage, beschleunige ich auch am Anfang und bremse am Schluss ab. Aber hier habe ich zwischendurch Richtungswechsel der Achsen. Vor diesen Richtungswechsel müssen die Achsen abgebremst werden, um einen Schrittverlust zu vermeiden. Passiert dieses dann automatisch auf Grund der geringen Streckenänderungen?

---

Bei einem Kreis fahren beide Motoren je einen Sinus, und solange dessen Frequenz nicht zu hoch ist sehe ich da keine Notwendigkeit für zusätzliche Maßnahmen (denn zum Zeitpunkt der Richtungsänderung ist die Geschwindigkeit eh 0).

Hi Felix,

Heist das du änderst die Timerintervalle nach deiner Startbeschleunigung des Kreises nicht mehr, sondern lässt diese bis zum Abbremsen konstant?
Die Ansteuerfrequenz deiner Motoren liegt dabei über der Start- Stop-Frequenz? (D.h ohne eine Bremsrampe kommt es bei einem sofortigen Stillstand oder Richtungswechsel zu Schrittverlusten)

Noch mal kurz als Hintergrund: Ich habe hier einen Delta-Roboter mit 3 rotatorischen Achsen versetzt im 120 Grad Winkel. Wenn der Endeffektor einen Kreis in einer 2D-Ebene abfahren will, müssen sich alle 3 Achsen gleichzeitig bewegen. Ob dies ein reiner Sinus ist, wag ich zu bezweifeln. Spielt aber auch keine Rolle, da das Ansteuerprinzip ja übertragbar sein muss...

Gruß

moin moin,

bei einem Kreis wird ein Motor mit Sinus der andere mit Cosinus angesteuert.
Im Bereich des Richtungswechsel ist die Schrittfrequenz sehr gering, da habe ich nichts extra progammiert.

>>Wenn der Endeffektor einen Kreis in einer 2D-Ebene abfahren will, müssen sich alle 3 Achsen gleichzeitig bewegen

damit ich das richtig verstehe mach mal bitte ne Zeichnung oder Foto.

Das mit der Wurzel aus der Summe der angesteuerten Motore:
1 Motor (X) => ein Schritte in der Ebene
2 Motor2 (XY) => ein Diagonalschritt in der Ebene..und der ist SQRT(2) länger
3 Motore(XYZ) => ein Schritt im Raum..und der ist SQRT(3) länger.

Kann es sein das Deine 3 Achsen alle in einer Ebene werkeln?

Mit Gruß
Peter

Hallo Peter1060,

anbei zwei Auszüge aus dem CAD von dem Delta Roboter. In der oberen Hauptplatte sind 3 Motoren im Winkel von 120 angebracht. Diese 3 Motoren befinden sich in einer gemeinsamen Ebene. An jedem der Motoren ist ein Ausleger angebracht, sowie ein Parallegestänge. Dieses läuft unten beim Endeffektor zusammen. Über eine rotatorische Bewegung kann der Endeffektor in Richtung der Motorachse verschoben werden. Die Verbindungen von Endeffektor und Ausleger sind Kugelgelenke, also kann sich bei den beiden stillstehenden Achsen das Gestänge passiv bewegen. Der Endeffektor macht somit eine Kreisbahn abhängig vom Radius des Gestänges.

Der Effekt des Parallegestänges ist, das egal wie die 3 rotatorischen Achsen zueinander stehen, der Endeffektor sich immer parallel zur Oberfläche befindet. Somit ist eine Bewegung in x, y, und z Richtung möglich.

Wenn ich nun den Endeffektor z.B. in die x-Richtung bewege, dann müssen alle 3 Achsen verfahren werden.

Was man nun einfach benötigt ist eine Rückwärtstransformation von x,y und z auf die 3 Achswinkel. Dies ist soweit kein Problem, diese Aufgabe habe ich schon bewältigt.

Vorteile von solchen Robotern sind wegen der parallelen Kinematik die Genauigkeit, und vor allen wegen den geringen bewegen Massen die Dynamik. Gerade im Industriesektor werden diese Delta-Roboter (Flexpicker) für höchste Zykluszeiten von Pick-und Place-Aufgaben eingesetzt. Da sind 4 Zyklen pro Sekunde bei einem verfahrweg von 500 mm keine Seltenheit.
Nachteile sind auf Grund des Aufbaus der eingeschränkte Arbeitsraum und die geringen Traglasten. Somit können natürlich auch externe Prozesskräfte z.B. beim Fräsen schlecht aufgenommen werden.

Ich habe mit einem Versuchsroboter angefangen, und sowohl die Rückwärtstransformation, als auch Linearbewegungen, Kreisfahren, PTP-Bewegungen softwartechnisch umgesetzt. D.h. ich habe bereits eine selbstgeschriebene funktionierende Software für die Ansteuerung solch eines Roboters.
Jetzt kommt das Aber:
Der Versuchsroboter war mit Modellbauservos aufgebaut. Neben der geringen Genauigkeit, der fehlenden Rückmeldung des aktuellen Winkels war hier vor allen eines Vorteilhaft, der Positionsregler. Hier habe ich mich nicht um Beschleunigungen, Schrittverluste, ect. kümmer müssen, sondern nur die Sollwinkelposition der Achse berechnet und dem Lageregler übergeben. Somit war eingentlich nur die Zeit undefiniert, wann der Endeffektor sein Ziel erreicht hat. Testweise wurde hier einfach mit Wartezeiten gearbeitet.
Somit war auch eine Kreisbahn kein Problem, denn die Bahn wurde einfach ein viele kleine Stücke zerlegt, über die Rückwärtstransformation der Sollwinkel der Achsen berechnet, und der Lageregler laufend mit einem neuen Sollwert aktualisiert, bis die Winkeländerung so groß war, das die Auflösung des Potis ausreichend war, automatisch eine Regelung der Differenz durchzuführen.

Hier ein Beispiel Video für einen Delta Roboter aus Youtube. Dieser setzt sich natürlich deutlich von den zahlreichen Hobbyversuchen ab.

http://www.youtube.com/watch?v=Gv5B63HeF1E

Gruß