Mein Drucker hat eine Gedächtnislücke

Hallo
Bis jetzt konnte ich mir bei Problemen mit meinem GEEETech Prusa i3 immer noch selber helfen. Aber bei dem neuesten Problem stehe ich vor einen wirklichen Rätsel. Irgendwann wärend des Drucks vergisst er plötzlich wo er war und fährt entgegen dem Endschalter in eine undefinierte Position, meistens Y und knallt gegen die Bande. Es ist verschieden wann es passiert, mal hat er 2mm in der Höhe gedruckt, mal aber auch 60 mm. Manchmal geht aber auch ein Druck durchgehend. Hat einer eine Idee an was es liegen könnte?

Der Gärtner

PS. ArduinoMega mit Ramps 1.4
Marlin, Slicer mit CuraEngine

... wenn per USB vom Rechner aus angesteuert -- sowas passiert bei fehlerhaftem Empfang vom PC her - dann bekommt er ab und an mal völlig falsche Koordinaten.

Versuch mal die Baudrate zu reduzieren (in der Frmware und PC-Software/USB-Verbindung) oder ein kürzeres bzw. besser abgeschirmtes USB-Kabel ...

---

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]

Hallo Viktor
Danke erstmal für die Antwort. Leider konnte ich nicht auf die schnelle das USB-Kabel tauschen, das verwendete war schon mein bestes. Bei der Baudrate bin ich etwas vorsichtig mit dem verändern in Marlin. Habe da schon viel Mist gebaut, bin leider nicht so der große Experte. Fehlende Englischkenntniss kombiniert mit dem Alter(73) mindern nicht gerade die Fehlerquote. Vielleicht hatte schon jemand das gleiche Problem, das würde jedenfalls die Suche nach der Fehlerquelle erleichtern. Übrigens ist der Versatz schon bei allen 3 Achsen aufgetreten, am meisten aber in der längsrichtung und im Extremfall knallt er dann vom Endschalter weg an den Rahmenanschlag.

Der Gärtner

1-mal bearbeitet. Zuletzt am 25.02.19 06:27.

Versuche doch mal von der Karte zu drucken.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Sehr gute Idee, Fridi. Leider hatte ich vergessen zu erwähnen dass ich den Kartenleser am Display noch nicht dazu überreden konnte. Mit anderen Worten, es funktioniert bei mir nicht. Ich bin schon froh wenigstens die Temperaturen ablesen zu können.

Der Gärtner

Klingt ja nach nem typischen Montagsmodell.

Meine Erfahrung beim Druck aus Pronterface / Repetier / whatever vom PC aus:
Lass den PC in Ruhe. Im besten Fall frischer Reboot und dann ab dafür.
Mir sind damals 3 Drucke in die Hose gegangen, bei denen der PC kurzzeitig am Laden oder Rechnen war - wodurch der Buffer vom Drucker leerlief und er einfach stehen blieb.

Gilt halt das übliche zu prüfen:
- Anderes Kabel
- Anderer Port am PC
- SD flott machen
- Auf Octoprint wechseln

Nichts desto trotz kenn ich ein ähnliches Problem von meinem Delta, der sich bei manchen Drucken einfach mal denkt: "Jetzt ein päuschen". Der Extruder fängt an die seltsamsten Geräusche zu machen und ich muss die Kiste wirklich über den Notstop ausschalten, da nichts mehr geht. Das kommt alle Schaltjahr mal vor und eine Lösung hab ich dafür auch noch nicht gefunden. Mit genau der gleichen Datei noch mal angefangen druckt er sauber durch.

---

Alle Angaben ohne Gewähr

Liegt evtl. ein 230 V Kabel (z.B. das Kabel zum Netzteil des Druckers) ganz nah oder sogar auf dem USB Kabel? Mein Drucker bricht dann gern mal einen Druck ab oder rebootet plötzlich. Wenn ich das USB-Kabel und das 230 V Kabel so 20 cm auseinander bewege, ist wieder Ruhe. Das passiert mir gelegentlich, wenn ich per PC Firmware aufspiele und den Drucker provisorisch neben den Schreibtisch quetsche.

Wenn mir solche Sachen passiert sind, lag es meistens entweder (1) an zu heiß gewordenen Stepper-Treibern oder (2) an einem abgeknickten Stepper-Kabel.

Wenn es meist die Y-Achse betrifft, könnte es ein Indiz für (1) sein, weil auf Y beim Prusa-Aufbau ja die größte Maße bewegt werden muss.

Bei (1): Die Stepper betasten und wenn sie zu warm sind für mehr Kühlung sorgen oder (wenn möglich) Stromstärke reduzieren und/oder langsamer drucken.
Bei (2): Alle vier Kabel des betroffenen Steppers prüfen. Wenn eines defekt ist (meist nah bei den Steckern), reparieren.

4-mal bearbeitet. Zuletzt am 27.02.19 02:10.

Ich hatte auf meinem Geetech anfangs ähnliche Probleme, vorallem bei langen Drucken. Da kam dann sowas wie in dem angehängten Bild bei raus.

Es lag wohl daran, dass die Beschleunigungs- und Jerk-Werte zu hoch eingestellt sind, und die Motortreiber damit mittelfristig zu warm werden und nicht mehr hinterherkommen. Sie haben sich zwar nicht übermäßig warm angefühlt (ich konnte den Finger gemütlich dauerhaft auf den Kühlkörpern liegen lassen, ohne danach Grillsteak-Muster auf der Fingerkuppe zu haben), aber seit ich die Werte runtergestellt habe, ist dieser Fehler auch bei über 12 Stunden Druck am Stück nicht mehr aufgetreten. Das fiese war, dass der Fehler meist erst nach 3-4 Stunden aufgetreten ist, man es also nicht "mal schnell" mit geänderten Werten überprüfen konnte.
Ich drucke übrigens per Karte, es kann bei mir also nicht am USB gelegen haben.

