Unsere Firmware kann einen Trick, der so wirkt, wie eine Gangschaltung am Fahrrad.
Man simuliert damit bei hohen Geschwindigkeiten einen kleineren Micro-Step Modus.
Das Feature heißt Step-Doubling. Dieses Feature soll mit einer endlichen Prozessorgeschwindigkeit einen Motor bei schnellen Geschwindigkeiten effizienter ansteuern, ohne dass der Prozessor durch seine Auslastung zu schnell ans Limit kommt.

Kurz die Motoransteuerung umrissen:
Die Firmware im Drucker gibt dem Stepperdriver einzelne Takte aus. Jeder Takt dauert eine sehr kurze fast vernachlässigbare Zeit und anschließend wird aus der aktuellen Geschwindigkeit errechnet, wann der nächste Takt ausgegeben werden muss. "Der Wecker" wird gestellt und sobald dieser Klingelt passiert der nächste Interrupt. Es wird wieder (pro aktivem Motor) getaktet.
In diesem Idealzustand läuft der Drucker absolut flüssig. Die Impulse zum weiterbewegen des Motors kommen gleichverteilt am Motordriver an.
Nebenaufgaben wie das Empfangen von Befehlen und Vorbereiten des Druckweges werden zwischen diesen Interrupts in der Wartezeit abgearbeitet.

Problem:
Je schneller wir drucken,

• desto geringer wird die Zeit zwischen den Motorschritten.
• Desto schwieriger wird es, die Nebenaufgaben in der verfügbaren Zeit zu erledigen.

Effekte, wie

• ein langsames Menü oder
• ein stockendes Drucken können sich einstellen.

Step-Doubling und Step-Quating
sorgen dafür, dass ab einer bestimmten Verfahrgeschwindigkeit immer zwei Motorschritte oder vier Motorschritte pro Interrupt abgearbeitet werden. Die Soll-Verfahrgeschwindigkeit, was bei Single-Stepping der Interrupt-Taktfrequenz entspricht wird nun mit der halben/viertel Interrupt-Frequenz in zusammengefassten 2er-/4er-Blöcken an den Stepperdriver ausgegeben.
Man verlässt quasi durch ganz schnell aufeinanderfolgende Motortakt-Pakete die echten 32 Microsteps und begibt sich in der Theorie in eine Zwischenwelt zwischen 16 und 32 Microsteps bei Doublestepping (bzw. 8 und 32 Microsteps bei Quadstepping) solange man extrem schnell druckt.
Die Umschaltung erfolgt immer dann, wenn die Druckgeschwindigkeit über die Schaltschwelle hinausgeht oder darunter fällt. Genau wie bei einem Auto mit der Drehzahl bei der Automatik.

Natürlich könnte man meinen, dass das die Qualität schlechter macht.
In diesem Fall verhindern wir aber auch,

• dass Verzögerungen auftreten
• die Geschwindigkeit zu langsam, unregelmäßig ausgegeben wird.
• dass die Geschwindigkeit langsamer wird, als kommandiert, weil Interrupts übersprungen werden.
• dass
• der Drucker wegen Puffer-Entleerung absichtlich langsamer druckt oder stottert, weil er nicht mehr mit dem Füllen der Streckenplanung hinterher kommt. (Kleine Kreischen ab 40mm/s und so ^^)

Diese Gangschaltung aktiviert sich in der offiziellen Firmware bei 12000 Herz.
Ich kann hier nicht für die offizielle Firmware sprechen, da ich sie nicht mehr kenne. Aber beim Mod hatte ich ernsthaft Probleme, wenn ich eine gewisse Bandbreite an Geschwindigkeiten benutzt habe. (60..80mm/s)
Und auch, wenn ich Kreise drucken wollte, die aus vielen kleinen Teilstücken bestehen.

Geschwindigkeiten Nachgerechnet: Grenze bei 12000 Steps/s / 152,38 X-Y-Microsteps/mm = 78,75 mm/s als Umschaltpunkt "in den zweiten Gang"
Für Quadstepping, unseren dritten Gang: 2* 78,75 mm/s = 157,50mm/s
Grenze irgendwo ... bei 200 .. 300mm/s. (<- ??? Was soll ich damit?)
Die Idee ist:
Warum schalte ich erst bei 78mm/s runter, wenn die Probleme ca. bei 40mm/s langsam Gewicht bekommen?

