Marlin Firmware spinnt rum

Hallo Leute,

bin neu hier und weiß nicht wie ich danach suchen soll darum folgende Frage

Problemstellung:

Habe einen Kossel Mini zusammengeschustert mit E3D Hotend.
Mechanisch bzw elektrisch funktioniert das Teil auch abgesehen vom Materialzuführungsstrang (Hotend bzw Extruder). Das ist aber auf mangelnde Erfahrung rückzuführen und gehört meiner Meinung nach zum Lernprozess.
Mein eigentliches Problem besteht darin, dass er mitten unterm Druck plötzlich stehenbleibt für ca eine halbe Sekunde und dadurch kleine Warzen im Druck entstehen weil Material nachquillt. Danach fährt er ganz normal weiter. Ich habe das hauptsächlich bei komplizierten Druckobjekten.

Toolchain schaut so aus: Cura 14.03 --> Pronterface --> Marlinfirmware auf normalem Arduino Mega --> Ramps 1.4 bei 12 V


Ich hoffe es kann mir jemand helfen. Vielen Dank

Beste Grüße

Albin

Hi Albin,

.. aus der Ferne schwer zu sagen -- neben Software-'Schluckauf' auf dem Rechner können das auch z.B. Verbindungsstörungen auf der USB-Verbindung sein ... wird gerne mal durch schlecht abgeschirmte/verlegte Schrittmotorkabel oder starke Stromeinbrüche auf der Stromversorgung verursacht ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Würd das was bringen wenn man die Baudrate runterschraubt? Ich fahr noch immer mit 250000... An den Schrittmotoren liegts glaub ich nicht. Weil ja die Bahnführung ziemlich einwandfrei ist.

Ggf ist die Auflösung vom STL zu hoch. Wenn du dann vielleicht noch nen FullGraphic dran hängt ist schnell Feierabend.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hi.

Delta - ruckler bei engen Kurven - 8 bit elektronik -->kenn ich
der Elektronik kommt nicht hinterher mit dem berechnen.

drucke die Perimeter deutlich langsamer
oder versuch mal repetier.
damals vor eineinhalb Jahren war repetier bei Delta druckern ein paar Prozent schneller.
wie schon erwähnt gehen display auch auf die rechenleistung ...

Ich meine in den Tiefen von Slic3r kann man irgendwo einstellen wie dicht punkte bei einander liegen dürfen. Wenn du den abstand vergrößerst kannst du schneller durch enge kurven fahren.

Gruß

1-mal bearbeitet. Zuletzt am 24.07.15 02:17.

Quote
windiesel
Hi.

Delta - ruckler bei engen Kurven - 8 bit elektronik -->kenn ich
der Elektronik kommt nicht hinterher mit dem berechnen.

drucke die Perimeter deutlich langsamer
oder versuch mal repetier.
damals vor eineinhalb Jahren war repetier bei Delta druckern ein paar Prozent schneller.
wie schon erwähnt gehen display auch auf die rechenleistung ...

Ich meine in den Tiefen von Slic3r kann man irgendwo einstellen wie dicht punkte bei einander liegen dürfen. Wenn du den abstand vergrößerst kannst du schneller durch enge kurven fahren.

Gruß

Ja, Repetier ist schneller beim Delta. Die Slic3r-Dichte funktioniert irgendwie nicht so richtig. Zumindest bei der 1.2.6 habe ich es nicht gebacken bekommen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich glaub ich weiß mittlerweile wo der Hund begraben liegt.

Habe bei weiterer Recherche folgende Beschreibung zur Marlinfirmware gefunden:

Quote

Buffer underruns
The high printing speeds of Marlin can cause buffer underruns, which means that the computer cannot send data to the printer fast enough, and the printer occasionally comes to a stop, waiting for data from the computer. You'll experience this when printing parts with high polygon count and many small segments; the printer slows down and does not move as smooth as it did before.

There multiple ways to circumvent this:

print from SD; communication with the SD is much faster than with the PC
reduce the polygon count or resolution of your original STL file.
marlin has a feature that reduces speed gradually to prevent buffer underruns. The parameter that sets how fast it should slow down can be varied using the M205 Bxxx command.

Increasing speed & performance
The default configurations are conservative so they will work without troubles for most people. If you want to push the limits of your machine, you can play with the parameters. Below are some guidelines:



