Extruder bohrt sich in Druckobjekte

[[email protected]]

dass der Kopf anstatt UM -1mm AUF -1mm absolut

Kannst du mir das nochmal anders erklären?
Was ist UM und was meinst du dann mit AUF ...

Es sieht so aus, als ob er die Reihenfolge der Befehle verwürfeln würde und anstatt relativ UM 1 mm nach links zu fahren geht er AUF die absolute Koordinate 1mm (nahe der Home-Position). Tatsächlich tangiert mich dieses Problem weniger - die Sprünge in der Z-Richtung (die möglicherweise unbeobachtet auch bei X und Y auftreten - aber da nicht so katastrophale Ergebnisse hinterlassen) sind viel schlimmer - ich hatte das lediglich erwähnt, da es hier möglicherweise Zusammenhänge gibt...

Vorab: Jenachdem ob der Drucker ungehomed ist, gehomed ist, oder die Z-Kompensation an ist, verhält er sich ein wenig anders, was sein Stop-Verhalten am Schalter oder bei "Override Max" betrifft. Ich hatte für mich selbst an diesen Punkten in der Firmware einiges geändert, sodass ich nicht mehr überfahren kann, egal was ich dem Drucker für Kommandos gebe.
Dabei bin ich auf ein paar Ungereimtheiten gestoßen, die ich noch nicht vollständig verstanden habe.
Das Free-Z habe ich in meiner persönlichen Test-Version inzwischen komplett entfernt, weil das die RF1000-Schalter killt, wenn man auf Doppelschalter-Circuit stellt und den Drucker mit gedrücktem Z-Schalter bootet...

Bitte nicht das leidige Thema z-Schalter (meinen hat die FW ebenfalls gehimmelt) eröffnen - das ist (entschuldigung) PEINLICH für Conrad, hat aber glaube ich nichts mit meinem Problem zu tun.

Irgendein Bug existiert. Das weiß ich.
Doch meine sind etwas anders, evtl. hilfts:
- Wenn man wiederholt in die Pause geht und fortsetzt verzählen sich manchmal die Achsen.
- Wenn man sich unterhalb der Max-Z-Compensation-Höhe befindet und mit den Z-Tasten Z bewegt verzählt sich manchmal der Drucker. Man kann also mit G28 und M3001 und den Hoch-Runter-Tasten irgendwie die Skala der Z-Millimeter bescheißen. Danach ist Z=0 nicht mehr bei 0mm ab Schalter.
Dabei gehts aber vermutlich um ein Zusammenspiel zwischen der eigentlichen Steuerung und diesem direct-Move. Aber du beschreibst was das beim wechseln der Absolut-Relativ-Systems betrifft?

Wo ich aufgehört habe zu suchen:
Wenn ein Step gemacht wird, wird er gezählt, wenn der Achse eine Richtung zugeordnet ist, nicht wenn sie 0 ist. Und evtl. gibts Probleme, wenn die Funktion mehrfach läuft?? Ist aber alles nur Spekulation.
Ich hatte an dieser Stelle irgendwann aufgegeben und das komische Verhalten einfach gemeldet. Darum warte ich seit längerem sehnsüchtig auf die 1.38 um diese Version anzuschauen, was das Problem war

LG

[Nibbels]

Wegen Z:

Komische Werte in der Z-Matrix stehen bei dir nicht, nehme ich an? (Kannst du die mal posten, nicht dass da irre peaks drin sind.)
Deine Z-Schraube sollte auch in Ordnung sein, oder?

Zum Relativ-Absolut-Problem:

Die G90/91 sind eigentlich nicht sonderlich kompliziert:

Screenshot_1.png

Screenshot_2.png

G90 stellt den oberen Block aktiv, G91 den unteren... hmm.
Mir stellt sich die Frage, warum man G90 direkt vor G91 senden sollte.
Dennoch: ich hab mir das grad nur angesehen, um zu prüfen, ob nicht beim Screenshot 1 ein einfaches "Commands::waitUntilEndOfAllMoves();" vor beiden Umstell-Vorgängen helfen könnte.