Um das zu Zeigen habe ich diese Grenze von 12000 auf 8000 gesenkt.
Grenze bei 8000 Steps/s / 152,38 X-Y-Microsteps/mm = 52,50 mm/s als Umschaltpunkt "in den zweiten Gang"
Für Quadstepping, unseren dritten Gang: 2* 52,50 mm/s = 105 mm/s
Grenze irgendwo ... bei 150 .. 200mm/s.
https://www.youtube.com/watch?v=hXBmBCK ... e=youtu.be

Und es läuft noch immer nicht perfekt. Aber besser als mit 12000!

Also habe ich diese Grenze von 8000 auf 6000 gesenkt.
Grenze bei 6500 Steps/s / 152,38 X-Y-Microsteps/mm = 42,66 mm/s als Umschaltpunkt "in den zweiten Gang"
Für Quadstepping, den dritten Gang ab: 2* 42,66 mm/s = 85,31 mm/s
Grenze irgendwo > 130mm/s dort wirds dann halt langsamer.
Bei dieser Umschalt-Frequenz konnte ich im Menü ganz normal navigieren, als wäre nichts. Dann hat der drucker auf Double-Stepping umgeschaltet und ich konnte immernoch normal navigieren. Kein zähes Menü usw.
Sollte jemand feststellen, dass z.B. kleine Kreise erst ab unter 6000 sauber rauskommen, lege ich den Standard gerne auf 5000 runter Aber ich denke, dass 6500 o.ä. ein guter Normalwert sind, um umzuschalten.

Für alle, die Lust haben diesen Beitrag auf Geschwätz zu prüfen - oder mir beweisen wollten, dass ich in der Firmware irgendwo einen Bock geschossen haben muss, weil das in der originalen Firmware so nicht ist(?):
Stellt in der RF1000.h oder RF2000.h zuerst nichts um und anschließend bis ein,
generiert einen G-Code mit einer geraden Druck-Geschwindigkeit (z.B. 25mm/s) bei 100% Speedmulti und erhöht schrittweise und langsam den Speedmulti. Dann könnt ihr die Umschaltfrequenz ertasten.
Bitte dran denken, dass immer 16 Bewegungen im Cache liegen und die Erhöhung der Geschwindigkeit nach erhöhen des Speed-Multis darum bei langen geraden Strecken seine Zeit dauert!

Menü-Anzeige beim Mod 1.37u+ Wer auf seinem Display sehen will, wann umgeschaltet wird, kann sich zum Testen die Mod-Firmware 1.37u oder größer https://github.com/RF1000community/Repe ... evelopment herunterladen.
Dort habe ich Menü-Support und EEPROM-Support für diese Frequenzgrenze eingebaut und einen Marker ins Mod-Menü gelegt, der zeigt, ob Single, Double oder Quadstepping verwendet wird.
Für RF1000: Ich glaube, man müsste aufgrund der limitierten Menübreite genau S/D/Q anstatt Sgl/Dbl/Qud sehen. Stimmt das? Konnte das nur abzählen und nicht testen.

Configuration -> Stepper -> DblFq: Standard 6500, aber einstellbar von {5000 .. 12000} Ich bin gespannt
LG

Hi,

habe es getestet und mit Highspeed gedruckt....
läuft wie immer perfekt


RESPEKT !

Ist wirklich der Hammer welche Features aus Deiner Feder kommen!


Danke
liebe Grüße Heiko

Nibbels,

Ganz verstehe ich das nicht. Schenke ich damit nicht Auflösung her? Käme ich nicht auf beinahe das gleiche wenn ich von 32 Mikroschritte auf 16 (=Dbl) oder gar 8 (=Qud) reduziere?

Und bloß Geschwindigkeitsabhängig ist es nicht, sonst müsste mein Drucker bei jeder Leerfahrt (150mm/s) stocken. Sind es vielleicht die Rechenoperationen in Kombination mit den Interrupts? Eine Leerfahrt ist meist nur eine gerade, daher sind kaum Rechenoperationen involviert, bloß die Interrupts für die Motorschritte. Ein Kreisbogen, jedoch, mit den vielen kurzen, geraden Linienabschnitten, verlangt Rechnen und Interrupts.Ist das das Problem, dass zu viele Liniensegmente den Rechner überfordern, kann man genauso gut die Auflösung der STL reduzieren (falls man die Möglichkeit dazu hat). Damit reduziert sich die Anzahl der kurzen, geraden Linienabschnitte und damit die verlangte Rechnerleistung.