Ich verwende Marlin 1.1.8. Die relevanten Stellen sind dann in der Configuration.h ab Zeile 559 zu finden:

#define DEFAULT_MAX_ACCELERATION      {3000,3000,50,5000}   // default 5000,5000,50,5000, geändert 3000,3000,50,5000 13.09.18

/**
 * Default Acceleration (change/s) change = mm/s
 * Override with M204
 *
 *   M204 P    Acceleration
 *   M204 R    Retract Acceleration
 *   M204 T    Travel Acceleration
 */
#define DEFAULT_ACCELERATION          800		// X, Y, Z and E acceleration for printing moves; default 1000, geändert 800 03.09.18
#define DEFAULT_RETRACT_ACCELERATION  2000		// E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   2000		// X, Y, Z acceleration for travel (non printing) moves; default 3000, geändert 2000 03.09.18

/**
 * Default Jerk (mm/s)
 * Override with M205 X Y Z E
 *
 * "Jerk" specifies the minimum speed change that requires acceleration.
 * When changing speed and direction, if the difference is less than the
 * value set here, it may happen instantaneously.
 */
#define DEFAULT_XJERK                  4.0		// default 6.0
#define DEFAULT_YJERK                  4.0		// geändert 4.0 am 03.09.18
#define DEFAULT_ZJERK                  0.3
#define DEFAULT_EJERK                  5.0

Ich habe den Text jetzt mal absichtlich komplett und inklusive der Kommentare rauskopiert. Anhand meiner Kommentare siehst du, welche Werte ich wie sehr verändert habe. Wenn du es ausprobieren magst, bin ich sehr gespannt, was dabei rauskommt.

1-mal bearbeitet. Zuletzt am 03.03.19 17:42.

---

Hardware: Geeetech i3 Pro W mit GT2560 A+ Board
Software: Marlin 1.1.8 und Slic3r

Hallo
Bin erst jetzt wieder zum lesen gekommen. Das von firefrog klingt ganz nach meinem Problem, auch bei mir hat er schon oftmals einige Schichten gesponnen und dann normal weiter gedruckt, oder aber den Druck ganz abgebrochen. Ich melde mich dann wieder, ob erfolgreich oder nicht.
Eine Frage so ganz nebenbei, kann man den Arduino so einfach auslesen. Oder muss man das immer mit der config h im marlin machen?

Der Gärtner

Quote
Gärtner
Hallo
Bin erst jetzt wieder zum lesen gekommen. Das von firefrog klingt ganz nach meinem Problem, auch bei mir hat er schon oftmals einige Schichten gesponnen und dann normal weiter gedruckt, oder aber den Druck ganz abgebrochen. Ich melde mich dann wieder, ob erfolgreich oder nicht.
Eine Frage so ganz nebenbei, kann man den Arduino so einfach auslesen. Oder muss man das immer mit der config h im marlin machen?

Der Gärtner

Ich meine mal irgendwo gelesen zu haben, dass die Steppertreiber, wenn sie zu warm werden, kurzzeitig in einen "Sparmodus" gehen, um abzukühlen, und danach wieder normal weitermachen. Das würde erklären, warum er nach einer kurzen Spinnerei wieder normal weiterdruckt.

Du kannst über Pronterface, Octoprint und ähnliche Programme sowohl Daten auslesen als auch schreiben. Sämtliche Befehle dafür sind hier zu finden - allerdings ist das sehr viel und alles auf englisch...

---

Hardware: Geeetech i3 Pro W mit GT2560 A+ Board
Software: Marlin 1.1.8 und Slic3r

Es ist eigentlich untypisch, dass der Drucker bei überhitzten Motoren oder Treibern "in eine Richtung" fährt. Eher bleibt er stehen bis die Temperatur wieder etwas abgekühlt ist und macht dann weiter. Üblicherweise durch einen dicken Blob sichtbar, da die Düse einfach ausläuft. Schuld daran ist oftmals ein zu hoher Vref der Treiber.

Dieses "in eine Richtung" fahren ist eher ein Kommunikationsfehler, ein beschädigter Baustein des Gcodes bspw. oder halt eben eine Störung des Signals.
Stehenbleiben und hacken sowie Steploss ist dann Motor / Treiber Sache.
Aber Ausnahmen bestätigen bekannterweise die Regel.

Was das auslesen betrifft:
Bei oft zu ändernden Werten wie bspw Steps/mm und Jerk ist das, wie Firefrog schon sagte, mit den genannten Programmen möglich. Der sogenannte "EEPROM" wird dabei ausgelesen und in diesen geschrieben. Mittels M-Command wird dann dieser abgespeichert und in die Firmware übernommen.
Die komplette Firmware lässt sich jedoch nicht auslesen. Diese ist kompiliert und abgespeichert. Ergo lohnt es sich, eine Basis-Firmware auf der Festplatte zu haben, auf der man jegliche Änderungen mittels Kommentare dokumentiert und protokolliert (Datum, ggf. Zeit, was geändert wurde) so dass man beim Totalausfall einfach auf die letzte Version zurückgreifen kann.

---

Alle Angaben ohne Gewähr