Increase maximum speed
e.g M203 X500 Y500 will give you higher speeds.
Increase acceleration
If you have non-stock motors or another solution that gives more torque, you could increase the default acceleration.
You may also want to increase the x,y jerk. Increasing it will give you higher speeds at risk of lost steps. e.g M205 X50
Increase minimum speed
Some skeinforge-generated code does not travel at high speeds. If you see a lot of stringing and
too low speeds while traveling, you can increase the minimum travel speed.

eg. M205 T500 will cause all travel moves to be done at 500mm/s, regardless of the skeinforge settings.
Buffer underruns
If you have troubles with high-density polygon printing, try increasing or decreasing the minimum buffer time.
eg. M205 B50000 or M205 B0 to disable it completely

Habe dann in Marlinfirmware geschaut was den genau dieses M205 so treibt. Da stand fiolgendes:

Quote

// M205 - advanced settings: minimum travel speed S=while printing T=travel only, B=minimum segment time X= maximum xy jerk, Z=maximum Z jerk, E=maximum E jerk

Rückschlüssig kann daher gesagt werden, dass Jerk unmittelbar Auswirkung auf Radienbefehle hat.
Theoretisch ist Jerk aka Ruck als Querruck zu sehen was per Definition die maximale Beschleunigung einer Beschleunigung darstellt. Beim Querruck ist das so zu sehen wie schnell ich maximal den Radius einer Kurvenbewegung verkleinern kann.
Ein Deltaroboter kann aber nur lineare Bewegungen ausführen (laut Information aus dem Internet; so fit bin ich kinematisch dann doch nicht) ergo muß der Arduino wenn er eine Kurve aus dem G-Code befohlen kriegt, erstmal alles in Geraden umrechnen. Je kleiner aber der maximale Jerk ist desto höher muß er die Kurve auslösen und stößt dabei an die Grenzen seiner Rechenleistung.

So seh ich das zumindest hypothetisch, da ich unmittelbar bevor das Problem zum ersten mal auftrat, an den Parametern für Jerk und Beschleunigung rumgespielt und die runtergestellt hab um die Mechanik zu schonen.
Nachdem ich die Werte jetzt wieder hochgestellt hab werd ich schauen ob das Problem bei den nächsten Drucken wieder auftritt.

Quote
Elkroellosso
Rückschlüssig kann daher gesagt werden, dass Jerk unmittelbar Auswirkung auf Radienbefehle hat.

Nein. Zumindest nicht mehr, als dass mit höherem Jerk eine etwas höhere Geschwindigkeit erreicht wird und daher natürlich auch schneller G-code nachkommen muss. Bei Marlin muss nicht unbedingt eine Beschreibung von hier zum Quellcode von dort passen, da gibt es zig Varianten und Forks und selbst innerhalb einer Fork ist nicht immer alles auf dem neuesten Stand.

Quote
Elkroellosso
Theoretisch ist Jerk aka Ruck als Querruck zu sehen was per Definition die maximale Beschleunigung einer Beschleunigung darstellt.

Das ist nur richtig, wenn man "maximale Beschleunigung" gleich "unendlich hohe Beschleunigung" setzt. Ein Ruck ist ein Ruck, also eine Geschwindigkeitsänderung ohne Beschleunigung dazwischen.

Allerdings gibt es da ein paar Superspezialisten, die haben "Jerk" einfach mal umdefiniert zur ersten Ableitung der Beschleunigung. Das kann die (normale) Marlin nicht, bei der ist dieser Jerk, wie Du ihn beschrieben hast, immer unendlich hoch.

Streng physikalisch geht das natürlich nicht. In der Praxis sind da aber Schrittmotoren, die ohnehin mehr oder weniger ruckeln (deswegen sind sie so laut), ein relativ weicher Druckerrahmen, weiche Riemen, etc, die alle solch einen Ruck genügend dämpfen. Bekanntlich wird der Lauf des Druckers bei guter Einstellung sogar deutlich ruhiger.

Quote
Elkroellosso
Ein Deltaroboter kann aber nur lineare Bewegungen ausführen

Rein mechanisch kann ein Delta jede beliebige Figur fahren. Es gibt nur keine Firmware, die die Schrittmotoren entsprechend ansteuern kann. (Fast) all die RepRap-Firmwaren können nur Geraden. Bekommen sie einen G2 oder G3 (Kreis), zerlegen sie den erst mal in Geradenstückchen und machen dann mit den Geraden weiter.

Wenn Dein Controller überfordert ist, musst Du die erforderliche Rechenleistung verringern. Der Jerk ist da unerheblich. Was hilft:

- Langsamer drucken.
- Weniger Microstepping. (Bis zu 90% der Rechenleistung geht in die Berechnung der einzelnen Schritte)
- Schnellere Firmware.
- Schnellerer Controller. (Bei Deltas macht ein 32-Bit-Controller Sinn)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hallo Elkroellosso

