Hallo,

Ich habe mir gerade Gedanken gemacht falls dieses Problem auch beim Fräsen auftritt könnte das im schlimmsten Fall zu Beschädigungen am Drucker führen!
Dann sollte man das Fräsen von der sd meiden.

Lg nikibalboa

Ja! Dss kann gefärhöich werden
Kannst du bitte mal schauen was du dagegen machen kannst pls
Mfg

@nibbels:

Ich möchte einen Fehler in der stable firmware melden, der mir bei meinem Dual Extruder Umbau aufgefallen ist:

====

Jetzt kommt ein kleines Problem beim Testen im Menü, was ich nicht verstehe:

# Ich heize Extruder 1 auf 180 °C auf.
# Dann wechsele ich den aktiven Extruder auf Extruder 1.
# Warte bis 180 °C erreicht wurden.
# Jetzt will ich den Extrudermotor drehen lassen: und es tut sich nichts. Man hört einen Klick, aber der Motor ist stromlos.
Der Filamentvorschub bleibt auch bei 0.00mm?
Die serielle Schnittstelle gibt aus:

X:0.00 Y:0.00 Z:0.00 E:NAN

====

Ich bin jetzt auf die Developement firmware umgestiegen, und siehe da: der Fehler ist weg und Extruder 1 funktioniert einwandfrei!

@anwofis, ich glaube ich weiß was da los war. Laut dem anderen Thread hast du von single auf dual geflashed.
Dein Eeprom mit den extrudersettings wurde aber als single initialisiert.
Wechselst du dann mit demselben Eeprom-Mode auf Dual-Extruder blieb bisher ohne Werksreset das Eeprom bestehen. Aber mit Zufallseinstellungen für dein rechtes Hotend.

Ich habe das vor ein paar Wochen/Monaten gemerkt und eingebaut, dass der Drucker die Anzahl der Hotends im Eeprom notiert. Startet der mit zwei statt vorher einem Hotend werden die Eepromwerte des zweiten Hotend mit denen aus der Configuration.h überschrieben.

LG

was kann man nun dagegen machen, wenn der Extruder dann eben gegen den Endschalter fährt während dem Drucken und mir somit meine Drucke versaut hat jemand eine Idee?

Mit dem Mod sollte man aktuell nur über USB drucken.

Ich will versuchen das zu lösen. Aber meine Zeit ist aktuell beschränkt und ich kann noch nicht genau nachvollziehen warum das passiert.
Also kenne ich die Lösung nicht und muss raten.

Ausgeschlossen haben wir das motion-, achskoordinaten- und Gcode-system.
Wenn das wirklich nur über SD drucken vorkommt. Wir haben nun viele Berichte da drüber, dass es beim Druck über SD passiert. Aber wenige Aussagen über den Gegentest.
Ich selbst kann grad nicht im Keller sitzen und aufpassen obs passiert.

Mit SD als einzige Quelle kann man natürlich auch die offizielle 1.42 / 1.39 nutzen.

LG

Ok Danke! Ich werd dann erstmal mit der 1.42 Drucken
Mfg

@nibbels:

Vielen Dank für die Information! Das erklärt alles. Ich habe das EEPROM in der Tat nicht resettet nach dem Flashen von Single auf Dual Extruder! Ich bleibe jetzt erstmal bei der developement version - funktioniert sehr gut!

Ich freue mich über jede Rückmeldung was Dual-Betrieb mit der 1.43.8x betrifft. Ich konnte damit noch nicht dual drucken. Hab nur extruderwechsel usw. durchgetestet.

Lg

Ich habe vorher die komplette SD-Library mit dem aktuellen Stand von Github überschrieben.
Sollte ich beim übertragen der einzelnen Patches des Codes einen Fehler gemacht haben dürfte das Problem nun weg sein.
Ich glaube aber nicht so wirklich dran. Das ist also eher als Vorsichtsmaßnahme einzuordnen.

Zusätzlich habe ich noch einen Schalter gefunden und auf 0 gesetzt:
- #define USE_MULTI_BLOCK_IO 0
Ich hoffe damit mit etwas weniger dynamischem Ram auszukommen. Zumindest ist die Grenze der automatischen Parametereinstellung der Ram des Mikrocontrollers.
.. könnte also was bewirken.
-> 1.43.88
Es ist dennoch hochexperimentell mit der FW von SD zu drucken. Aber "nur wie bisher". Das heißt auch, dass diese Home-Fahrten nur noch hier gemeldet werden sollten, wenn sie ab 1.43.88 passieren.

LG