Andererseits ist dein Ansatz toll, denn es erlaubt quasi 'im Flug' die Umstellung der Mikroschritte, je nach Objektkomplexität und geforderter Druckgeschwindigkeit. Hoffentlich ist die Option abwählbar? Das wäre dann wichtig, wenn Genauigkeit die oberste Priorität hat und Tempo sekundär ist.

Ich drucke häufig mit 55-60mm/s und merke nur selten ein Stocken. Oft dann, wenn ich nebenbei am Rechner arbeite (ich drucke 98% der Zeit über USB). Wenn gerade am PC was rechenintensives abläuft, kann der Drucker hie und da stocken, weil die Daten fehlen, bzw. zu langsam geliefert werden (ist meine Vermutung). (Ich habe einen inzwischen recht alten dual core mit 'nur' 2.5 GHz, dafür 8GB Arbeitsspeicher.)

Kann es sein, dass die zusätzlichen Routinen in deiner Mod langsam den Rechner an die Grenze bringen? Da gibt es die Routine die die F-Digits überwacht und den Abstand regelt, jetzt die Routine die die Geschwindigkeit überwacht.....

mjh11

Ich versuche es mal so darzustellen:

Zuerst: Ich habe das nicht programmiert! Das war Repetier.

Ursachentheorie
Default 12000 sollte die maximale Interruptfrequenz für Bewegungen sein. Darüber hinaus konnte es problematisch sein.
Repetier hatte das für Rechner ohne z-Kompensation / RGB-Beleuchtung / Servos / Direct-Move / ... etc. auf 12000 voreingestellt.
Diese neuen Features wurden unserer Firmware (im Interrupt) hinzugefügt, aber dieser Wert (der eine Grenze in der maximal gewollten Interrupt-Frequenz darstellt) wurde nie verändert.
Ob ich selbst die Situation im Mod verschlimmert habe: Eher habe ich gut aufgeräumt und optimiert: Ich glaube nicht, aber will es nicht ausschließen. Mit einfachen Zeichen erklärt:
| bedeutet Ping zum Stepperdriver.
- bedeutet Overhead wegen Interrupt-Start und Ende.
. bedeutet freie Rechenzeit für sonstwas, wie Display, Kommunikation oder Pathplaning
Jedes Zeichen stellt ein Rechenschritt dar.

1) Ziemlich schneller Druck: ............-------|-------.................................................-------|-------................................................
2) Doppelt so schneller Druck:..........-------|-------.................-------|-------.................-------|-------..................-------|-------..............
3) Vierfach so schneller Druck:.........-------|-------.-------|-------.-------|-------.-------|-------.-------|-------.-------|-------.-------|-------.-------|-----

Besser wäre im letzten Fall Double-Stepping:

4) Vierfach so schneller Druck:.........-------||-------...............-------||-------...............-------||-------.................-------||-------................

• Fall 3 hat fast keine Punkte mehr, also kaum Kapazität für sonstige Aufgaben. Fallen diese sonstigen Aufgaben weg, wird auch die Geschwindigkeit nicht aufrecht erhalten, weil sie davon abhängt, dass neue Bewegungen geplant werden. Stockeln?
• Fall 3 und Fall 4 sehen für den Stepper im Sinne der Bewegungsstrecke fast gleich aus. Wir befinden uns hier auch schon bei ~6khz bis ~12khz Steps und da spielt es wegen der großen Dynamik und Masse evtl. nicht mehr so die große Rolle, ob die Takte gebündelt oder vereinzelt im Stepperdriver landen. Ich dachte mir, dass ein unregelmäßiges Stocken der Takte schlimmer sein müsste.
• In der Nähe von Fall 3 könnten schon Effekte auftreten, wie ein zeitliches Verschieben oder Überspringen von Interrupts, also ein unregelmäßiges Abarbeiten und versenden notwendiger Takte an den Stepperdriver.

