Hallo! Ich habe für meinen Kreuztisch und die bestehenden Schrittmotorentreiber eine neue Ansteuerungselektronik gebaut. Die alte Ansteuerelektronik konnte deutlich höhere Verfahrgeschwindigkeiten erreichen und mir ist auch klar warum: Weil sie Rampen zum anfahren und abbremsen genutzt hat. Prinzipiell habe ich das auch vor zu realisieren, aber mir stellt sich die Frage, wie ich das am besten anstelle. Zur Diskussion hier mal ein Ausschnitt von einem geparsten G-Code file: 9 0 -3 9 0 -3 9 0 -3 9 0 -3 9 0 -3 9 0 -2 10 0 -3 9 0 -2 7 0 -1 10 0 -2 10 0 -2 11 0 -1 10 0 -1 10 0 -1 1. Spalte: Anzahl der X-Schritte 2. Spalte: Anzahl der Z-Schritte 3. Spalte: Anzahl der Y-Schritte Wenn X und Y <> 0 sind, wird also eine "Schräge" gefahren. Jede Zeile enthält einen Verfahr-Befehl. Jetzt stellt sich mir die Frage: wann fahre ich eine Rampe und wann nicht? In jeder Zeile? Aber es sind garnicht genug Schritte um effektiv ne Rampe abzufahren. Es würde nie volle Geschwindigkeit erreicht werden, obwohl ja fast alles in die selbe Richtung geht (mit leichten Variationen). Nur bei größeren Richtungsänderungen? OK, aber wo setzt man die Grenze? Übrigens hat die alte Elektronik immer bei jedem Verfahrbefehl eine komplette Rampe abgefahren. Zusammen mit der denkpause, die durch die Kommunikationsschnittstelle entstand kann man sich vorstellen wie viel langsamer eine Rundung war, als eine lange gerade. Hat sich schonmal jemand ähnliche Gedanken gemacht? Ich hoffe mein Problem ist halbwegs verständlich :-) Viele Grüße, Peter
> Jetzt stellt sich mir die Frage: wann fahre ich eine Rampe > und wann nicht? Ja, besonders nett wird es noch, wenn die folgenden G-Code Kommandos erst während der Tour geliefert werden, dann muss man bremsen wenn man noch nicht weiss wie es weiter geht, kann aber wenn Daten kommen eventuell das Bremsen sein lassen. (das hat sich deine alte Steuerung einfach gemacht). Prinzipiell gilt: Die Rampe gilt pro Achse. Eine Achse darf also nicht mehr als um xxx G beschleunigen oder bremsen. Die anderen Achsen müssen natürlich mitgeführt werden, wenn die eine Achse bremst, darf die andere Achse bei einer Geraden nicht gleich schnell bleiben sondern muß mitgebremst werden. Daher ist ein G-Code Interpreter nichttrivial. Wenn ein G-Code der letzte ist, weisst du, daß das Tempo an jeder Achse danach 0 sein muss. Wenn auf den G-Code noch einer folgt, weisst du noch nichts. Du musst erst den folgenden G-Code berechnen. Angenommen der war der letzte, dann musste an seinem Ende Tempo 0 sein, und du rechnest seine Länge rückwärts und weisst, wie hoch das Tempo (begrenzt auf Maximaltempo) jeder Achse maximal sein konnte. Damit ist aber immer noch nicht sicher, ob es so hoch sein wird. Denn wenn die Richtung von der Richtung abweicht, die dein G-Code hat, dann ist das Verhältnis der Achsengeschwindigkeiten anders, und eine Achse muss eventuell gebremst werden, dann wird das folgende Stück G Code ja langsamer begonnen, also am Anfang beschleunigt. Kommt hinter dem letzten G Code noch ein G Code, erweitert sich die Beobachtung und das kann Auswirkungen bis zum ersten G Code haben, bis zur Stelle, die aktuell abgearbeitet wird. Neben Geraden sollte man auch Kreisbögen als G Code implementieren. Das macht die Sache zwar deutlich schwieriger, aber besser.
Es klingt komisch, aber die Antwort lautet: Immer.
Ist Deine minimale Schrittgeschwindigkeit 100/s und das Maximum 600/s,
so musst Du ja, bei kurzen Fahrstrecken, nicht immer bis zum Maximum
beschleunigen. Verbunden mit der Beschleunigung ist ja auch die dabei
zurückgelegte Strecke. So kann es sinnvoll sein bis auf 200/s Schritte
zu beschleunigen um dann direkt in die Bremsphase zu gehen.
Bildhaft
Große Strecke: Start mit 100/s; beschleunigen bis 600/s;
Fahren mit 600/s; abbremsen bis auf 100/s; Stopp.
Kurze Strecke: Start mit 100/s; beschleunigen bis 200/s;
abbremsen bis auf 100/s; Stop.
So kannst Du auch bei kurzen Strecken sehr viel zeit sparen.
Dank euch beiden. Die beiden Ansätze gehen in 2 verschiedene Richtungen. Während der erste in Richtung "ideale/effiziente" Implementierung geht, geht der 2. mehr in Richtung pragmatische/sichere Lösung. Ich werde mal schauen in welche Richtung ich gehe. Das mit dem Rampen ist auf jeden Fall ein heikles Thema, wenn man sich anschaut in was für mini-stückchen der G-code zerhackt wird, wenn man "biegungen" in der Vorlage hat. Leider sind es selten welche, die durch Kreise approximiert werden können. Evtl. betreibe ich auch den Kreuztisch erstmal nur in einem sicheren Bereich, d.h. ohne Rampen und mit niedriger Geschwindigkeit. Leider bedeutet das eine große Geschwindigkeitseinbusse: Mit Rampen kam die alte Elektronik auf knapp 10cm pro Sekunde (was natürlich nur für Rapid moves interessant war). Ohne Rampen komme ich auf gerade mal auf 1cm pro Sekunde.
Eigentlich ein recht interessantes Thema Peter schrieb: > ist auf jeden Fall ein heikles Thema, wenn man sich anschaut in was für > mini-stückchen der G-code zerhackt wird, wenn man "biegungen" in der > Vorlage hat. Leider sind es selten welche, die durch Kreise approximiert > werden können. Ich denke, der Knackpunkt liegt tatsächlich in der Erkennung, dass man aufeinanderfolgende Verfahrwege geschwindigkeitsmässig zu einem einzigen zusammenfassen kann, solange die Hardware die Richtungsänderung noch mitmachen kann. Theoretisch müsste es auch gehen aus dem Winkel der Richungsänderung sich zu berechnen, bis auf welche Geschwindigkeit man runter gehen muss, damit die Stepper mitkommen. Als ersten Ansatz würde ich mal probieren, einfach hintereinanderliegende Wege, die einen Winkel von 0 bzw. nahe 0 einschliessen für die Rampenberechnung zusammenzufassen. Wobei natürlich das Problem, welches MaWin angesprochen hat, nicht ohne ist. Würde ich fürs erst mal dahingehend ignorieren, in dem ich den Buffer für die Codes die vorgehalten werden groß genug mache, dass es unwahrscheinlich ist, dass sich an den berechneten Rampen noch groß was ändert. Unwahrscheinlich - nicht unmöglich. Wenn der ab und zu mal in einem großen Kreis langsamer wird und dann wieder beschleunigt - müsste man ausprobieren ob das tatsächlich in der Praxis ein Problem ist.
Der fahrplan ist ja klar und immer durch ein gcode programm vorgegeben. dieser ist schon komplett vor der ausführung bekannt. Man muesste es irgendwie schaffen die "physik" der maschine on the fly zur bestimmung der pausen zwischen den vorgegebenen pulsen zu berechnen. Sprich massen beruecksichtigen/maximale beschleunigung bei der schritte verloren gehen, etc... Erinnert mich irgendwie von der komplexität her an die inverse kinematik bei automobilrobotern :-)
Ich erinnere mich düster an Grbl, die hatten einen kleinen Kernel gebaut, der sich um die Rampenberechnung kümmerte. Das wäre doch zumindest ein Einstieg. https://github.com/grbl/grbl
Ich glaube nicht, dass hier irgendjemand gesagt hat dass Dein Problem einfach zu lösen ist. Eins ist aber sicher: Einfach die niedrigste Geschwindigkeit ist auch keine Lösung. Fahre mal in Gedanken einen Kreis, sehr beliebt bei der Programmierung, ab und stell Dir mal die dabei anfallenden Geschwindigkeiten vor. Fängst Du unter 0° an, so fährst Du mit maximaler X-Geschwindigkeit los und in Y-Richtung bei 0. Bei 45° sind beide Geschwindigkeiten gleich und bei 90° läuft in X-Richtung nix mehr und in Y-Richtung geht's richtig ab. Schon dieser Fall macht deutlich, dass Du mit linearen Rampen nicht weit kommst. Selbst das hier aufgezeigt Scenario ist nicht auf verschiedene Werkzeuge oder Radien anwendbar. Auch gilt: Fährst Du in X-Richtung mit Geschwindigkeit 100 und machst dasselbe in Y-Richtung, so fährt dein Werkzeug mit Geschwindigkeit 141... Eins sollte allerdings kein Problem sein: Die Rechenleistung. Zumindest wenn Du mal 500++ MHz Klasse einsteigst. Das Hauptproblem ist ja nicht ein Ballistikcomputer der ein vorbeifliegendes Objekt verfolgen soll, sondern eine Mechanik, mit definierter Masse, bei der sich in 0,001s Sekunden nichts tut bzw. bei der Du vorher weist, welchen Zustand sie in 0,001s einnimmt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.