Extruder bohrt sich in Druckobjekte

[[email protected]]

es geht um die Aufwärtsbewegung des Tisches, und die sollte ja wohl erst wieder möglich sein, wenn das Werk vollendet ist, oder?)

Funktion "z-Lift" nicht verstanden - setzen, sechs! ;-P

[hal4822]

Funktion "z-Lift" nicht verstanden - setzen, sechs! ;-P

Ganz recht, habe bisher aber auch nicht danach gesucht. In der Suche fördert "z-Lift" aber verdächtig oft "lift nozzle" zutage, was ja nun wohl suggeriert, dass die Düse angehoben wird; gemeint ist aber sicher, dass der Tisch gesenkt wird. Andernfalls habe ich keinen RF1000.
Bevor ich jetzt aber 6 Seiten durchwühle, was es da noch für irreführende Wortschöpfungen geben könnte, bleibe ich derweil lieber sitzen.

Bis die Weisen den göttlichen Ratschluss gefunden haben.

[[email protected]]

Ok,... wenn wir uns aufs Z-Schalter-Schrotten einigen:

Neinneinein! Darüber bitte später und in einem anderen Thread!

Ich hab mich vor einiger Zeit mit dem Thema bei folgenden Links beschäftigt:
http://www.rf1000.de/viewtopic.php?f=67&t=1748
http://www.rf1000.de/viewtopic.php?f=67&t=1747
[ http://www.rf1000.de/viewtopic.php?f=67&t=1746 ]
[ drive-free problematik ]

Was ich nicht getestet habe ist das Verhalten beim G-Code. Die Tasten und Menübefehle habe ich in der Community-Firmware komplett überarbeitet.
Ohne Homing sollte über die Tasten jedes Überfahren absolut verboten sein. Mit Homing nur noch Stepwise und größere Fahrten durch Menübedienung brechen nun immer korrekt beim Schalter ab.

Wie ich sehe hast du die Z-Ebene auf Z = 64mm gefahren und dann 63,5/64/63,5/64/63,5/64/...
Wenn du mir einen G-Code zusammenstellst, der bei dir schiefgeht, dann teste ich das bei mir! Ich kann nur gerade nicht 100% den eigentlichen Knackpunkt in deiner Beschriebung finden, sodass ich wüsste, wo genau ich was anklicken oder ansteuern müsste, um einen echten Fehler zu provozieren.

Das Log ist ein Auszug aus einem Druck, der bis 64mm sauber gebaut hat. z-Lift stand auf 0.5, daher kommen die 63,5/64/63,5...
Dann ist er um ca 1 mm ins Objekt runtergefahren, hat noch ca. 4 Retracts (mit Lift) gemacht (während er das Objekt vom Tisch riss) und ich habe Pause gedrückt.
Leider ist eben dieses Problem anscheinend nicht zuverlässig und leicht reproduzierbar. Es tritt halt bei einem von geschätzten 10000 Z-Lifts auf.

Das leichter Reproduzierbare Steuerproblem (Bewegung über manuelle Kontrolle am RepetierHost) lag/liegt am Repetierhost. Da es sich recht leicht umschiffen lässt, ist mir das relativ egal. Reproduzierbar ist mein akutes Problem (theoretisch) mit dem vor 1-3 Mails gesendeten flower02.gcode. Das Objekt weist recht viel z-Lift auf und lässt sich bei mir beinahe nicht drucken (2v3 Fails).

PS: Mein Drucker lief nun wieder ca. 20h am Stück durch - ohne ein Murren. Es könnte unter Umständen tatsächlich ein Temperaturproblem sein? Vorgestern wars hier 10°C heißer.

[Nibbels]

Thema entwirren ist super

[rf1k_mjh11]

[email protected],

In der Log-Datei konnte ich keinen Hinweis finden, dass die Düse nach unten (hier für hal4822: "das Bett nach oben") fahren soll. Abgesehen von den vielen z-lifts (Lift Z, z-hop, ...). Damit liegt der Fehler nicht direkt im generierten GCode (indirekt vielleicht noch immer ...). Laut der Log-Datei hätte die Düse nicht in das Objekt fahren sollen.

Ich konnte in dem Log-Abschnitt auch keine G91 / G90 Kombinationen finden. Damit ist das als die eigentlich zugrunde liegende Ursache ebenfalls ausgeschlossen (beitragen könnte es natürlich immer noch).

Hier was älteres:

Die Steuerproblematik wird eindeutig vom Host erzeugt. Ich hatte bislang wohl nicht genau genug geschaut, aber der macht - zumindest in der 1.6.2RF-Version kaputten GCode.

Repetier-Host erzeugt eigentlich keinen GCode. Da wird einfach ein externer Slicer (Slic3r, Skeinforge, Cura, oder was man sonst dazu konfiguriert hat) dafür eingesetzt. Repetier-Host stellt quasi nur die Oberfläche zur Verfügung.
Du könntest einmal direkt im jeweiligen Slicer den Code generieren lassen, um zu sehen, ob derselbe G90/G91 Fehler auftritt.

mjh11

[Marcometaner]

Ich habe gerade folgende Matrix aktiv (die leider mit dem gleich folgenden Firmware-Test wieder übergebügelt wird ... #snif#)
21:11:31.816: M3013: current heat bed z-compensation matrix:
21:11:31.819: front left ... front right
21:11:31.822: ... ... ...
21:11:31.823: back left ... back right
21:11:31.829: ;7;0;15;35;55;75;95;115;135;155;175;195;215;235;245
21:11:31.836: ;0;-1016;-1016;-1036;-1092;-1116;-1044;-992;-1016;-1132;-1192;-1172;-1100;-1180;-1180
21:11:31.843: ;30;-1016;-1016;-1036;-1092;-1116;-1044;-992;-1016;-1132;-1192;-1172;-1100;-1180;-1180
21:11:31.850: ;50;-572;-572;-552;-1020;-1032;-1056;-1020;-1008;-1140;-1172;-1136;-1156;-1176;-1176
21:11:31.859: ;70;-512;-512;-1136;-1128;-1072;-1132;-1080;-1064;-1168;-1176;-1156;-1264;-1204;-1204
21:11:31.866: ;90;-504;-504;-1100;-1248;-1220;-1168;-1152;-1120;-1240;-1276;-1272;-1260;-1252;-1252
21:11:31.873: ;110;-808;-808;-1032;-1112;-1132;-1056;-1084;-1028;-1184;-1216;-1280;-1232;-1240;-1240
21:11:31.880: ;130;-396;-396;-1060;-1084;-1152;-1048;-1068;-1052;-1192;-1196;-1256;-1204;-1300;-1300
21:11:31.889: ;150;-324;-324;-1036;-1044;-1160;-1028;-1052;-1000;-1212;-1224;-1200;-1252;-1296;-1296
21:11:31.896: ;170;-532;-532;-1000;-1016;-1084;-948;-1048;-1004;-1208;-1220;-1236;-1296;-1368;-1368
21:11:31.903: ;190;-332;-332;-764;-1008;-1112;-1016;-1120;-1084;-1196;-1288;-1340;-1364;-1332;-1332
21:11:31.910: ;210;-552;-552;-452;-1044;-1140;-1044;-1084;-1128;-1268;-1328;-1388;-1292;-1372;-1372
21:11:31.917: ;230;-96;-96;-332;-908;-1104;-984;-1028;-1080;-1244;-1244;-1344;-1168;-1400;-1400
21:11:31.926: ;245;-96;-96;-332;-908;-1104;-984;-1028;-1080;-1244;-1244;-1344;-1168;-1400;-1400
21:11:31.929: offset = -96 [steps] (= -0.04 [mm])
21:11:31.930: g_uZMatrixMax[X_AXIS] = 14
21:11:31.933: g_uZMatrixMax[Y_AXIS] = 13
21:11:31.935: g_nActiveHeatBed = 1

Hallo, irgendwas stimmt mit Deinem Druckbett nicht.
Eine größere Differenz als 0.2mm sollte hier eigentlich nicht vorkommen.
So halte ich es zumindest und der Produzent der für uns die Drucker zusammen baut
sollte seit einiger Zeit auch diesen Richtwert haben.
Generell sollte etwas mehr aber auch kein Problem sein, aber bei Dir finde ich das zu viel.

Du hast von dem einen auf den anderen Punkt daneben schon bis zu 0.25mm Unterschied.
Über das ganze Bett verteilt ist die Düse maximal 0.58mm und minimal 0.04mm vom Bett entfernt.

Poste bitte mal die Matrix die ausgegeben wird wenn Du
M3013 P1
ausführst, nicht dass ich mich verrechnet habe.

Richte bitte das Bett nochmal neu aus oder entferne eventuelle Rückstände vom Druckbett.
Dann führe einen Scan PLA aus, wie er in der aktuellsten Anleitung beschrieben ist.
Achte hier bitte möglichst darauf, dass Abstand auf 0.3mm an der höchsten Stelle vom Druckbett eingestellt ist,
wenn Bett und Extruder aufgeheizt (230/60) sind.
Aktuell dürfte dieser Punkt hinten links sein, sollten hier keine Rückstände auf der Platte sein, wird diese an der Stelle verbogen sein.

https://drive.google.com/open?id=0B9K-v ... 3hjRElmczQ


PS: Ich konnte Deine Datei bislang 2x drucken, bislang ohne den Fehler.
Jedoch muss ich sagen, dass für ein Objekt dieser Art und Größe eine geringere Druckgeschwindigkeit besser wäre.

Auch dass der Retract auf 0.0001 eingestellt ist ist nicht optimal da ich hier sehr viele Fäden habe.
War wohl nur für einen Test so nehme ich an.
Könntest Du das Teil nochmal hochladen wie Du es normal drucken würdest, dann teste ich nochmal.
Und eventuell mal die STL verlinken, danke.

MfG

[Marcometaner]

Nachtrag:
die nächsten 2 Ausdrucke hatten Fehler.
Einmal sah es so aus als ob er für einen oder mehrere Layer nicht weiter nach unten gefahren ist und einmal als
ob er zu weit nach unten gefahren ist...
Das sollte sich RF1000 am besten mal anschauen. Das File liegt ja vor.
Es trat an unterschiedlichen Stellen auf, die Datei war die gleiche also liegt es, denke ich, an der Firmware.

PPS: Der bestellte Motor sollte Anfang nächster Woche geliefert werden

[Nibbels]

Ich drucke jetzt auch den GCode : Mit der Änderung, dass ich die Temperaturen runtergenommen und Sense-Offset aktiviert habe.
Allerdings drucke ich den mit meinem "nicht-community-Mod".
(https://github.com/Nibbels/Repetier-Firmware , statt wie normal https://github.com/RF1000community/Repetier-Firmware)

[[email protected]]

[email protected],

In der Log-Datei konnte ich keinen Hinweis finden, dass die Düse nach unten (hier für hal4822: "das Bett nach oben") fahren soll. Abgesehen von den vielen z-lifts (Lift Z, z-hop, ...). Damit liegt der Fehler nicht direkt im generierten GCode (indirekt vielleicht noch immer ...). Laut der Log-Datei hätte die Düse nicht in das Objekt fahren sollen.

danke, dass das nochmal jemand anderes bestätigt hat!

Ich konnte in dem Log-Abschnitt auch keine G91 / G90 Kombinationen finden. Damit ist das als die eigentlich zugrunde liegende Ursache ebenfalls ausgeschlossen (beitragen könnte es natürlich immer noch).

das ist richtig - ich hatte anfangs gedacht, dass meine 2 Probleme möglicherweise zusammenhängen, dass möglicherweise eine "ungünstige Abfolge" das Problem auslösen würde. Mittlerweile scheint sicher, dass das G90G91-Problem lediglich darauf basiert, dass G91 manchmal einfach gar nicht gesendet wird.

Hier was älteres:

Die Steuerproblematik wird eindeutig vom Host erzeugt. Ich hatte bislang wohl nicht genau genug geschaut, aber der macht - zumindest in der 1.6.2RF-Version kaputten GCode.

Repetier-Host erzeugt eigentlich keinen GCode. Da wird einfach ein externer Slicer (Slic3r, Skeinforge, Cura, oder was man sonst dazu konfiguriert hat) dafür eingesetzt. Repetier-Host stellt quasi nur die Oberfläche zur Verfügung.
Du könntest einmal direkt im jeweiligen Slicer den Code generieren lassen, um zu sehen, ob derselbe G90/G91 Fehler auftritt.

mjh11

Für den Objekt-Gcode stimme ich dir sofort zu - aber wenn ich im Host unter "manueller Kontrolle" den Tisch hoch- oder runterfahre, wird doch wohl für die daraus erwachsenen G-Befehle (G1 Z+-n)wohl kaum ein Slicer bemüht, oder?

[[email protected]]

Nachtrag:
die nächsten 2 Ausdrucke hatten Fehler.
Einmal sah es so aus als ob er für einen oder mehrere Layer nicht weiter nach unten gefahren ist und einmal als
ob er zu weit nach unten gefahren ist...
Das sollte sich RF1000 am besten mal anschauen. Das File liegt ja vor.
Es trat an unterschiedlichen Stellen auf, die Datei war die gleiche also liegt es, denke ich, an der Firmware.

PPS: Der bestellte Motor sollte Anfang nächster Woche geliefert werden

DAS ist mein Mann!
Im Ernst: Das scheint mein Problem zu sein! (auch wenn deine Drucke insgesamt etwas schlechter aussehen als meine - aber die Fehlerbilder kommen mir SEHR bekannt vor!

Übrigens ist die "spiral vase" (schwarze Vase auf meinen Photos) - wie ich mittlerweile rekapituliert habe - vmtl. ganz ohne z-Lift entstanden (vase-modus - daher höchstens Retract+zlift bei Layer-Wechseln). Auch dabei sind mehrfach Layer zusammengestaucht worden.