Das ist der weniger interessante Fehler, aber da du gerade "eingearbeitet bist":
Wenn du die Firmware so änderst:

Screenshot_4.png

Wäre dann das Problem mit G90 G91 G1 Z-1 behoben? (Würde mich persönlich interessieren, sodass ich das gleich in den Community-Mod einbauen kann, wenns klappt ...)

LG

[[email protected]]

Wegen Z:

Komische Werte in der Z-Matrix stehen bei dir nicht, nehme ich an? (Kannst du die mal posten, nicht dass da irre peaks drin sind.)
Deine Z-Schraube sollte auch in Ordnung sein, oder?

Wird heute Abend geprüft - aber eigentlich bin ich davon ausgegangen, dass die Kompensationsmatrix lediglich in den/der untersten Layer aktiv wäre ... ich sehe die Fehlstellen (wenn sie auftreten) übers ganze Objekt verteilt..

Zum Relativ-Absolut-Problem:

Die G90/91 sind eigentlich nicht sonderlich kompliziert:
Screenshot_1.png
Screenshot_2.png

G90 stellt den oberen Block aktiv, G91 den unteren... hmm.
Mir stellt sich die Frage, warum man G90 direkt vor G91 senden sollte.

Erschließt sich mir auch nicht - da scheint der Host zu interferieren - hat er einmal das G91 "gesehen" hört der Spuk auf. (kann gerne Versionen nachliefern). Weswegen ich das Problem erwähne: für mich sieht das so aus, als ob da 2 Threads teilweise parallel abgearbeitet würden und es dabei sporadisch zu falscher Abarbeitung käme. Das wäre ein grundsätzliches Problem - ein waitUntilEndOfAllMoves scheint mir hier ein unsauberer Workaround - die Kommandos kamen schließlich in korrekter Reihenfolge im Repetier an. (zumindest lt. Log des Hosts) Selbst das unerwartete Einflexen der G90,G91 Sequenzen durch den Host ist schon in meinen Augen ein Bug, der beseitigt werden müsste. Ich befürchte nur, der eine Bug ermöglicht es gerade einen anderen zu beobachten. Ich kann deinen Ansatz aber gerne heute Abend prüfen! Gegen welche Version soll ich patchen?

Dennoch: ich hab mir das grad nur angesehen, um zu prüfen, ob nicht beim Screenshot 1 ein einfaches "Commands::waitUntilEndOfAllMoves();" vor beiden Umstell-Vorgängen helfen könnte.

Das ist der weniger interessante Fehler, aber da du gerade "eingearbeitet bist":
Wenn du die Firmware so änderst:

Screenshot_4.png

Wäre dann das Problem mit G90 G91 G1 Z-1 behoben? (Würde mich persönlich interessieren, sodass ich das gleich in den Community-Mod einbauen kann, wenns klappt ...)

LG

[Nibbels]

"Gegen welche Version soll ich patchen?"

Wenn du die Firmware meinst, immer 1.37, alles andere ist veraltet und hat Bugs, die ich selbst nicht mehr sehen wollte ^^.
>Siehe Watchdog bis zur 1.33 oder 1.35 und so.

Ich glaube, dass Repetier-Server oder Repetier-Host anfangs immer die Koordinaten umstellt, erinnere mich aber nicht mehr ganz genau. Ich hatte mal bei G90/91 einen Consolen-Kommentar eingefügt und der wurde beim Verbinden zum Drucker ausgegeben. Das ist aber inzwischen schon etwas weiter weg und ich kenne die Details nicht mehr.