In meiner Vorstellung, wurde bisher ab einer Frequenz wie im Fall 3) Double-Stepping aktiviert. Bei ca. 79mm/s.
Dort war aber schon kaum mehr Rechenleistung vorhanden.
In der RF1.37u habe ich die Firmware angewiesen schon nach Fall 2) Double-Stepping zu aktivieren. Bei beispielsweise 43mm/s.

Also folgt auf:
2) Doppelt so schneller Druck:..........-------|-------.................-------|-------.................-------|-------..................-------|-------..............
4) Vierfach so schneller Druck:.........-------||-------...............-------||-------...............-------||-------.................-------||-------.............
Was mir sinnvoller erscheint.
Verdopple ich, wird Quadstepping aktiviert:
5) Vierfach so schneller Druck:.........-------||||-------............-------||||-------............-------||||-------..............-------||||-------.............

Ich erhalte mir durch frühzeitiges "Hochschalten" also immer mindestens "............" an Rechenleistung. Erst nach Quad-Stepping, also > 86mm/s wird langsam das Limit der Rechenpower ausgereizt. Bisher passierte das vermutlich annähernd bereits in manchen der unteren Geschwindigkeitsbereiche: Gegen 79mm/s und gegen 157mm/s, immer kurz vor dem Umschaltpunkt.
Ab 79mm/s war wieder ordentlich Leistung da.
Ab 157mm/s war wieder ordentlich Leistung da.
Aber, wenn ich recht habe, gabs dazwischen "Leistungslöcher". -> Also warum nicht umschalten, bevor es knapp wird. Denn Geschwindigkeit können wir auch so genug.

32Microstep && Quad-Stepping vs. 8 Microsteps:
Solange wir langsam drucken haben wir 32 Microsteps. Nur wenn es ans Limit gibt, fassen wir die Steps zu Blöcken zusammen. Wir verlieren diese Auflösung also nicht wirklich.
Bremst der Extruder ab, kann er wieder extrem fein positionieren, als hätten wir nichts geändert.

Es wäre gut, wenn jemand mit unterschiedlichen Firmware diesen Test machen könnte: Kreischen drucken ... bei z.B. 25mm/s und schrittweise 1% erhöhen. Dann sehen, was ab rechnerisch 79mm/s passiert und wie sich der Drucker darunter verhält.

LG

rf1k_mjh11 hat geschrieben: Und bloß Geschwindigkeitsabhängig ist es nicht, sonst müsste mein Drucker bei jeder Leerfahrt (150mm/s) stocken.

Ich habe bei Leerfahrten meist Quadstepping oder Doublestepping gesehen. In dieser Geschwindigkeit ist der Drucker schon über die Problemzone raus.

rf1k_mjh11 hat geschrieben: Sind es vielleicht die Rechenoperationen in Kombination mit den Interrupts? Eine Leerfahrt ist meist nur eine gerade, daher sind kaum Rechenoperationen involviert, bloß die Interrupts für die Motorschritte.

Genau. Und diese Gerade braucht fast nur Ticks,
also Interrupts. Aber in manchen Situationen (GCode/Teile/Geschwindigkeitsbändern/Beschleunigungseinstellungen) hat sich das Display verhalten.als würde man Honig bedienen. Kaum Reaktion. Knöpfe halten, um eine Reaktion zu halten, kein reiner Klick.

rf1k_mjh11 hat geschrieben: Ein Kreisbogen, jedoch, mit den vielen kurzen, geraden Linienabschnitten, verlangt Rechnen und Interrupts.

Wo wird gerechnet

---

Bei jeder Richtungsänderung muss die Firmware einmal abschätzen, ob eine Abbrems- und Beschleunigungssequenz notwendig sein wird, und zweitens das Verhältnis der X- zu Y-Achsenbewegung ausrechnen. (Das ist alles nur eine Annahme meinerseits - was genau abläuft, entzieht sich meinem jetzigen Kenntnisstand.)

Ist das das Problem, dass zu viele Liniensegmente den Rechner überfordern, kann man genauso gut die Auflösung der STL reduzieren (falls man die Möglichkeit dazu hat). Damit reduziert sich die Anzahl der kurzen, geraden Linienabschnitte und damit die verlangte Rechnerleistung.

