Community Mod RFx000 Firmware :: Neue Stable (Stand 1.43.13 / 30.11.2018)

[Nibbels]

Hallo euch beiden

Spazierfahrten:
Danke für die Rückmeldung. Ich muss mir das erst noch durch den Kopf gehen lassen, woran das liegen könnte.

Mikroruckler:
sind wohl eine Folge von zu lahmem Prozessor vs. zu schnellen+kurzen Bewegungen.
Man wird immer in diese Situation kommen, wenn man die mm/s aufdreht.
Die Frage ist nur wie fein die Bewegungen bei welcher Geschwindigkeit sein dürfen. Kann gut sein, dass wir durch das Entfernen der CRC-Prüfung und dem Aufdrehen der SPI-Geschwindigkeit einige Prozent an Kleinst-Bahnstücks-Effizienz gewonnen haben.

Ich weiß das mit dem Grenzfall ziemlich genau, seit ich mit den G3/G2 experimentiert habe. Da steht keine USB und keine SD-Datenübertragung im Hintergrund. Man lässt sich einfach nur feine Bahnstücke generieren und führt die aus. Nehmen wir an, wir lassen den Drucker viele viele Kreise ziehen. Erhöht man dann währenddessen die Feedrate um 1er-Schritte fängt irgendwann dieses Microruckeln an. -> Und zwar immer.

Bei Travel-Bahnstücken können wir fahren so schnell wir wollen, denn dabei wird nicht extrudiert (keine Blobs) und normalerweise sind diese Bahnstücke ziemlich gerade. (Ausser mit der SimplifyOption, man soll mit der Düse möglichst nicht über die Perimenter hinausfahren.)

Was ich gerne hätte (das ist aber nicht einfach oder nicht sauber umzusetzen) ist eine Art Regelmechanismus, welcher je nach Häuffigkeit der Microruckler die Feedrate automatisch auf das "beste Maß" einschränkt.
Denn mir selbst ist ehrlich egal, wie lange ein Druck dauert. Der Drucker muss nur korrekt und Blob-Frei und ohne viel Pro-Teil-Tuning den Job erledigen.
Also habe ich schon mal dran gedacht, dass ich ähnlich wie die Geschwindigkeitsabhängigkeit zum DMS-Sensor auch eine Abhängigkeit zum Throttling schaffen könnte.
Throttling gibts schon, aber ist das Throttling immer mal wieder, dann sieht es aus wie Micro-Ruckeln. (Ich glaube, Throttling ist zu 95% für das Mikro-Ruckeln verantwortlich.)
-> Also müsste man solange die Grundgeschwindigkeit senken, bis man Throttling auf ein Minimalmaß eingeschränkt hat.
Das wird super klappen, wenn alle Moves immer gleich lang wären. Es ist jedoch so, dass der Drucker immer nur die nächsten 16 Moves kennen kann.
Und da wirds kompliziert.

Der Slicer hingegen kennt eigentlich alle Bewegungen genau. Der sollte eigentlich die Geschwindigkeit immer genau so wählen, dass bei feinsten Teilstücken entsprechend limitiert langsamer gedruckt wird.

LG

[CrazyJ]

Hallo Nibbels,
wie schon geschrieben habe ich Mikroruckler während des normalen Betriebs nicht mehr festgestellt. Auch bei höheren Geschwindigkeiten scheint es stabil zu laufen.

Spazierfahrten:
Hierbei muss ich mich wohl korrigieren. Das Problem tritt nicht unbedingt in Zusammenhang mit der Temperatur auf. Das Problem scheint bei der Bedienung der Tasten zu liegen:
Wenn ich z.B. die Temperatur des Extruders mehrmals erhöhe, verringere oder einfach um eine Temperatur öfter hintereinander hoch und runterschalte, entsteht eine Spazierfahrt gegen den x-Endschalter. Die Verarbeitung der Tasten / übergabe der Daten scheinen ihn wohl aus dem Konzept zu bringen.
Wenn man ihn aber in Ruhe lässt, läuft aber alles gut.

[zero K]

...
Die Verarbeitung der Tasten / übergabe der Daten scheinen ihn wohl aus dem Konzept zu bringen.
Wenn man ihn aber in Ruhe lässt, läuft aber alles gut.

Das ist ein Problem vieler Maschinen, die über ein lokales Bedienfeld und ein entferntes Datenverarbeitungssystem bedient und programmiert werden können und hier bei unseren Druckern wohl auch ein nicht so seltenes Problem.

In der Regel werden zur Laufzeit eines Programms nur bestimmte Funktionen über das Bedienfeld zugelassen deren Parametrierung auch eher in kleinen, sicheren Schritten verändert werden können.
Maschinenrichtlinien sehen dafür auch Kontrollmechanismen und Steuerungen vor, nur dürfte es nicht ganz einfach sein das einer einzelnen CPU mit begrenztem RAM beizubringen.