Unsauber: Ja. Aber wenn es hilft, kann man an der Stelle weitermachen und prüfen, wieso es hilft. Wenn es nicht hilft, kann man es ausschließen.
https://github.com/Nibbels/Repetier-Firmware/ -> https://github.com/Nibbels/Repetier-Fir ... s.cpp#L925
Dort habe ich es mal reingenommen und in mein Board eingespielt. (Drucke aber jetzt und ich muss erst herausfinden, wie ich diesen Bug reproduzieren könnte.)
Hier haben die offiziellen Repetier-Entwickler nichts daran geändert:
https://github.com/repetier/Repetier-Fi ... .cpp#L1154
Das spricht gegen meinen Tipp. Ausser du bist der Erste mit diesen Problemen.

Es gibt in der Firmware Caches, wie hier vermerkt:
https://github.com/Nibbels/Repetier-Fir ... ion.h#L945
https://github.com/Nibbels/Repetier-Fir ... 000.h#L890
Das deutet darauf hin. Ich habe daran aber noch nie was verändert. -> Gefährliches Halbwissen.
Bewegungen kommen vermutlich in den Move-Cache und werden anschließend in Reihe ausgeführt. Lüftersteuerung etc. evtl. nicht, dass die Bewegungen flüssiger bleiben??

Wenn diese Umkehr-Effekte im gesamten Druck ständig vorkommen: Das ist schon arg merkwürdig, denn ich kenne sowas nicht.
Hast du ein Foto davon?
Man kann bei sowas auch immer spekulieren, ob die Ursache nicht auch eine Abart eines Fehlers durch Kabelbruch oder schleichenden Kabelbruch sein könnte.

[[email protected]]

"Gegen welche Version soll ich patchen?"

Wenn du die Firmware meinst, immer 1.37, alles andere ist veraltet und hat Bugs, die ich selbst nicht mehr sehen wollte ^^.
>Siehe Watchdog bis zur 1.33 oder 1.35 und so.

Ich glaube, dass Repetier-Server oder Repetier-Host anfangs immer die Koordinaten umstellt, erinnere mich aber nicht mehr ganz genau. Ich hatte mal bei G90/91 einen Consolen-Kommentar eingefügt und der wurde beim Verbinden zum Drucker ausgegeben. Das ist aber inzwischen schon etwas weiter weg und ich kenne die Details nicht mehr.

Unsauber: Ja. Aber wenn es hilft, kann man an der Stelle weitermachen und prüfen, wieso es hilft. Wenn es nicht hilft, kann man es ausschließen.
https://github.com/Nibbels/Repetier-Firmware/ -> https://github.com/Nibbels/Repetier-Fir ... s.cpp#L925
Dort habe ich es mal reingenommen und in mein Board eingespielt. (Drucke aber jetzt und ich muss erst herausfinden, wie ich diesen Bug reproduzieren könnte.)
Hier haben die offiziellen Repetier-Entwickler nichts daran geändert:
https://github.com/repetier/Repetier-Fi ... .cpp#L1154
Das spricht gegen meinen Tipp. Ausser du bist der Erste mit diesen Problemen.

Es gibt in der Firmware Caches, wie hier vermerkt:
https://github.com/Nibbels/Repetier-Fir ... ion.h#L945
https://github.com/Nibbels/Repetier-Fir ... 000.h#L890
Das deutet darauf hin. Ich habe daran aber noch nie was verändert. -> Gefährliches Halbwissen.
Bewegungen kommen vermutlich in den Move-Cache und werden anschließend in Reihe ausgeführt. Lüftersteuerung etc. evtl. nicht, dass die Bewegungen flüssiger bleiben??

Wenn diese Umkehr-Effekte im gesamten Druck ständig vorkommen: Das ist schon arg merkwürdig, denn ich kenne sowas nicht.
Hast du ein Foto davon?
Man kann bei sowas auch immer spekulieren, ob die Ursache nicht auch eine Abart eines Fehlers durch Kabelbruch oder schleichenden Kabelbruch sein könnte.