Reine Steppergeschwindigkeit macht die Interrupt-Anzahl hoch.
Viele Segmente machen die Vorbereitungsarbeit hoch.
Die Z-Kompensation will immer mitreden.
Alle wollen sich gegenseitig blockieren, sobald die erforderliche Leistung ans Limit geht. Der Interrupt hat aber vorrang.

rf1k_mjh11 hat geschrieben: Andererseits ist dein Ansatz toll, denn es erlaubt quasi 'im Flug' die Umstellung der Mikroschritte, je nach Objektkomplexität und geforderter Druckgeschwindigkeit. Hoffentlich ist die Option abwählbar? Das wäre dann wichtig, wenn Genauigkeit die oberste Priorität hat und Tempo sekundär ist.

Darum kann man im Menü die Frequenzgrenze so umschalten, wie man das für richtig hält. Ich halte es für schwierig, den richtigen Teiler zu finden. Eigentlich müsste man bei kleinsten Pfadstückchen automatisch die Frequenzgrenze absenken, sodass die Interrupts mit ihrer Prioriät nie den Nachschub blockieren können, aber trotzdem die notwendigen Schritte absetzen dürfen.
-> Es gibt sone Funktion! Nur die senkt die Geschwindigkeit allgemein, wenn man unter 10 Cache-Strecken fällt. Maximum ist 16 gecachte Streckenstücke.
Edit: -> Die Zeitgenauigkeit bekommt man zurück, sobald die negative Beschleunigung einsetzt und man abbremst - langsamer wird. Das wäre bei 8 oder 16 Microsteps nicht so.

rf1k_mjh11 hat geschrieben: Ich drucke häufig mit 55-60mm/s und merke nur selten ein Stocken. Oft dann, wenn ich nebenbei am Rechner arbeite (ich drucke 98% der Zeit über USB). Wenn gerade am PC was rechenintensives abläuft, kann der Drucker hie und da stocken, weil die Daten fehlen, bzw. zu langsam geliefert werden (ist meine Vermutung). (Ich habe einen inzwischen recht alten dual core mit 'nur' 2.5 GHz, dafür 8GB Arbeitsspeicher.)

Kann es sein, dass die zusätzlichen Routinen in deiner Mod langsam den Rechner an die Grenze bringen? Da gibt es die Routine die die F-Digits überwacht und den Abstand regelt, jetzt die Routine die die Geschwindigkeit überwacht.....

mjh11

Ist die Frage, ob man das Stocken mit bloßem Auge erkennen könnte. Zumindest hatte ich mal definitiv bei einem Teil mit vielen Löchern komische Effekte, die ich nie einordnen konnte.

Auf 6500 als mein Frequenzmaximum kam ich, indem ich die Reaktion des Menüs im schlechtesten Geschwindigkeitsbereich herangezogen habe. Ich habe die 12000 solange gesenkt, bis knapp vor dem Umschaltpunkt auf Double-Steps (anfangs) 79mm/s das Menü sauber und flüssig lief (so, dass man keinen Unterschied zu 10mm/s gemerkt hatte). Das war bei ca. > 5000. Ich bin dann wieder etwas höher gegangen: 6500.

LG

rf1k_mjh11 hat geschrieben: Kann es sein, dass die zusätzlichen Routinen in deiner Mod langsam den Rechner an die Grenze bringen? Da gibt es die Routine die die F-Digits überwacht und den Abstand regelt, jetzt die Routine die die Geschwindigkeit überwacht.....

mjh11

Das nochmal aufgegriffen:
Wenn ja, dann nicht gewollt. Schnelligkeit war mir immer sehr wichtig. Ich verstehe auch einiges von Microoptimierung.

- Ich spare z.B. DMS-Messungen ein, die wirklich eine Millisekunde(!) dauern. Diese werden in einem bestimmten Takt (100ms+) sowieso gemacht, wegen dem Emergency-Block.
- Gut, die Z-Kompensation muss immer arbeiten, nicht nur in den untersten 3mm. Man kann das (Digit-Compensation) natürlich abschalten.
- Was auch ein guter Punkt ist: Advance! Man kann das auch rauskompilieren - weglassen. Dort läuft ein zusätzlicher Interrupt mit. Da hättest du natürlich absolut recht.