Vielleicht findet Nibbels eine Möglichkeit die Funktion der Tasten zur Laufzeit eines Programms in sichere Grenzen zu bringen.

Gruß zero K

Da fällt mir noch ein ...
wenn ich über den Repetier-Server während der Laufzeit eines Druckes Parameter wie Flow Bahngeschwindigkeit Lüfterdrehzahlen und Temperaturen variiere passiert nix ungewolltes, Repetier scheint die Änderungen wohl recht sauber in den Datenstrom einzugliedern.

[AtlonXP]

Hier eine Beobachtung meinerseits mit der FW 1.43.77
Ich habe die Angewohnheit bei dem Start eines neuen Druckes,
während des Homing mit der Extruder Taste bereits in die Luft zu Extrudieren.

In den älteren Versionen war es so, dass nur die Z Achse leicht in der Homing Bewegung beeinflusst wurde.
Sie fuhr Prozesszeit bedingt langsamer und schneller.
Nach dem senken der Feed Rate war dieses Problem fast weg.

Heute fährt nicht nur die Z Achse mit gewaltigen Rucken hoch,
sondern ebenso auch die andern Achsen zum Homing.
Es ist ein komplettes stehen bleiben mit einem unangenehmen Poldern.

Ich denke das müsste am RF2000 genauso und reproduzierbar sein.

LG AtlonXP

[Nibbels]

Hier eine Beobachtung meinerseits mit der FW 1.43.77
Ich habe die Angewohnheit bei dem Start eines neuen Druckes,
während des Homing mit der Extruder Taste bereits in die Luft zu Extrudieren.

In den älteren Versionen war es so, dass nur die Z Achse leicht in der Homing Bewegung beeinflusst wurde.
Sie fuhr Prozesszeit bedingt langsamer und schneller.
Nach dem senken der Feed Rate war dieses Problem fast weg.

Heute fährt nicht nur die Z Achse mit gewaltigen Rucken hoch,
sondern ebenso auch die andern Achsen zum Homing.
Es ist ein komplettes stehen bleiben mit einem unangenehmen Poldern.

Ich denke das müsste am RF2000 genauso und reproduzierbar sein.

LG AtlonXP

Ja, das ist richtig.
Dieses "Einschleusen" von Steps gibts in der aktuellen Firmware nicht mehr. Jede Bewegung ist entweder über die Warteschleife geplant oder ein Direct-Move. DirectMove ist eine gesonderte Warteschlange die genau einen Platz hat und diese Bewegungen haben immer Vorrang, unterbrechen also alles andere hart.

Das einzige verbliebene Drive-System das parallel zu anderen Bewegungen die Stepper manipulieren darf ist die Z-Kompensation.

Danke für eure Hinweise mit dem Knopfdrücken. Ich versuche mal, das irgendwie nachzustellen. Generell ist dieser Teil des Codes eher widerlich. ^^
Dort einzusteigen ist eigentlich nicht das was ich tun wollte. Zwar weiß ich grob wie der Code abläuft, aber da sind teils Meterlange Spaghetticode Teile drin und ziemlich viel Pointer-Mist.

LG

[AtlonXP]

Hier noch eine Beobachtung meinerseits mit der FW 1.43.77

Heute habe ich ein kleines Teil gedruckt mit Z Lift 0,4 mm.
Dabei ist mir aufgefallen, dass die Z Achse nach jedem Sprung, schon während beim Drucken nochmals nachstellt.
Erst dachte ich an meine Zahnriemen.

Da aber der zweite Z Wert (neu hinzu gekommen) um 0,02 mm Unterschiede anzeigt,
schiebe ich das Problem auf die FW.
Dieser Springt bei mir zwischen -7,39 und -7,41.

Ich sehe etwa an meinen Spindeln eine Nachkorrektur von 1 bis 2 Grad.
An meinem gedruckten Teil sehe ich dieses Problem auch.

LG AtlonXP

[Nibbels]

Du Fuchs. Wie du immer die Hundertstel bemerkst

Ein unterschiedliches Z-Niveau bedeutet ein unterschiedliches Z-Kompensations-Offset. (->Du springst in Z.)
Dann merkt die Z-Kompensation, dass die Verzerrung des Z-Achsen-Koordinatensystems am neuen Punkt eine andere ist und kompensiert die Differenz.

Wie du sagst ist der erste Wert im Display nun die Soll-Koordinate der GCode-Warteschleife.
Alle anderen Offsets sammeln sich in der rechten Spalte. Z-Offset, Z-Kompensation, optional das Hotend-Z-Offset / DirectMoves.

(Da wir durch die Auto-Erkennung die Kompensations-Zone größer gemacht haben, das "Dehnen" der Einzel-Layer also nur noch maximal 5% ausmachen darf, sollte zumindest theoretisch der Effekt nicht so riesig sein. Es ist ja nicht wirklich ein Fehler, sondern nur ein komisches Verhalten, oder?
Aber dennoch sollte man um das Problem zu vermeiden nicht riesige Z-Sprünge einplanen.
-> Könnte das auch eine Ursache für unsere Layer-Probleme gewesen sein? Ein Shift nach zwei Z-Layer-Wechseln klingt verdächtig, aber wir haben den Z-Layershift auch oberhalb der Kompensationsgrenze festgestellt, also habe ich das damals verworfen.)