Hast du an deinem Kossel Mini einen LCD.

Ich hatte auch Probleme mit der Rechenleistung mit angeschlossenem LCD gab es immer Blobs.
LCD in Marlin deaktiviert und alles lief glatt.

Danke für den Tip. Ich glaub ich start morgen oder übermorgen nochmal einen Testdruck.

Quote
Burningman
LCD in Marlin deaktiviert und alles lief glatt.

OMG. Marlin.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
Burningman
LCD in Marlin deaktiviert und alles lief glatt.

OMG. Marlin.

Das liegt kaum an Marlin sondern eher an einem FullGraphic auf einem AVR, dann noch mit einem Delta.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

OMG Traumflug
Schliess mal an Teacup ein FullGraphic an.
Achso das geht ja nicht

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

So hab jetzt definitiv die Ursache rausgefunden.

Und zwar liegt das an der zu hohen Auflösung eines STLs und dem daraus generierten GCode.

Es gibt von Johann Rocholl ein Pythonscript um Gcodes zu bereinigen. Glücklicherweise hat dieses Script eine Funktion um zu dokumentieren was es mit dem Gcode treibt.
Die Theorie mit den Radien im Gcode war falsch. Cura, bzw. wahrscheinlich alle Slicer, generiert(en) ausschließlich G1 ergo nur lineare Bewegungen. Teilweise generiert es allerdings auch Bewegungen im Bereich von 1 bis 5 Hundertstel.
Diese Bewegungen sind teilweise zu klein um eine physikalische Bewegung hervorzurufen, sind aber gleich zig-mal hintereinander vorhanden. Das erzeugt die Illusion, dass der Druckkopf steht. Man hört auch ein Brummen es bewegt sich allerdings nichts.
Nach dem Ausführen des Scripts läuft alles normal. Das Script löscht nämlich alles was sich unter 5/100 abspielt.

Anbei findet man den Link mit dem Script das man auch in Kisslicer einbinden kann.

[github.com]

Quote
Wurstnase
Ggf ist die Auflösung vom STL zu hoch.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Aber es hatte nix mit der Rechenleistung zu tun der is nur ne halbe sekunde an einer Stelle rumgekrebst und hat fleissig extrudiert. Daher kamen dann die Warzen ^^

Das Script ändert übrigens die Auflösung kaum und der Gcode is gleich mal um 20% schmäler

Nicht ganz, da kommen zwei Flaschenhälse aufeinander. Die Übertragungsrate vom Host zum Drucker und die Berechnung der einzelnen Segmente.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Le-Seaw
OMG Traumflug
Schliess mal an Teacup ein FullGraphic an.
Achso das geht ja nicht

Wenn es die Marlin dann beherrschen würde. Tut sie ja nicht. Nur vergeudete Zeit und vergeudetes Filament. Es sei denn, man hat sich den Drucker zum Display glotzen angeschafft.

So langsam wundert es mich nicht mehr, dass so Viele auf die teuren ARM-Controller abfahren. Das liegt nicht am ATmega, sondern an der Firmware drauf.

Gilt übrigens auch für die Endstops. Mechanische funktionieren einwandfrei, wenn es die Firmware im Griff hat.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Wo soll denn das Problem mit mechanischen Endstops sein?

Displayoptimierungen sind auch schon lange implementiert. Aber bei zu vielen Segmenten steigt auch Teacup aus. Das ist ja eine ganz andere Geschichte.

1-mal bearbeitet. Zuletzt am 30.07.15 06:39.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Das liegt kaum an Marlin sondern eher an einem FullGraphic auf einem AVR, dann noch mit einem Delta.

Es kann gar nicht am Display liegen, denn eine korrekt funktionierende Firmware würde das Display nur dann bedienen, wenn Zeit dafür ist.

Quote
Elkroellosso
So hab jetzt definitiv die Ursache rausgefunden.

Sagen wir mal, Du hast einen Workaround um die Macke gefunden.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
Wurstnase
Das liegt kaum an Marlin sondern eher an einem FullGraphic auf einem AVR, dann noch mit einem Delta.

Es kann gar nicht am Display liegen, denn eine korrekt funktionierende Firmware würde das Display nur dann bedienen, wenn Zeit dafür ist.

Da hast du recht. Wahrscheinlich grätscht das Display in die Planner-Berechnung.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ja und aber funktioniert hats. Du hattest ehrlich gesagt keine Lösung. :-|