Hallo! Vor längerer Zeit gab es hier mal eine interessante Diskussion, zu Schrittmotoren und Rampen. Leider finde ich sie nicht mehr, aber sie war in meinen Augen auch nicht zuende diskutiert. Dabei ging es nicht, wie in den zig anderen Posts darum, wie man Rampen effizient kodiert, oder ob man eine lineare, sin^2 förmige, ... Rampe benutzt. Wenn man lange gerade Wege fährt sind Rampen kein Problem, egal, welche Rampenform man benutzt. Der Punkt der Diskussion war folgender: In der Praxis, wird man aber viele kurze Liniensegmente fahren. z.B. kurvige Objekte, die sich nicht durch eine Kreisapproximation und die dazu passenden G-codes realisieren lassen. Diese Kurven werden dann durch viele kleine lineare Bewegungen approximiert, die durchaus in dem Bereich von <10 Schritten liegen, aber nur langsam ihre Bewegungsrichtung ändern. Wenn man sturr seine Rampe hoch und runter fährt, wird sich das Werkzeug sehr langsam bewegen, weit entfernt von der eingestellten Geschwindigkeit, wenn nicht sogar ruckelig. Eine pragmatische Lösung wäre, Richtungsänderungen zu interpretieren und bei einer zu grossen Abweichung die Rampen zu aktivieren. Wenn die Liniensegmente sehr klein sind, schlägt das aber auch fehl... man bekommt 90° knicke, z.B. bei 1 Schritt grossen Segmenten. Bei der Sache muss man natürlich in die Zukunft schauen, was aber bei einem typischen festen Fräsprogramm kein Problem sein sollte :-) Ich frage mich jedoch, ob es nicht näher an der Physik des ganzen geht und man nicht das ganze schlauer angehen kann. Ein angedachter Ansatz war es, aus dem G-Code eine ganz lange Liste mit Schrittfolgen (Inhalt für jeden Motor: 1*CW, 1*CCW, kein Schritt) für alle Achsen zu erstellen - völlig ohne Timingaspekte. In einem weiteren Schritt dachte ich, diese Liste (notfalls mehrfach) durchzugehen und auf Basis der physikalischen Aspekte (z.B. Trägheitsmomente) mit einer Timinginformation zu versehen. Man muss ein parametrisierbares Modell der Achsen bilden. Mag erstmal kompliziert klingen, aber so wild kann das doch nicht sein, wenn man mit einem einfachen Ansatz startet. Jede Achse hat eine gewisse Masse zu bewegen, die man als Paramter fürs Modell benutzen kann. Wenn man Effekte, wie Haftreibung mal aussen vorlässt, könnte man auf Basis dieser Masse jeder Achse einen 3D-Trägheitvektor berechnen und ins Timing für den nächsten Schritt eingehen lassen. Wenn für jede Achse der Drehmoment (meist abhängig von der Drehzahl) bekannt ist, kann man mit Hilfe des aktuellen Trägheitsvektors das Timing für den nächsten Schritt berechnen. Meine Gedanken sind da noch recht weit am Anfang. F=m*a... aber was nimmt man als a? Nur die letzten 3 Schritte zu benutzen um das a zu berechnen, wäre doch nicht zielführend, also wird man vermutlich über mehrere Schritte das ganze berechnen müssen und mitteln?! Grüße, Kai
Kai schrieb: > Ich frage mich jedoch, ob es nicht näher an der Physik > des ganzen geht und man nicht das ganze schlauer angehen > kann. Sicher kann man. Das Problem liegt aber tiefer: Diese ganze übliche statische Schrittbetrachterei ist im Grunde genommen Quatsch. "Der Motor steht irgendwie. Jetzt wird eine Wicklung bestromt. Der Strom steigt langsam an. ... " uswusf. Alles Blödsinn. Der Fehler liegt schon im ersten Satz. "Der Motor steht irgendwie" ist nur ein seltener Spezialfall des allgemeinen Zustandes "Der Motor bewegt sich mit einer bestimmten Geschwindigkeit". Die Energie, die dem System durch einen (den nächsten) Schritt zugeführt wird, geht zum einen Teil in das Überwinden der Reibung, und zum anderen Teil in die Änderung des Bewegungszustandes (vulgo: Beschleunigung). Man müsste als im Extremfall Schritt für Schritt schauen, welche Achse welche Kraft erfordert. Die Achse mit dem größten Kraftbedarf diktiert die Geschwindigkeit.
Wenn du es gut machen willst, wird das nicht einfach. In die vorauseilende Bahnplanung sollten eingehen v, v', v'', mögliche Beschleunigung, aktuelle Geschwindigkeit. Alle als Vektor natürlich. Für jeden Motorschritt, den du auslöst, mußt du mindestens soweit vorausrechnen, daß du bei der erlaubten Beschleunigung nit übers Ziel hinausschießt. Bei komplexeren Mechaniken als "nur" X-Y Maschinen wird die Sache mit den Massenträgheiten und der gegenseitigen Beeinflussung dann sehr -ähm- interessant. Bei Industriesteuerungen hilft es übrigens ungemein, die Anzahl der Bahnpunkte klein bzw. deren Abstand zueinander groß zu halten. Das vermeidet ein unnötiges Abbremsen wegen unfertiger Bahnplanung. Vergessen.. Definiere eine "Genauigkeitskugel", innerhalb derer sich dein TCP um die berechnete Bahn herum bewegen darf. Diese muß mindestens einen Schritt in jede Richtung deiner Maschine sein, wenn du Schrittmotore verwendest.
:
Bearbeitet durch User
Helge A. schrieb: > Für jeden Motorschritt, den du auslöst, mußt > du mindestens soweit vorausrechnen, daß du > bei der erlaubten Beschleunigung nit übers Ziel > hinausschießt. Mir ist gerade aufgefallen, dass hier ein kompli- zierterer Ansatz einfacher ist als ein einfacher. :) Wenn man einen Polygonzug betrachtet, hat man in den Knicken immer Beschleunigungsspitzen, weil sich ja die Bewegungsrichtung plötzlich ändert. Geht man jedoch von einem Spline aus, verteilt sich die Änderung auf viele Schritte, und es gibt keine Notwendigkeit für abrupte Änderungen der Bewegung.
Winziger, aber entscheidender Nachteil von Splines in Bearbeitungsmaschinen: Du weißt zwar, durch welche Begrenzungspunkte deine Maschine fährt - aber nicht genau, wo sie sonst lang fährt ;) Durch Berechnung über Genauigkeitskugel wird das besser beherrschbar, denke ich..??
Kai schrieb: > Vor längerer Zeit gab es hier mal eine interessante Diskussion, zu > Schrittmotoren und Rampen. > .... > Bei der Sache muss man natürlich in die Zukunft schauen, was aber bei > einem typischen festen Fräsprogramm kein Problem sein sollte :-) Was mir bei den vielen "Rampendiskussionen" durch den Kopf geht ist, daß sie sich nur mit den Motoren beschäftigt. An anderer Stelle wird gesagt, ein Fräser sollte immer mit einer möglichst optimalen Schnittgeschwindigkeit arbeiten. Was ist eigentlich wichtiger, die Motorrampe oder die Schnittgeschwindigkeit? MfG Klaus
Hallo Klaus, kommt ganz drauf an. So lange der Motor den Schritten folgen kann, würde ich dazu tendieren die Schnittgeschwindigkeit als wichtiger anzusehen. Allerdings hilft diese Betrachtung nur bedingt, wenn einer der Schrittmtoren durch ständige Änderungen seiner Schrittrate zum Schwingen angeregt wird. Dann bekommst du schöne Rattermarken ins Werkstück. Bei WinPCNC wird meines Wissens nach der Eigangs diskutierte Ansatz (Winkel zwischen den Geradenstücken) verwendet, der Winkel ist als Parameter einstellbar. Aufgabe des CAM-Systems ist es, die Daten so aufzubereiten, dass ein Kreis nicht in ein n-Eck zerfällt, dessen einzelne Kanten nur noch einen Schritt groß sind. So genau sind die meisten Fräsen mit Schrittmotoren ohnehin nicht, dass man einen einzelnen Motorschritt wirklich am Werkstück sehen könnte. Erst recht nicht, wenn mit Mikroschritt gearbeitet wird. Mit freundlichen Grüßen Thorsten Ostermann
Helge A. schrieb: > Du weißt zwar, durch welche Begrenzungspunkte deine Maschine fährt - > aber nicht genau, wo sie sonst lang fährt ;) die Segmente sind ja normalerweise auch nur die Näherung für eine Kurve, von daher wird ein Spline daher sogar besser die Kurve annähern (solange keine Knicke in der gewünschten Kurve sind)
Helge A. schrieb: > Winziger, aber entscheidender Nachteil von Splines in > Bearbeitungsmaschinen: > > Du weißt zwar, durch welche Begrenzungspunkte deine > Maschine fährt - aber nicht genau, wo sie sonst lang > fährt ;) Hmpf. Ich merke gerade, dass ich "Spline" geschrieben habe, aber Bezierkurve vor Augen hatte. Zum Ausdruck bringen wollte ich nur: Geraden-Interpolation wird man sowieso implementieren. Nun besteht die Verführung, die Kreisbögen (über den Weg des Polygonzuges) auf Geraden zurückzuführen. Das scheint mir aber nicht sehr clever, denn man bekommt das Problem, dass sich die Beschleunigung (und damit der Kraftbedarf) in den Knicken konzentriert. Man sollte wohl Basisfunktionen wählen, die stetig differenzierbare Übergänge zulassen. Ich finde Thorstens Bemerkung mit dem Winkel zwischen den Geradenstücken zwar interessant, komme aber mit der Mathematik nicht zurande: Bei einem Knick in der Bahn springt schon die Geschwindigkeit, d.h. die Beschleunigung nimmt beliebig hohe Werte an... ?! > Durch Berechnung über Genauigkeitskugel wird das besser > beherrschbar, denke ich..?? Ich verstehe leider nicht, was damit gemeint ist. - Läuft das auf eine Art Bresenham-Algorithmus hinaus? Übrigens sehe ich da keine Widerspruch. Das eine Thema ist, dass die Steuerung den aktuellen Bahnabschnitt vorausberechnen kann, das andere, die Entscheidung zu treffen welche Achse wann einen Schritt machen muss. Das baut ja aufeinander auf.
Walter schrieb: >> Du weißt zwar, durch welche Begrenzungspunkte deine >> Maschine fährt - aber nicht genau, wo sie sonst lang >> fährt ;) > > die Segmente sind ja normalerweise auch nur die Näherung > für eine Kurve, von daher wird ein Spline daher sogar > besser die Kurve annähern Normalerweise, ja. > (solange keine Knicke in der gewünschten Kurve sind) Ja... hihi... das ist aber für eine CNC-Fräse eine entscheidende Einschränkung. Frei nach Ford: "Auf dieser Fräse können Sie jedes Teil herstellen, vorausgesetzt, das Teil ist rund!" :) Aber warte mal...das wird ja durch die Werkzeugkorrektur sichergestellt, dass die Bahnkurve in den meisten Fällen tatsächlich verrundet ist... hmm. Splines haben praktisch noch den anderen Nachteil, dass alle Segmente miteinander wechselwirken. Man muss also zuerst ein Gleichungssystem für die gesamte Bahn lösen.
Man kann auch mit stückweiser linearer Bahninterpolation (also mit Lagrangepolynomen 1. Ordnung) recht sinnvoll Geschwindigkeits- und Beschleungigungsberechnungen machen. Man muß nur für die 1. Ableitungsordnung mit Interpolieren, indem man in den Stützpunkten neben der Position auch die Normale mit hinterlegt. Das läßt sich dann der effizient berechnen. Dummerweise ist im G-Code, außer in G3-Kreisabschnitten, keine Normale hinterlegt, sondern muß wieder (mehr oder weniger sinnvoll) aus den Positionsdaten interpoliert werden. In den G3/G4-Abschnitten kann man sie ja problemlos mit einer frei gewünschten Diskretisierung berechnen. Viele Grüße W.T.
Klaus schrieb: > Was ist eigentlich wichtiger, die Motorrampe oder > die Schnittgeschwindigkeit? Das ist doch kein Gegensatz. Kais Idee ist doch gerade, dass sich die meisten "Motorrampen" aufgrund physikalischer Betrachtungen "von selbst" aus der gewählten Bahnkurve ergeben! Man muss überhaupt keine künstlichen Motorrampen hineinrechnen! Die Steuerung muss nur sicherstellen, dass die Grenzen der Maschine (max. Beschleunigung usw.) nicht überschritten werden. Das hat Thorsten ja schon erklärt.
So, sorry, musste arbeiten, daher erst so spät ein Reply. Super Feedback, Danke :-) Ja, die Schnittgeschwindigkeit ist wichtig. Auch, dass der Schnitt nicht "Ruckelig" erfolgt. Jede Maschine hat Ihre Limits, was die maximale Geschwindigkeit, Beschleunigung, etc... angeht. Darum kann man oft nicht konstant mit der eingestellten Geschwindigkeit verfahren. Wie jemand hier erwähnte, dominiert die limitierende Achse die Gesamtgeschwindigkeit. Ich habe etwas Backgroundwissen, was inverse kinematik bei Robotern betrifft, Lagrange, Singularitäten, usw. Allerdings nicht so weit, dass man noch die Trägheitsmomente, etc... explizit mit berücksichtigt habe. Implizit ergibt sich das bei einem Closed-Loop System jedoch von selbst, weswegen auch bei CNC Maschinen Servomotoren recht praktisch wären. Zum Glück sieht die Sache bei einem Kreuztisch aber einfacher aus => Keine Singularitäten :-) Ja, der Ansatz sollte sein zu jedem Zeitpunkt den Drehmoment berechnen zu können, die der Motor aufwenden muss, um den nächsten Schritt auszuführen. Invers gesehen kann man dann die Zeit für den nächsten Schritt so wählen, dass der Drehmoment einen gewissen Wert nicht übersteigt. Die Definition von "Der Motor steht" ist in der Tat schwer. Die Schritte haben immer einen gewissen zeitlichen Abstand. Wie gross ist dieser, um sagen zu können "Der Motor steht". Schwer möglich. Daher würd ich das nicht als Sonderfall betrachten wollen. Meine Grundidee war es, die Massen, die die Achsen bewegen müssen für die Trägheit im Modell zu berücksichtigen. Erscheint mir irgendwie sinnvoll. Bei meiner Maschine z.B. trägt jede Achse wiederum die nächste, d.h. die Z-Achse hat die geringste Masse zu bewegen. Hier wurde z.B. v, v', v'' in den Raum geworfen. Wie würdet Ihr an die Werte kommen? Egal, ob man einen Ansatz über Trägheitsmomente, oder Energie benutzt, man benötigt eine Beschleunigung v'. Um v zu berechnen, benötige ich 2 Punkte, um v' zu berechnen 3 von jeder Achse. Reicht das wirklich aus? Muss mann eine Mittelung durchführen? Was, wenn harte Richtungswechsel erfolgen? Die Maschine soll G-Code verarbeiten und nicht irgendwelche Spezialkonstrukte, wie Splines als Input benutzen. Evtl. kann man das Problem erstmal andersrum betrachten: Ich habe eine Tabelle mit Zeitwerten und Schritten für jede Achse. Wie berechne ich den Drehmoment, den jeder Motor aufwenden muss zu jedem Zeitabschnitt? Als Eingabewerte jeweils die von jedem Motor zu bewegende Masse (Haft / Gleitreibungseffekte ignoriert). Oder hilft es erstmal eine einzelne Achse zu betrachten und davon ausgehend eine Lösung für 3 Achsen zu erarbeiten? Werd mir später nochmal intensivere Gedanken dazu machen und posten. Grüße, Kai
Kai schrieb: > Hier wurde z.B. v, v', v'' in den Raum geworfen. Wie > würdet Ihr an die Werte kommen? Ich versteh' Dein Problem nicht. - An die Werte kommst Du über die Bahnkurve. Jetzt frag' bitte nicht, wie Du an die Bahnkurve kommst. Die wird natürlich vom Bearbeitungsprogram (also der Folge der g-Befehle) definiert. > Egal, ob man einen Ansatz über Trägheitsmomente, oder > Energie benutzt, man benötigt eine Beschleunigung v'. > > Um v zu berechnen, benötige ich 2 Punkte, um v' zu > berechnen 3 von jeder Achse. Nein ! <mode="Gebetsmühle"> Du benötigst 1. die Bahngeschwindigkeit (also den "Vorschub") und 2. die Bahnkurve! Beides steht im Bearbeitungsprogramm! </mode> Man kann die Bahnkurve als parametrische Kurve auffassen; freier Parameter ist die Zeit. Die Komponenten geben direkt Ort über Zeit an. Einmal nach der Zeit abgeleitet gibt Geschwindigkeit. Nochmal nach der Zeit abgeleitet gibt die Beschleunigung. > Die Maschine soll G-Code verarbeiten und nicht irgendwelche > Spezialkonstrukte, wie Splines als Input benutzen. Du hast das Prinzip nicht verstanden. Die Maschinensteuerung muss zwischen den Koordinaten, die im Bearbeitungsprogramm ("G-Befehle") stehen, interpolieren. Das heißt: Sie muss mit einem festen Algorithmus herausfinden können, wie sie vom Startpunkt zum Zielpunkt kommt. Für diese Interpolation gibt es mehrere Möglichkeiten. Eine (schlechte) Möglichkeit ist lineare Interpolation. Eine weitere (schlechte) Möglichkeit sind Splines. Noch eine (etwas bessere) Möglichkeit sind Bezier-Kurven. Man kann auch eine Fallunterscheidung machen und Geraden direkt als Geraden, Kreisbögen direkt als Kreisbögen behandeln. Das hat aber den Nachteil, dass man in Echtzeit mit den Winkelfunktionen herumhantieren muss. > Ich habe eine Tabelle mit Zeitwerten und Schritten für jede > Achse. Nein! Die hast Du nicht! Du hast etwas wie "G03 X20 Y30 I-15 J15" > Wie berechne ich den Drehmoment, den jeder Motor aufwenden > muss zu jedem Zeitabschnitt? Indem Du ein Mathematikbuch hernimmst und Dich informierst, wie die erste und zweite Ableitung beim Kreis zu berechnen sind (Parameterdarstellung verwenden). Vielleicht ist auch ein Lehrbuch in Maschinendynamik nützlich; das steht was über stoß- und ruckfreie Bewegungen. Befass' Dich mal mit Parameterkurven und Interpolation.
Possetitjel schrieb: > hat aber den Nachteil, dass man in Echtzeit mit den > Winkelfunktionen herumhantieren muss. Die man allerdings auch oft durch den Einsatz von Vektoralgebra vermeiden kann. Skalarprodukt und Kreuzprodukt lassen grüssen. Um Wurzelziehen kommt man allerdings meistens nicht herum.
Karl Heinz schrieb: >> hat aber den Nachteil, dass man in Echtzeit mit den >> Winkelfunktionen herumhantieren muss. > > Die man allerdings auch oft durch den Einsatz von > Vektoralgebra vermeiden kann. Skalarprodukt und > Kreuzprodukt lassen grüssen. Stimmt. Bresenham funktioniert ja auch für Kreise. Das ist ja direkt die "diskretisierte" Version. > Um Wurzelziehen kommt man allerdings meistens nicht > herum. Irgendwas ist immer :) Insgesamt nettes Gebiet. Viele Kurven und nicht zu komplizierte Mathematik ;-)
Kai schrieb: > Ich frage mich jedoch, ob es nicht näher an der Physik des ganzen geht > und man nicht das ganze schlauer angehen kann. Das war damals schon das Ergebnis der Diskussion: Alle Kommandos nacheinander aufschreiben, also look-ahead. Jede Achse für sich betrachtet nach maximaler Beschleunigung (und damit minimalem Zeitabstand der Schritte) durchrechnen. Es ergeben sich ZWEI Geschwindigkeitsprofile, und als drittes kommt die Fräsgeschwindigkeit je nach Werkzeug dazu. Aus den dreien gibt der kleinste Werte das Tempo der Strecke vor, aus dem man dann die realen Zeitabstände der Schritte bestimmt. So macht das Mach3 und all die anderen besseren Fräsprogramme. Die Frage ist, ob mna das vor dem Fräsen berechnen muss, oder ab man es mit den gepufferten G-Code machen kann: Hat man keine vorweg gespeicherten, muss man eine Bremsrampe annehmen, kommen dann Daten, kann man die Bremsrampe, falls man ihren Beginn noch nicht erreicht hat, wieder neu berechnen.
Possetitjel, keine Sorge, ich bin nicht verdummt. Hatte nur ein bisschen Hoffnung, dass andere sich an der Diskussion mit beteiligen, weil es sie interessiert :-) Dieser Ansatz mag evtl. schon existieren, aber ich habe bisher noch nichts im Hobbybereich davon gesehen. Scheinbar alle fahren festgelegte Rampen, mit den oben beschriebenen Problemen. Von der Physik der Maschine auszugehen erscheint mir hier als die Ideale Lösung. Im ersten Post steht doch, dass ich jeden Schritt einzeln betrachte. Wie ich dazu komme, auch bei 3D geraden, ist mir klar, ich habe schon vor 15 Jahren die erste CNC Bohrmaschine selber gebaut und damals noch in Assembler auf nem Z80 programmiert programmiert, inklusive Kreisinterpolation, etc.. ohne Floating point, hochgestochene Trigometrischen Funktionen, Arduinos, usw. Was die Physik angeht, bin ich etwas weiter. Manchmal fehlt einfach Zeit sich mal über etwas intensiver Gedanken zu machen und das Problem wird für komplexer gehalten, als es ist. Fm = M * 2 π / h, mit h = Spindelsteigung [m] Herleitung ist einfach, poste ich jetzt mal nicht ...beschreibt die Kraft, die der Motor bei einem bestimmten Drehmoment auf den Schlitten ausübt. Fs = m*a beschreibt die Trägheitskraft, die bei einer Beschleunigung des Schlittens entsteht. Fm ist als Limit anzusehen, Fm muss darunter liegen und das "a" dementsprechend angepasst werden. Wenn man nur mal eine einzige Achse betrachtet: Sagen wir, die Achse macht einen Schritt nach links (-1), dann direkt danach nach rechts (+1), bzw. als Tabelle: t Schritt 0 0 1 0 2 0 3 -1 4 +1 5 0 Was ist die Beschleunigung zu den diversen Zeitpunkten? Viele Grüße, Kai PS: Mir ist klar, das es noch andere Kräfte gibt, wie z.B. Haft- und Gleitreibung an einigen Stellen, Kraft durch den Fräser im Material, ...
Kai schrieb: > keine Sorge, ich bin nicht verdummt. Das hatte ich, glaube ich, auch nicht behauptet. > Scheinbar alle fahren festgelegte Rampen, mit den > oben beschriebenen Problemen. Von der Physik der > Maschine auszugehen erscheint mir hier als die > Ideale Lösung. Mir nicht. Die Maschine ist kein Selbstzweck, und die "festgelegten Rampen" auch nicht. Die "Rampen" schreibt das Fräsprogramm, also die Folge der G-Befehle vor. > Im ersten Post steht doch, dass ich jeden Schritt einzeln > betrachte. Gut. Dann habe ich Dich missverstanden und klinke mich hier aus: Es ist sinnlos, jeden Schritt einzeln zu betrachten, denn dieser "Schritt" existiert physikalisch nicht. Warum das so ist, habe ich in meiner allerersten Antwort zu erklären versucht. Deine Beiträge haben mich dennoch auf ein interessantes Teilproblem hingewiesen: Wenn Bahndatenverarbeitung und Motorsteuerung in zwei getrennten Baugruppen erfolgt, dann ist es wünschenswert, dass die Motorsteuerung das Einhalten aller Grenzwerte in Echtzeit prüfen kann. > Sagen wir, die Achse macht einen Schritt nach links (-1), > dann direkt danach nach rechts (+1), Die Achse macht im physikalischen Sinne keine Schritte. > bzw. als Tabelle: > > t Schritt > 0 0 > 1 0 > 2 0 > 3 -1 > 4 +1 > 5 0 > > Was ist die Beschleunigung zu den diversen Zeitpunkten? Begriffsbildungen aus dem Stetigen (Ableitung) auf diskrete Objekte (Schritte) anzuwenden ist mathematisch ein grober Fehler und anschaulich sinnlos. Weitere Diskussion für mich ohne Nutzwert.
Du redest eigentlich nur von der Interpolation der Geraden, ausser kurz in einem Post. Einzelne Schritte existieren evtl. nicht, zumindest ab einer gewissen Schrittfrequenz, wegen der Massenträgheit. Zeig uns doch einen anderen Ansatz, der nicht die einzelnen Schritte betrachtet.
Possetitjel schrieb: > Karl Heinz schrieb: > >>> hat aber den Nachteil, dass man in Echtzeit mit den >>> Winkelfunktionen herumhantieren muss. >> >> Die man allerdings auch oft durch den Einsatz von >> Vektoralgebra vermeiden kann. Skalarprodukt und >> Kreuzprodukt lassen grüssen. > > Stimmt. Bresenham funktioniert ja auch für Kreise. > Das ist ja direkt die "diskretisierte" Version. Für mich hat es da weiter oben so geklungen, als ob man sich die Eckpunkte eines Polygons ansehen sollte um zu entscheiden, ob man mit dem 'Zug' über diesen Eckpunkt drüber fährt, oder ob da jetzt ein neuer Linienzug beginnt, so dass man abbremst und in eine andere Richtung neu beschleunigt. Dazu rechnet man sich den Winkel zwischen den beiden Richtungsvektoren aus und wenn der größer als ein Grenzwinkel ist, dann wird abgesetzt. Ansonsten fährt man einfach ohne Bremsen über den Eckpunkt drüber oder man verbindet die so gefundenen 'Nicht-Bremspunke' mit einer Bezier-Linie oder wie auch immer. Springende Punkt: selbst gestandene Mathematiker(*) rechnen dann wirklich mit den Arcus-Funktionen die Winkel aus und vergleichen die, wenn alles was man dazu braucht einmal Skalarprodukt und ein Kreuzprodukt (nur das Vorzeichen der Z-Komponente) ist. Gänzlich ohne Winkelfunktion und das ganze Gesocks, das man hat, weil der Kreis bei 360° ja wieder zu 0° wird. Speziell letzters ist des öfteren dann tatsächlich so unangenehm, wie Hämorrhoiden bei der Büroarbeit. (*) speziell studierte Mathematiker gehen da oft recht gerne sehr naiv an die Sache ran und schmeissen wie die Wilden mit Winkelfunktionen um sich.
:
Bearbeitet durch User
Possetitjel, ich wollte Dich nicht vergraulen. Zeig doch einen anderen Ansatz auf. Ich bin offen für andere Ansätze, oder einer konkreten Begründung, warum der gezeigte falsch ist. Ich bin nicht frei von Fehlern und lerne gerne dazu. Ich gehe nicht unbedingt davon aus, dass die Schritte physikalisch existieren. Es ist eine Quantisierung in der Ansteuerung. Warum lässt sich an ihnen keine Geschwindigkeit oder Beschleunigung ablesen? In der Tabelle: > t Schritt > 0 0 > 1 0 > 2 0 > 3 -1 > 4 +1 > 5 0 wird z.B. zwischen Zeitpunkt 3-4, 4-5, 5-6 beschleunigt (davon ausgehend, dass z.B. der Schritt -1 exakt zum Zeitpunkt 3 ausgeführt wird). Das sollte doch so auch an der Achse zu merken sein. Wenn ich mit Splines / Bezierinterpolationen arbeite, wird das Programm doch nicht mehr 100% an dem definierten Weg abgefahren. Spitze Ecken werden gerundet - je nach Parametrisierung, etc. Das sorgt natürlich auch für eine Verbesserung der Situation => Beschleunigungen werden geringer, weniger Drehmoment nötig, ... Bei Schrittmotoren habe ich immer als Vorteil gesehen, dass sie exakt den definierten Weg abfahren.
Karl Heinz schrieb: > Possetitjel schrieb: >> Karl Heinz schrieb: >> >>>> hat aber den Nachteil, dass man in Echtzeit mit den >>>> Winkelfunktionen herumhantieren muss. >>> >>> Die man allerdings auch oft durch den Einsatz von >>> Vektoralgebra vermeiden kann. Skalarprodukt und >>> Kreuzprodukt lassen grüssen. >> >> Stimmt. Bresenham funktioniert ja auch für Kreise. >> Das ist ja direkt die "diskretisierte" Version. > > Für mich hat es da weiter oben so geklungen, als ob > man sich die Eckpunkte eines Polygons ansehen sollte Ach so, darauf beziehst Du Dich. - Ich wäre Thorsten sehr verbunden, wenn dazu nochmal was sagen könnte, denn... > um zu entscheiden, ob man mit dem 'Zug' über diesen > Eckpunkt drüber fährt, oder ob da jetzt ein neuer > Linienzug beginnt, so dass man abbremst und in eine > andere Richtung neu beschleunigt. ... hier ist der Punkt, den ich nicht verstehe: Wenn ich ein Polygon als Parameterkurve habe, dann habe ich immer Sprünge in den ersten Ableitungen (also der Geschwindigkeit), und an den Stellen ist die Beschleunigung undefiniert. Das ist unabhängig vom "Knickwinkel". Was übersehe ich? Auch wenn ich Deine Bemerkung über Vektoralgebra fehl- interpretiert habe, war sie mir trotzdem interessant: Der Bahndatenprozessor, der die Folge der G-Befehle vorverarbeitet, muss - wie ich nun gelernt habe - nix interpolieren, denn Geraden und Kreise kann man vektoriell recht elegant und gleichzeitig exakt behandeln. Die Controller für die einzelnen Achsen haben dagegen das Problem, dass sie jeweils nur eine Komponente des Vektors zu Gesicht bekommen, da ist also nix mehr mit Vektoralgebra. Dort wird Polynominterpolation nützlich sein, weil das einerseits numerisch einfach genug ist und andererseits Geschwindigkeit und Beschleunigung fast frei Haus liefert. [...] > Gänzlich ohne Winkelfunktion und das ganze Gesocks, > das man hat, weil der Kreis bei 360° ja wieder zu 0° wird. Aaaahhhhhhh...!!! Nicht dieses Thema! Bitte! :-)
Hallo Kai, > Ich gehe nicht unbedingt davon aus, dass die Schritte physikalisch > existieren. Es ist eine Quantisierung in der Ansteuerung. > Warum lässt sich an ihnen keine Geschwindigkeit oder Beschleunigung > ablesen? Klar geht das. Das Ergebnis hängt aber davon ab, ob du die Stützpunkte "Punkt zu Punkt" oder über Treppenstufen ("stairs") verbindest. Oder ob man der Argumentation von "Possetitjel" folgt und einen Spline durch die Stützpunkte legt. > In der Tabelle: > >> t Schritt v >> 0 0 0 >> 1 0 0 >> 2 0 0 >> 3 -1 -1 >> 4 +1 +2 >> 5 0 -1 >> 6 0 0 Man kann sich jetzt natürlich noch darüber streiten, ob "v" um einen Takt nach hinten verschoben werden muss. > > wird z.B. zwischen Zeitpunkt 3-4, 4-5, 5-6 beschleunigt (davon > ausgehend, dass z.B. der Schritt -1 exakt zum Zeitpunkt 3 ausgeführt > wird). > > Das sollte doch so auch an der Achse zu merken sein. Sicher, deswegen neigen Schrittmotoren ja zu Resonanzen. Insbesondere wenn sie im Vollschritt betrieben werden. > Bei Schrittmotoren habe ich immer als Vorteil gesehen, dass sie exakt > den definierten Weg abfahren. Das kommt immer darauf an, wie genau man hinsieht ;) http://www.schrittmotor-blog.de/die-bedeutung-des-lastwinkels-bei-schrittmotoren/ Mit freundlichen Grüßen Thorsten Ostermann
Thorsten Ostermann schrieb: >> Ich gehe nicht unbedingt davon aus, dass die Schritte >> physikalisch existieren. Es ist eine Quantisierung in >> der Ansteuerung. Warum lässt sich an ihnen keine >> Geschwindigkeit oder Beschleunigung ablesen? > > Klar geht das. Das Ergebnis hängt aber davon ab, ob du die > Stützpunkte "Punkt zu Punkt" oder über Treppenstufen > ("stairs") verbindest. Oder ob man der Argumentation von > "Possetitjel" folgt und einen Spline durch die Stützpunkte > legt. > >> In der Tabelle: >> >>> t Schritt v >>> 0 0 0 >>> 1 0 0 >>> 2 0 0 >>> 3 -1 -1 >>> 4 +1 +2 >>> 5 0 -1 >>> 6 0 0 Die Betrachtung hat nur zwei Probleme: 1) Es handelt sich um die mittlere Geschwindigkeit im Intervall. Wie die Momentangeschwindigkeit zu bestimmen ist, ist nicht klar. (Möglicherweise ist sie nicht mal definiert.) 2) Die mittlere Geschwindigkeit springt, also ist die Beschleunigung nicht definiert (="unendlich hoch"). Das ist recht ungünstig für die Auswahl der Motoren...
Kai schrieb: > Ich gehe nicht unbedingt davon aus, dass die Schritte > physikalisch existieren. Vielleicht ein rein begriffliches Problem: Was beim Schrittmotor exakt definiert ist, sind die möglichen Stellungen des Rotors, also die Positionen. Die Bewegungen des Rotors, also der Übergang von einer definierten Stellung zur nächsten, ist schlecht bis gar nicht definiert. Sie hängt sehr stark von der Art und Weise der Ansteuerung und von der Last ab. > Es ist eine Quantisierung in der Ansteuerung. Auch nicht wirklich. Beim Mikroschrittbetrieb versucht man, die Ströme stetig zu ändern, um eine gleichmäßige Bewegung zu erreichen. > Warum lässt sich an ihnen keine Geschwindigkeit > oder Beschleunigung ablesen? Weil für dynamische Betrachtungen nicht die exakt definierten Positionen , sondern die (beim Schritt- motor weitgehend undefinierten) Übergänge zwischen den Positionen wesentlich sind! Wenn Du im Garten stehst und den Ball in Deiner Hand in exakt 3 Sekunden in eine exakt 3m entfernte Grube befördern willst, dann gibt es mindestens 2 Möglichkeiten: 1) Du rollerst den Ball - wie beim Kegeln - mit einem leichten, eleganten Schwung in die richtige Richtung. Wenn Du die Kraft richtig dosiert hast, kullert der Ball gleichmäßig davon und fällt nach genau 3 Sekunden in die Grube. 2) Du nimmst Dir 2.9 Sekunden Zeit zum Zielen und schießt den Ball mit einem scharfen Schuss in die Grube. Im beiden Fällen ist zum Zeitpunkt 0s die Position 0m und zum Zeitpunkt 3s die Position 3m. Damit stimmt z.B. auch die berechnete mittlere Geschwindigkeit überein. Die reale Momentangeschwindigkeit sowie die Beschleuni- gungen und Kräfte sind aber völlig verschieden!
Hi Possetitjel, verstanden. Der Verlauf zwischen den Schritten ist nicht bekannt, da sind wir uns beide einig. Auch bei Mikroschrittansteuerung ist das nicht der Fall. Abgesehen davon, dass das eh nicht zu einem linearen Verlauf führt bei sinusförmiger Ansteuerung. So gesehen ist auch die Drehmomentsangabe - oder das chart bei Schrittmotoren eine Vereinfachung. Das Modell ist eine Vereinfachung. Gibt es Modelle, die exakter auf die Sache eingehen? Mit dem verschleifen von harten Ecken mittels splines, o.äh ist eher der Ansatz, dass man die Kräfte verändert, statt die Kräfte so anzupassen, dass die Ecken weiterhin "hart" sind. Wenn man ein closed-loop System hat, und es so ansteuert, dass ständig versucht wird einen vorgegebenen Pfad mit vorgegebener Geschwindigkeit abzufahren und die Motoren so stellt, dass sie sich dem Weg annähern, bekommt man den Fall mit dem Verschleifen (Thema Inverse Kinematik, Jakobimatrix, Bahnplanung, ...). Die Kräfte / Drehmomente dominieren den Weg, statt der Weg die Kräfte und Drehmomente. Ich hätte gern letzteres. Oder verdammt günstige Servomotoren als Ersatz :-) Grüße, Kai
Kai schrieb: > Das Modell ist eine Vereinfachung. Gibt es Modelle, > die exakter auf die Sache eingehen? Es gibt mit Sicherheit Literatur zur dynamischen Auslegung von Schrittantrieben; ich kann aber keine konkreten Quellen nennen. Aus meiner Sicht sind viele wichtige Punkte schon genannt worden. Wenn Du über Mikroschrittbetrieb bei Schrittmotoren mal nachdenkst, kannst Du Dich auch fragen, worin der fundamentale Unterschied zum Synchronmotor besteht. Ich sehe nämlich keinen. Sicher, die idealen Strangströme sind nicht sinusförmig, und die Polpaarzahl beim Schrittmotor ist sehr viel größer. Das sind wohl technische Unterschiede, aber einen wirklich fundamentalen Unterschied in der Funktionsweise sehe ich nicht. > Mit dem verschleifen von harten Ecken mittels splines, > o.äh ist eher der Ansatz, dass man die Kräfte verändert, > statt die Kräfte so anzupassen, dass die Ecken weiterhin > "hart" sind. Nun ja. Wozu braucht man harte Ecken? Für eckige Werkstücke jedenfalls nicht. - Warum nicht? Das Stichwort lautet "Werkzeugradium-Korrektur". Die Drehachse des Fräsers beschreibt einen Viertelkreis, und trotzdem wird die Ecke "hart". Eine eckige Werkstück- kontur bedeutet noch lange nicht, dass die Bahnkurve des Fräser-Mittelpunktes eckig werden muss. Das muss sie nicht! Glaub's oder glaub's nicht... :-) (Der schlimmste Fall tritt bei Kerben auf, die nur sehr wenig größer als der Fräserdurchmesser sind. Das ist ein echtes Problem, aber das ist wesentlich seltener als eckige Werkstücke.) > Die Kräfte / Drehmomente dominieren den Weg, statt der > Weg die Kräfte und Drehmomente. Nein, da haben wir uns missverstanden. Vergiss' zunächst bitte mal die Splines; das war eine Fehlzündung von mir. Wenn schon, dann Polynominterpolation. Weiter: Vom "rechten Weg" abzuweichen ist natürlich nicht zulässig; ich will ja kein "ungefähr ähnliches" Werkstück fräsen, sondern genau das, was auf der Zeichnung ist! Der Weg wird selbstverständlich durch die Koordinaten in den G-Befehlen diktiert, keine Frage. Die auftretenden Kräfte hängen aber außer vom Weg auch noch vom Vorschub ab! Die Motorsteuerung muss also prüfen "Schaffe ich diese Weg (diese Bahn) mit diesem Vorschub, oder schaffe ich das wegen begrenzter Kraft nicht?" Wenn sie merkt "Ohh, ich schaffe das nicht!", dann muss sie auf die Bremse treten und den Vorschub verringern, nicht den Weg ändern! Das machst Du doch hoffentlich beim Autofahren genauso... ? Diese Prüfung kann vor Fräsbeginn durchgeführt werden; man kann es aber auch in Echtzeit von der Motorsteuerung machen lassen (oder beides). Die Polynominterpolation ist lediglich ein numerisches Hilfsmittel, um die Berechnung zu vereinfachen bzw. besser in Echtzeit hinzubekommen.
Possetitjel schrieb: > "Werkzeugradium-Korrektur". Mist. Dämlicher Tippfehler... :) Kaufe ein "s". Überzähliges "m" zu verschenken.
Kein Probles :-) Also die Argumentation mit der Radienkorrektur gilt ja nur bei Aussenecken :-) Der Ansatz mit den Polynomen widerspricht meinem doch nicht. Aber irgendwie muss man halt erstmal an fie Polynome kommen. Ich werd mal etwas experimentieren und berichten. Zum Beispiel mit dem Autofahren: wenn ich langsam fahre, wird die Kurve eng genommen. Fahre ich schnell, wird sie weit ausgefahren. Da gibt es gluecklicherweise ne geschlossene Regelschleife.
Possetitjel schrieb: > Wenn man einen Polygonzug betrachtet, hat man in den > Knicken immer Beschleunigungsspitzen, weil sich ja die > Bewegungsrichtung plötzlich ändert Das stimmt nicht. Schließlich kannst du z.B. durch einen Spitzen Winkel fahren, indem du zur Spitze hin abbremst, i.e. die Geschwindigkeitkomponente in Richtung der Winkelhalbierenden auf 0 fährst und dann wieder in Gegenrichtung beschleunigst. Dann ändert sich die Bewegungsrichtung nicht "plötzlich" sondern genau so schnell, wie der Antrieb verträgt. Was willst du mit Beschleunigungsspitzen in den Knicken. Der Vorschub wird über die Zeit parametrisiert, so dass die Beschleunigung, i.e. die zeitliche Ableitung der Geschwindigkeit die zulässigen Werte nicht überschreitet.
Ihr habt denk ich beide Recht: Bei konstanter Geschwindigkeit hat man eine Beschleunigungsspitze. Wenn man sie schlau anpasst nicht.
Mike schrieb: > Das stimmt nicht. Schließlich kannst du z.B. durch einen Spitzen Winkel > fahren, indem du zur Spitze hin abbremst, i.e. die > Geschwindigkeitkomponente in Richtung der Winkelhalbierenden auf 0 > fährst und dann wieder in Gegenrichtung beschleunigst. Dann ändert sich > die Bewegungsrichtung nicht "plötzlich" sondern genau so schnell, wie > der Antrieb verträgt. Das ist das, was ich oben meinte. Hier wird auf die "Befindlichkeiten" des Antriebs eingegangen. Wie sieht es aber mit der Schnittgeschwindigkeit des Fräsers in diesem Fall aus? MfG Klaus
Mike schrieb: > Possetitjel schrieb: >> Wenn man einen Polygonzug betrachtet, hat man in den >> Knicken immer Beschleunigungsspitzen, weil sich ja die >> Bewegungsrichtung plötzlich ändert > > Das stimmt nicht. Meine Güte. Ich habe natürlich konstante Vorschubgeschwindigkeit vorausgesetzt, ohne das extra hinzuschreiben. Wenn man beliebige Abstriche am Vorschub zulässt, wird die ganze Diskussion sinnlos.
Klaus schrieb: > Das ist das, was ich oben meinte. Hier wird auf die > "Befindlichkeiten" des Antriebs eingegangen. Ja. Weil das die kritische Komponente ist. > Wie sieht es aber mit der Schnittgeschwindigkeit des > Fräsers in diesem Fall aus? Die wahre Schnittgeschwindigkeit setzt sich aus der Drehung des Fräsers (Größenordnung: m/s) und dem Vorschub (Größenordnung: mm/s) zusammen. Der Einfluß ist daher in den meisten Fällen vernachlässigbar. Schlechter ist schon die Tatsache, dass die Späne bei zu geringem Vorschub sehr dünn werden; mit genügend Pech fasst der Fräser nicht mehr (oder nicht gleichmäßig) und die Oberfläche wird beschissen. Das ist aber ein etwas komplexeres Thema, was zu Glück nur speziellen Fällen zum echten Problem wird.
Kai schrieb: > Also die Argumentation mit der Radienkorrektur > gilt ja nur bei Aussenecken :-) Hmm. Neee. Es gilt auch bei Innenecken, solange der Radius der Werkstückkontur deutlich größer ist als der Radius des Fräsers. Das muss man halt durch Auswahl eines geeigneten Fräsers sicherstellen. Ich will aber gar nicht prinzipienreiten: Es ist schon richtig, dass sich harte Ecken in der Bahnkurve zwar in sehr vielen, aber nicht in allen Fällen vermeiden lassen. Wenn ein nicht vermeidbarer Fall eintritt, hat man halt Pech gehabt und muss mit dem Vorschub heruntergehen. > Der Ansatz mit den Polynomen widerspricht meinem > doch nicht. Doch, in einem Punkt schon: Wenn man die Bahnkurve abschnittsweise durch Polynome beschreibt, dann kann man sich sehr einfach die Ableitungen des Polynoms besorgen - also die Geschwindigkeit und die Beschleunigung. Man muss diese Größen nicht numerisch aus Hunderten von Einzelschritten herausfummeln, sondern braucht nur die vier Koeffizienten des Polynoms zu betrachten. Genau deswegen habe ich Polynome vorgeschlagen ;-) > Aber irgendwie muss man halt erstmal an fie Polynome > kommen. Bei Geradenabschnitten ist es einfach - eine lineare Funktion ist auch ein Polynom. Bei Kreisbögen wird es in der Tat komplizierter; man braucht einen schlauen Zerlegungsalgorithmus, der die Abschnitte so wählt, dass einerseits mit dem Polynom die geforderte Genauigkeit erreicht werden kann, andererseits aber die Abschnitte nicht nur einen Schritt lang sind.
Hi! Ja, verstehe, was Du meinst. Die Polynomrechnerrei ist nur auch nicht unbedingt einfacher als einfach die diskreten Schrit-Zeit Wertpaare zu betrachten. Und ein Polynom berücksichtigt auch nicht den dynamischen Verlauf zwischen den Schritten. Ich experimentiere gerade in Matlab etwas und bin scheinbar auf einem guten Weg. Danach gehts direkt an die Maschine. Evtl. komm ich zu demselben Schluss, wie Du. Noch evtl. ein Diskussionspunkt: Bei positiven Beschleunigungen gibt es die Gefahr Schritte zu verlieren. Wie seht ihr das bei negativen Beschleunigungen (Bremsen)? Mein Gefühl sagt mir irgendwie, dass man da nicht "drüberrutscht", zumindest nicht, wenn man die rein statischen Zustände betrachtet. Grüße, Kai
Betrachtest du nur statische Zustände, verlierst du niemals Schritte ;) Da wir uns hier schön achsweise im dreidimensionalen Raum bewegen, reicht zur Überwachung des Maximalmoments am Kopf vermutlich die Momentenbegrenzung pro Achse aus - obwohl mir das nicht so gaanz geheuer ist. So lange wir allerdings den erlaubten Ruck (v'') im Auge behalten, dürfte das OK sein. Zum Glück erlaubt die Elastizität von Maschinen in der Regel, daß man zu jedem Zeitpunkt von einer halbwegs linearen Bewegung mit bestimmter Geschwindigkeit in eine bestimmte Richtung ausgehen kann. Die dafür notwendige Randbedingung ist "nur", daß die Schrittweite in die einzelnen Richtungen kleiner ist als die Elastizität der Maschine. Da weiter oben die Genauigkeitskugel nachgefragt wurde: Gebe ich meiner Bahnplanung als Parameter mit, daß ich eine gegebene Kurve mit z.B. 0,1mm Genauigkeit in x/y/z abfahren will, so darf die Bahnplanung halt bei einem Richtungswechsel bis zu 0,1mm von der exakten Kurve abweichen. Das könnten dann (Hausnummer) z.B. 18 Schritte in X sein oder 12 Schritte in X und in Y. Diese gewünschte Genauigkeit ist dann "Spielball der Bahnplanung" und wird benutzt zur Berechnung der Umorientierung. Erst wenn die Bahnplanung feststellt, daß die notwendige Beschleunigung bei der Umorientierung (innerhalb der Genauigkeit) außerhalb der Grenzwerte der Maschine liegt, muß abgebremst werden.
Helge A. schrieb: > Betrachtest du nur statische Zustände, verlierst du niemals Schritte ;) Naja, irgendwie schon. Etwas schlecht ausgedrückt. Wenn ich erwarte beim harten Abbremsen bei eine gewissen absoluten Wert zu stehen und tue es nicht, hab ich irgendwo was verloren.
sehr interessante Aspekte! http://www.schrittmotor-blog.de/die-bedeutung-des-lastwinkels-bei-schrittmotoren/ > Es gibt einen lastabhängigen Positionsfehler, der bis zu einem > Vollschritt betragen kann. Richtig ist: Es gibt einen lastabhängigen Positionsfehler, der bis zu plus-minus ZWEI Vollschritte (= plus-minus einem halben Großschritt) betragen kann. Ist die Abweichung größer, rastet der Motor in der nächsten Großschrittposition (= plus-minus 4 Vollschritte) ein. Thorsten, kannst Du das bitte korrigieren? > Wie seht ihr das bei negativen Beschleunigungen (Bremsen)? Mein > Gefühl sagt mir irgendwie, dass man da nicht "drüberrutscht", > zumindest nicht, wenn man die rein statischen Zustände betrachtet. Das Durchrutschen passiert beim Abbremsen genauso, allerdings kommen Reibungskräfte "zu hilfe".
Mathematik Student hier: Es gibt auch noch schöne Kombinationen aus den verschiedenen Vorschlägen hier. Ich kenne zum Beispiel unter dem Begriff "Interproximation" ein mathematische Problem mit vorgegeben Daten (z.B. aus G-Code erzeugte Positionsdaten) und vorgegeben maximalen Abweichungen von diesen Daten (die oben angesprochene Sicherheitskugel/Genauigskeitkugel). Jetzt gibt es Algorithmen die eine Funktion f liefern, die abschnittsweise als Polynom darstellbar ist. Die Abweichung von f zu den ursprünglichen Daten ist dabei kleiner oder gleich der zugelassenen Abweichung. Meistens wird dabei bezüglich eines bestimmten Aspekt optimiert/minimiert. Also zum Beispiel bezüglich der 2. Ableitung. D.h. die Funktion soll möglichst glatt sein. Anschaulich soll sich die Geschwindigkeit (1. Ableitung) möglichst gleichmässig ändern, also nicht ruckartig. Bereits durch kleine zugelassene Abweichungen kann man sehr viel glattere Funktionen erreichen. Ein weiterer Aspekt wenn man nur "normale" Interpolationen anwendet, ist das teilweise deutliche überschwingen. http://de.wikipedia.org/w/index.php?title=Datei:Spline_interpolation.svg&filetimestamp=20071210125345&; Hier sieht man teilweise, dass die Funktion zwischen zwei Stützstellen größere/kleinere Werte annehmen kann. Das ist in einer CNC Steuerung natürlich mehr als unerwünscht. Auch da gibt es sogenannte "Monotonie erhaltene" Algorithmen die so etwas berücksichtigen. Zusammenfassend denke ich, dass man mit der einfachsten Interpolation nicht so wirklich weit kommt. Es müssen schon angepasste Algorithmen verwendet werden, die zum Beispiel nicht zum überschwingen neigen, Monotonie erhalten sollen, die Beschleunigung nach oben begrenzen sollen, etc. Aus meiner Erfahrung kann ich sagen, dass solche Probleme nicht mehr mal eben so gelöst werden können, sondern schon ein wenig Rechenaufwand auf geeigneter Hardware (ich denke 8-bit ist ungeeignet) benötigen.
Hallo eProfi, > http://www.schrittmotor-blog.de/die-bedeutung-des-lastwinkels-bei-schrittmotoren/ >> Es gibt einen lastabhängigen Positionsfehler, der bis zu einem >> Vollschritt betragen kann. > Richtig ist: > Es gibt einen lastabhängigen Positionsfehler, der bis zu plus-minus ZWEI > Vollschritte (= plus-minus einem halben Großschritt) betragen kann. > Ist die Abweichung größer, rastet der Motor in der nächsten > Großschrittposition (= plus-minus 4 Vollschritte) ein. > > Thorsten, kannst Du das bitte korrigieren? Warum sollte ich? Deine Aussage ist falsch. So das Lastmoment kleiner ist als das Haltemoment des Motors, liegt der Positionsfehler unterhalb von +/-1 Vollschritt. Wir das Haltemoment erreicht bzw. überschritten, rastet der Motor aus. Wie kommst du auf +/-2 Vollschritte? Mit freundlichen Grüßen Thorsten Ostermann
Vielleicht hilft bei der Diskussion hier ein Blick auf die professionellen CNC-Steuerungen. Da betrachtet man die Anforderungen von Prozess und Antrieb getrennt und zwar nacheinander. Als erstes gibt es eine Bahnplanung, die sich darum kümmert, dass die Bahn entsprechend der parametrierten Randbedindungen eingehalten wird. Das beinhaltet auch ein Look-Ahead über die folgenden Programmsätze. Neben der Bahngenauigkeit ist auch die Beschleunigung (auf der Bahn!) ein wichtiger Parameter. Bereits hier kann es passieren, dass -z.B. beim Umfahren von Ecken- die Bahngeschwindigkeit reduziert werden muss, um Bedingung für die Bahnbeschleunigung nicht zu verletzten. Danach werden die Sollwerte (Stützpunkte) für die Antriebe generiert, und zwar incl. Geschwindigkeits- und Beschleunigungswerten. Hier wird dann nochmal geprüft, ob ggf. die maximalen Einstellungen der Antriebe überschritten werden. Dann wird die Geschwindigkeit aller Achsen entsprechend zurückgenommen. Der wesentliche Unterschied zwischen einer "echten" CNC und einer Schrittmotorsteuerung liegt darin, dass bei einer CNC Stützpunkten gerbeitet wird, die zeitlich in einem festen Raster liegen, aber vom Weg her unterschiedlich weit voneinander entfernt liegen können. Bei Schrittmotorsteuerungen ist es andersrum, die Zeit ist variabel, aber die Schrittweite immer gleich. Alles mal so aus dem Gedächnis runtergeschrieben. Details siehe Kapitel 7 in folgendem Buch: http://www.amazon.de/Werkzeugmaschinen-Automatisierung-Maschinen-Anlagen-VDI-Buch/dp/3642387470/ Mit freundlichen Grüßen Thorsten Ostermann
Hallo Thorsten,
ich bitte zu bedenken: wenn ein statisch bestromter Schrittmotor über
das Haltemoment belastet wird, rastet er in die nächste
Großschrittposition ein. Das ist um 4 Vollschritte weiter.
Stelle Dir vor, Du hast 4 Magnete, 3 feste (oben = Stator) und einen
beweglichen (unten = Rotor):
0123456789abcdef0 Halbschritte
0 1 2 3 4 5 6 7 8 Vollschritte
0 1 2 Großschritte
N N N
| | |
S S S
N ->
|
S ->
Du drückst den unteren nach rechts (oder links), das geht bis zum
Vollschritt 4+2=6 (oder 4-2=2), darüberhinaus fühlt sich der bewegliche
Magnet stärker vom nächsten Magneten angezogen und rastet dort ein.
Überzeugt? Wenn nicht, probiere es aus.
Das überzeugt mich nicht im geringsten. Wenn du den Motor über das Haltemoment hinaus belastest, kannst du den Fehler nicht mehr quantifizieren. Kein Mensch garantiert dir, dass der Motor nur 4 Vollschritte weiterspringt und nicht 8, 16 oder noch viel mehr. Wo du da die +/-Vollschritte siehst hast du damit übrigens auch noch nicht begründet. Vielleicht solltest du dich mal praktisch damit beschäftigen? Ich mache das seit über 10 Jahren... Die Fehlerbetrachtung gilt für den Normalbetrieb, also Last<Motormoment. Und da gilt, dass der Winkelfehler +/- 1 Vollschritt sein kann. Den Begriff "Großschrittposition" gibt es übrigens nicht. Goggle findet dazu genau einen Treffer, und das ist dieser Thread. Ich bevorzuge es, mit etablierten Begriffen zu arbeiten. Dann weiss wenigstens jeder was gemeint ist. Also 4 Vollschritte oder eine elektrische Umdrehung. Mit freundlichen Grüßen Thorsten Ostermann
:
Bearbeitet durch User
Ich hab jetzt mal eine Zeit mitgelesen, weil ich fast das selbe Problem habe greife ich den Thread nochmal auf. Angenommen die Fräse will um eine Ecke fahren. Dazu fährt erst der Fräskopf in die X-Achse (beliebig angenommen), erreicht die Ecke und fährt dann in die Y-Achse. Leider erlaubt die Trägheit das nicht und der Fräskopf schießt über das Ziel hinaus. Nicht gut. Habe mir mal auf dem Papier überlegt wie man sowas lösen kann. Mein erster Ansatz war dass die Geschwindigkeit langsam heruntergefahren wird. Während dieser Zeit wird das abfahren der Punkte pausiert, sprich das System erzeugt neue Zwischenpunkte und erst wenn diese wieder mit der geplanten Bahn übereinstimmen fährt das ganze weiter. Damit hätte man aber nur den Overshoot verhindert, die Beschleunigung ist noch nicht berücksichtigt und auch die zweite Achse ist damit nicht synchronisiert. Kann man nicht irgendwie (vorausgesetzt man kennt den Pfad lange im voraus) erreichen dass die Position exakt den vorgegeben Werten folgt und ein Geschwindigkeitslimit sowie ein Beschleunigungslimit nicht überschritten wird?
Ja, kann man. Das ist alles in der o.a. Fachliteratur erläutert. Was man dagegen nicht kann, ist die Geschwindigkeit konstant zu halten und gleichzeitig konturgenau um die Ecke zu fahren. Irgendeinen Tod muss man da sterben, Geschwindigkeit verringern oder einen gewissen Fehler zulassen. Mit freundlichen Grüßen Thorsten Ostermann
Noch nicht genannt wurde die Moeglichkeit, die Drehzahl vom Werkzeug zu variieren: Wenn man in einer Kurve abbremsen oder sogar einen Genauhalt fahren muss, kann man doch das Werkzeug mit abbremsen, um auch die Schnittparameter im zulaessigen Bereich zu halten. Ist das unzulaessig, hat es gravierende Nachteile, die ich uebersehe?
Also ich habe auch schon ein CNC Steuerung Programmiert, und hatte die Probleme auch mit den Rampen. Die Rampen müssen direkt in der Interpolator-Routine integriert werden. Also direkt im NC-Kern. Einfach mal irgendwie losfahren und evtl. bei bedarf die Rampen Einschalten funktioniert nie !! Der Interpolator-Routine werden dann folgende Informationen übergeben: - Soll Position - Soll Vorschub - End-Vorschub (Soll Vorschub am ende der Positionierung) Bevor die Achsen losfahren, muss also bekannt sein, was am ende des Satzes geschieht. Wird danach zB. die Richtung stark geändert, ist der End-Vorschub = 0. Der Interpolator errechnet während der Positionierung ständig die Entfernung zur Sollposition. Die länge der Rampe (in Schritten) ist anhand der Beschleunigung und dem aktuellen Vorschub ebenfalls bekannt. Nun ist relativ einfach zu berechnen, zu welchem Zeitpunkt die Rampe eingeleitet werden muss, damit genau bei der Soll-Position, der End-Vorschub erreicht wird. Das ganze Prinzip hat weiter den Vorteil, das relativ einfach während einer Positionierung der aktuelle Vorschub manuell geändert werden kann -> Vorschub-Override. Noch was: Die Rampen müssen nicht einzeln pro Motor errechnet werden. Im Interpolator werden einfach anzahl Schritte errechnet, die für die Verzögerung benötigt werden. Beispiel: Die Rampe benötigt 10 Schritte. Fährt die X-Achse mit einem Vorschub von 100mm/min, wird während der Verzögerung nach jedem Schritt die Geschwindigkeit schrittweise verringert. Wird ein 45° Winkel gefahren, fahren die X- und Y- Achsen bei genauem hinschauen eine "Treppe". Der Werkzeug Vorschub ist immer noch 100mm/min, der Vorschub der einzelnen Achsen ist dem entsprechen kleiner. Bei der Verzögerung werden Total immer noch 10 Schritte benötig, bei der 45° Interpolation, sind nun für beide Achsen je 5 Schritte übrig. Bei der Kreisinterpolation ist das Prinzip genau das gleiche. Ist also gar nicht so schwierig, man braucht eigentlich keine Komplizierten Berechnungen, die Rampen bei einer 3D Interpolationen ergeben sich dadurch von selbst.
Hallo Michael, > Wird ein 45° Winkel gefahren, fahren die X- und Y- Achsen bei genauem > hinschauen eine "Treppe". Der Werkzeug Vorschub ist immer noch > 100mm/min, der Vorschub der einzelnen Achsen ist dem entsprechen > kleiner. Bei der Verzögerung werden Total immer noch 10 Schritte > benötig, bei der 45° Interpolation, sind nun für beide Achsen je 5 > Schritte übrig. Die Achsgeschwindigkeiten wären dann um sqrt(2)=0,707 kleiner. Warum dann die Rampe je Achse nur noch halb so lang sein soll kann ich nicht nachvollziehen? Die Beschleunigung bzw. Verzögerung teilt sich genau so auf wie die Geschwindigkeit. Da interessiert meiner Meinung nach nicht in erster Linie die Anzahl der Schrittte, sondern die Achsbeschleunigung. Die Rampenlänge (Anzahl der Schritte) sollte damit konstant bleiben?! Mit freundlichen Grüßen Thorsten Ostermann
Also habe das ganze Prinzip mal aufgezeichnet. Bei der 45° Interpolation fahren die beiden Achsen nicht gleichzeitig, sondern abwechselnd, so wie in der Grafik. Um von X0/Y0 nach X10/X10 zu gelangen, wird eine Effektive Strecke von 20 zurückgelegt und nicht 14.142 Man muss immer mit Schritten rechnen in einem Raster, Diagonale gibt es nicht
Das sehe ich anders. Ich würde ich einem solchen Fall immer beide Achsen gleichzeitig fahren. Aber egal wie man es macht, die Achsgeschwindigkeit ist um den Faktor 0,707 kleiner. Das gleiche muss auch für die Achsbeschleunigung gelten, wenn die Bahnbeschleunigung (also die am Werkzeug) unverändert bleiben soll. Wenn du statt dessen die Rampe auf jeder Achse auf 5 Schritte verkürzt, fährst du effektiv mit einer höheren Verzögerung. Mit freundlichen Grüßen Thorsten Ostermann
Hallo zusammen, einer der Mitdiskutanten hier (eProfi?) rief mich vor einiger Zeit an, und bat mich, die Thematik des Winkelfehlers nochmal zu betrachten. Ich habe dem Thema einen eigenen Beitrag in meinem Blog gewidmet: http://www.schrittmotor-blog.de/positioniergenauigkeit-von-schrittmotoren/ Je nach dem, welchen Fall man betrachtet (stehender oder drehender Motor) kann der max. Winkelfehler tatsächlich entweder +/- 1 oder +/- 2 Vollschritte betragen. Falls der Motor wegen Überlastung ausrastet, springt der dagegen um n*4 Vollschritte weiter. Das kann man übrigens selbst experimentell prüfen, in dem man einen Motor bestromt (am Besten nur mit einem relativ kleinen Wicklungsstrom) und den Rotor über das Drehmoment des Motors hinaus schrittweise weiter dreht. Bei bestromten Wicklungen wird man für einen Motor mit 200 Vollschritten (50 Polpaaren) nur 50 stabile Rastpositionen erreichen. Mit freundlichen Grüßen Thorsten Ostermann
Danke für die Rückmeldung und den Blogbeitrag. > Je nach dem, welchen Fall man betrachtet (stehender oder > drehender Motor) kann der max. Winkelfehler tatsächlich entweder > +/- 1 oder +/- 2 Vollschritte betragen. Ich gehe immer vom Strom (dieser "erzeugt" die Kraft / das Drehmoment) aus, nicht von der Spannung. Der Winkelversatz durch die Phasenverschiebung addiert sich, das ist richtig. > Vielleicht solltest du dich mal praktisch damit beschäftigen? > Ich mache das seit über 10 Jahren... Bei mir sind es schon mehr als 30 ...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.