Z-Kompensation findet nur statt wenn sich die Z-Achse nicht gerade bewegt. Es muss also eine XYE-Bewegung vorhanden sein, sodass die Z-Kompensation die Steps korrigiert, die sie als Differenz sieht.
Eine Ausnahme gibts:
-> Läuft die Soll-Position der Z-Kompensation gegenläufig zu normalen Z-Steps, dann verrechne ich die Steps miteinander. Der Z- wird also nicht ausgeführt und bei einer Z+CMPDifferenz einfach abgezogen, wenn der Fall auftritt.

Weiter gedacht: Warum nur bei gegenläufigen Bewegungen? Es ist einfach gewesen, das so einzubauen.
Wenn ich zusätzlich zu einer Z+Bewegung auch noch eine Z+Kompensation einschmuggeln will, dann muss ich zusätzliche Steps einstreuen. Beim Extruder machen wir das. Ich habe das aber bei Z noch weggelassen. Meist, ausser bei großen Z-Bewegungen ist die zu kompensierende Rest-Differenz sowieso winzig.

LG

[AtlonXP]

Hmm..
Was der zweite Z- Wert nach einer Layerhöhe von über 32 mm Anzeigt ist mir Wurscht.
Wenn, da aber die Z Achse noch meint,
irgendetwas kompensieren zu müssen, dann läuft da was falsch.
Die Z Achse läuft da trotzdem noch.
Mach einfach einen Bollen Fett an deine Spindel und auch du siehst es.

Du kennst meinen Fett Nippel Adapter.
Genau von diesem schreibe ich.
Die ersten 10 mm sehen sogar noch gut aus, vielleicht auch wegen der Rundung.
Danach sieht der Druck aber aus wie Sau.
Na gut ich übertreibe.

Ich gestehe mein Start Kode sieht anders aus.
Ich verwende M3008 Z0.6.
Ich möchte einfach das so haben, dass Sence Offset, die ersten 3 Layer Höhen lang aktiv bleibt.
Seither hatte das so funktioniert.

LG AtlonXP

[Nibbels]

Hmmm..

Ich muss dir wohl gestehen, dass ich M3007 und M3008 in 1.53.52 ausgebaut habe.
https://github.com/RF1000community/Repe ... g.txt#L182
Das hat den Code um einiges verständlicher gemacht, wenn dieser Sonderregelzustand weg ist. Und wir haben ein paar Byte RAM gespart

-> Diese Automatik funktioniert!
Wenn dein Bett allerdings sehr eben justiert ist und wenig wellig, dann kommt es für dich aufs Gleiche raus.
Faustregel: Je mehr Abstand deine z-Matrix-Werte maximal voneinander haben, desto größer wird der Kompensationsbereich.
(Das heißt Maximal- minus Minimalhöhe auf dem Bett [z.b. 0.2mm]. Deine -8mm Schalter-Abstand-Offset sind egal.)
Dein Bett ist vermutlich perfekt ausgerichtet und wenig wellig. Dann ist dir das egal. Aber "alle anderen die halt ihr verbogenes und krummes Bett scannen und damit drucken" würden ohne Automatik näherungsweise einen Raft erhalten.
Mit Automatik ist das Druck- und Kompensations-Zufüll-Verhalten quasi bei allen Betten gleich.

SenseOffset in den ersten 3 Lagen .. kann man machen ist aber eigentlich garnicht nötig.
Das bringt tatsächlich nur in der ersten Lage was und anschließend ist es theoretisch schädlich. Das wird zum Glücksspiel, wenn im zweiten Layer durch diese Slicer-First-Layer-Sondereinstellungen noch die Geschwindigkeit hochgeht.
Viel logischer wäre im ersten Layer einfach noch mehr Skirt-Umrundungen einzuplanen, wenn die Grundfläche vom Druckteil nicht reicht um das z-Offset perfekt einzu"fühlen".
(Änderst du im zweiten Layer nochmal dein Z-Offset stimmt der Füllgrad in dem Layer theoretisch nicht.)

LG

[AtlonXP]

So was aber auch…
Jetzt geht auch noch die absolute User Kontrolle flöten.

Deine Annahme mein Bett ist sehr eben ist falsch.
Ich arbeite gerade mit einer Druckplatte die das nicht ist.
Aus diesem Grund hast mir auch das frei Fahren von 0,X mm für einen HBS eingebaut.

Für die hier mitlesenden:
Mein Druckbett ist sehr flexible aufgebaut.
Darauf spanne ich alles auf, was Spaß macht zum Drucken.

Z. B. eine Schuhsole würde auch gehen.

LG AtlonXP