Wir haben auch das Menü umgebaut. Das sollte deshalb aber nicht sehr viel langsamer sein. Viele anderen Änderungen im Mod sind Fehlerbehebungen oder wir haben einen Wert einstellbar gemacht, der vorher fest war. Das behindert die Ausführungszeit nur kaum oder benötigt nur etwas vom restlichen Ram.

Sollte jemand nachweisen, dass irgendwas beim Mod absolut falsch läuft, dann suchen wir natürlich die Ursache.
Ich sage auch nicht, dass der Drucker bisher nicht lief! Aber es geht besser. Und unter Umständen merkt man diesen Umstand tatsächlich am Verhalten des Druckers während des Drucks
Die Theorie ist für mich nun quasi erschlagen, wenn jemand Fragen haben sollte beantworte ich die gerne. Ich gehe über zum Praxistest ^^.

LG

Ich bin gerade einem Effekt auf der Spur:

Unter Umständen könnte es sein, dass der Drucker in 1.37u2 noch gaaanz feine Probleme macht, wenn er zwischen den Step-Modi wechselt.
Genau kann ich es noch nicht sagen, aber mein Vergleichsteil, bei dem der Drucker nicht zwischen Double und Quad-Stepping hin- und herwechselt, weil ich die Step-Frequency angehoben habe scheint der Effekt wegzubleiben:

- DoublestepFrequency: 5500 39mm/s - DoublestepFrequency: 10000 66mm/s (PLA druckt mit kleiner 66mm/s!)
-> Bauteil ist gerade.

Ok: Das Problem kann sicher behoben werden, aber wenn man weiterdenkt: Schnelle Z-Bewegungen lassen den Drucker ebenfalls zwischen den Step-Modi wechseln. Evtl. ist das ein Hinweis darauf, warum der Z-Lift manchmal einen Shift verursacht?
(Ich sehe beim Homing immer Quadstepping arbeiten (!)...)

Ich weiß nun erstmal nicht, wie ich da rangehen soll: Erstmal werde ich vermutlich weider die ganzen Commits von Repetier durchlesen müssen, ob er seit 2013/2014 an dem Double/Quadstepping noch was geändert hat. Oder ich frage dort mal im Forum nach.
Vielleicht weiß auch RF1000 schon mehr darüber.

EDIT: Ja, ich glaube nun fest dran da ist noch ein Bug -> beim Stepping! LG

Öhm Nibbels,
wenn ich die Teile so anschaue, dann kommt mit der Verdacht auf, dass die Teile eine leichte Überhitzung zeigen.
Sind die Druckbedingungen wirklich identisch?

Auch eine unterschiedliche Bauraumtemperatur oder Geschwindigkeit, könnte so einen Fehler verursachen.
Ich denke da an die Abkühlzeit.

LG AtlonXP

Ja genau, das war meine erste Idee.

Aber dann, als das "Warping" einfach zu perfekt aussah habe ich genauer nachgeschaut und mich inzwischen vom Gegenteil überzeugen lassen.
Es ist zu 99% ein Bug, den ich nun suchen will.
Wenn die Lösung dafür uns noch zusätzlich die Z-Lift-Sache abnimmt, hätte sich der ganze Aufwand mehrfach gelohnt.

Ich hab schon ein paar Commits rausgekramt: https://github.com/repetier/Repetier-Fi ... 0a8a61b275
Hier hat Repetier 27 Apr 2015 dieses "Halfstepping" aus seiner Software ausgebaut. Warum weiß ich aber nicht. Ich hab mich immer gewundert gehabt, warum man das braucht.
...

Theoretisch kanns nun Monate dauern, bis ich das finde. Mal sehen..

Ich hab die Commits seit 2014 überflogen und mir sind einige Sachen aufgefallen die ich übernehmen konnte.
Die glückliche Ahnung, dass es was mit dem Half-Stepping zu tun haben könnte, war vermutlich ein Volltreffer.
Ich habs ausgebaut, wie Repetier:
Nun ist mein neues Bauteil gerade.

Und zwar auch mit denselben Einstellungen, die zu diesem Bauteil geführt haben: Wenn mich meine torischen Linsen zu dieser Stunde nicht wieder veräppeln, ist mein aktueller Druck nun wieder absolut 100% orthogonal.

morgen..

LG