Meine Untersuchungen waren etwas vollständiger, als schriftlich hier dokumentiert.
o Drucker ist 2 Monate alt (Bausatz)
o Problem tritt mit z-Raise auf (nicht sicher, ob auch ohne diese Funktion)
o Problem lässt sich nicht auf die Mechanik zurückführen (z-Antrieb einwandfrei, Zahnräder drehen nicht durch, Platte fährt elektrisch angetrieben(!) mal runter, mal hoch.
o Delta entspricht leider nicht der Hohe des Z-Lift (das wär ja zu einfach)
o Häufigkeit: bei 0.5mm Z-Lift und einem "zerklüfteten" Objekt (untiteled flower aus thingiv.) mit 8cm Gesamthöhe 6h Druckzeit tritt das Problem c.a 1-2 Mal auf
o Stepper verliert keine Steps
o kein Durchdrehen aufgrund von schwergängiger Mechanik
o Testweise Reduzierung der Z-Acceleration auf 1/20tel brachte - abgesehen von der Verlangsamung des Druckes) keine Besserung

Symptom: entweder eine Wulst im Objekt (Tisch ging hoch) oder Extruder druckt etwas in Luft, Objekt weist nachher Sollbruchstelle auf oder kommt gar nicht mehr in den Tritt und macht nur noch Spaghetti.

[Nibbels]

Was ungemein helfen würde, wäre ein Bild des Fehlers.
Denn unter Umständen kenne ich das und kann dann selbst meine Teile auf diese Macke untersuchen.

Layerungewöhnlichkeiten hatte ich auch, aber ich habe sie auf schwankende Digits/Popel in der Düse geschoben und diese dann per Firmware kompensiert. Seitdem, oder ich bilde mir das eher ein, ist meine Oberfläche quer zu den Lagen glatt. (Vorallem PETG ist glaube ich schöner, weil wegen der Konsistenz die Digits zwischen 3000 und 8000 geschwankt hatten.)
Durch die Kompensation habe ich extrem viele Z-Moves generiert, ausgeführt durch die Z-Kompensation. Und das quer durchs ganze Bauteil. Bei jeder zählbaren Digit-Änderung wird auch das Bett in seiner Höhe minimal angepasst.
Diese Bewegungen sind von den Z-Vertical-Lifts von 0.1mm überlagert (bei PLA habe ich das so eingestellt).

[Nibbels]

So wie auf den Bildern sah das aber nicht aus, oder?
http://www.rf1000.de/viewtopic.php?f=72&t=1853

LG

[[email protected]]

So wie auf den Bildern sah das aber nicht aus, oder?
http://www.rf1000.de/viewtopic.php?f=72&t=1853

LG

Nope!
Wenn, dann genau eine deutliche Wulst! Aber meistens reißt in dem Augenblick der Extruder das Objekt auch schon vom Tisch - er druckt dann halt ca. 0.5-1 mm tiefer im Objekt weiter - bzw. er versucht es...)

Bilder kommen heut Abend!

[[email protected]]

Weitere Hintergrundinfos zu den z-Sprüngen:

o ich benutze NICHT den Firmware-Retract sondern lasse das Retract und z-Lift durch Slic3r durchführen

... und zum Problem mit dem schnellen (sehr schnell muss es gar nicht sein!) Druck der Bewegungsknöpfe im Host
o betrifft alle Achsen
o er fährt tatsächlich auf die absoluten Koordinaten anstatt - oder + 1mm zu fahren
o betätige ich den Knopf (z.B. X um +1mm) halbwegs schnell weiter, so kann ich das ungeplante Homing sogar wieder abbrechen (er fährt dann nicht bis zu 1mm sondern stoppt schon unterwegs und geht dann +1mm nach rechts

Anbei die Bilder der Fehlstellen
o spiralvase mit Sprung nach unten (2 Stück)
o vronifrau mit 3 Fehlstellen (vmtl nach oben)
o untiteledflower mit 1 Fehlstelle nach oben (da gehört noch ein Haufen Wolle dazu, den ich bereits entsorgt hatte)

Anfangs hatte ich den Extruder in verdacht, einfach kein Filament mehr zu liefern - das ist mittlerweile ausgeschlossen (ich sehe tatsächlich unerwartet z-Achsenbewegung in die falsche Richtung)

[[email protected]]

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