Ich hab das Modell nun 3x gedruckt und keine Fehler.
Änderungen:
- Ich habe PLA verwendet und daher 200/195°C draus gemacht.
- (Modfirmware) SenseOffset des Mods ist in der ersten Lage aktiv.
- (Modfirmware) DigitCompensation auch.
Nibbels hat geschrieben:Ich hab das Modell nun 3x gedruckt und keine Fehler.
Änderungen:
- Ich habe PLA verwendet und daher 200/195°C draus gemacht.
- (Modfirmware) SenseOffset des Mods ist in der ersten Lage aktiv.
- (Modfirmware) DigitCompensation auch.
hmmm... ok .... also ich würde die Temperaturumstellung mal aus den möglichen Schuldigen rausnehmen. Dass du eine andere FW benutzt .... und einen anderen Drucker (mit anderer Platine) ... macht das Eingrenzen leider gerade nicht leicht....
Ich habe gerade mal einen Versuch mit extremem ZLift (2mm) gemacht, der nicht lange durchgehalten hat und denselben Druck nochmal mit minimalem ZLift (0.15mm) - es sieht ein wenig so aus, als ob die Wirkund des Fehlers von der Höhe des Lifts abhängt: bei kleinem ZLift scheinen die Fehler ebenfalls kleiner. Würde vermuten, dass die Fehler bei sehr kleinem ZLift nur so geringe Auswirkungen haben, dass lediglich eine "Störstelle" im Objekt sichtbar ist. Anders kann ich mir nicht erklären, dass dieser Fehler so lange unerkannt geblieben ist.
[email protected] hat geschrieben: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?
Da hast du natürlich recht. Da sendet Repetier-Host den GCode direkt an den Drucker (so wie er auch regelmäßig die Temperatur abfragt und die voraussichtliche Druckdauer anzeigen lässt). Ich muss auch gestehen, gelegentlich hier in Repetier-Host 'Fehler' zu generieren.
Der Hergang:
Oft mache ich vor einem Druck, währen das Bett aufheizt, ein Homing, gleichzeitig oder unmittelbar danach klick ich 3x auf "50mm nach rechts" (X achse). Der Drucker fährt an die richtige Position (X=150), aber die Koordinatenanzeige im Host zeigt gelegentlich nur 100mm. (Ich fahre dort hin, nur damit ich die Düse besser säubern kann.). Der 'Fehler' hat noch nie (?) zu einem Problem geführt, da beim anschließenden Druck erneut gehomed wird.
[email protected] hat geschrieben:Ü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.
Der Vasenmodus sollte eigentlich nie zu einem Retract führen (zumindest bei Slic3r). Die ganze Idee war ja, den Retract damit zu eliminieren: indem die Düse kontinuierlich hochgefahren wird (für hal4822: das Bett kontinuierlich hinunter gefahren wird). Der Vasenmodus klappt auch nur bei einem Perimeter der kontinuierlich abgefahren wird - ohne absetzen, ohne Layer-Wechsel ("Layer Change"). Daher bleibt die Düse nie stehen, kann folglich nicht sabbern und benötigt keinen Retract.
mjh11
Re: Extruder bohrt sich in Druckobjekte
Verfasst: So 4. Jun 2017, 05:23
von hal4822
rf1k_mjh11 hat geschrieben:... indem die Düse kontinuierlich hochgefahren wird (für hal4822: das Bett kontinuierlich hinunter gefahren wird).
p.s.: Die Scheibe, die da kurzfristig taumelt meint nicht den Tisch, sondern die jeweils aktuelle Printebene. Natürlich soll die sich auch nur in einer Richtung bewegen. In der Simulation (MSPhysics/SketchUp) kann man halt mit dem Schieberegler spielen, bis alles auseinander fliegt.
Re: Extruder bohrt sich in Druckobjekte
Verfasst: So 4. Jun 2017, 12:07
von Nibbels
Marcometaner hat geschrieben: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
Ich hab da sone vage Theorie.
(Kann auch voll ein Schuss in Ofen sein/reine Idee)
Gestern habe ich während einer Startmade einmal Retract gedrückt. Anschließend hat der Drucker auf Achse E seine Richtung umgekehrt gehabt. Ich hatte auf der zweiten Hälfte keine Startmade mehr und diese hat dann bei der zweiten nebenliegenden Startmade erst wieder bei der Hälfte angefangen. (Leergezogen, dann Richtungskorrektur, dann Leerlauf bis ersteres aufgehoben war.)
Heute nochmal getestet: https://youtu.be/3eYUQtTeITU
Kann das jemand von euch mit Original-Firmware nachstellen?
Aber wie könnte Z vom selben Syptom betroffen sein?
Spekulation:
Wir haben 3 Fahr-Ziele im Drucker. queuePosition...., compensatedPosition...., directPosition....
Dazu die Printer::stepperDirection[x/y/z]
Wenn nun während einer Z-Bewegung die Z-Kompensation oder was anderes aus irgendeinem Grund die Richtung umkehrt, könnte der Drucker mal kurz in die falsche Richtung steuern.
Mich stört die Tatsache, dass der Fehler "zufällig" auftritt... (also bei identischem gcode an unterschiedlichen Stellen).
Mir fällt dazu spontan folgendes ein - bin leider kein SKETCH-Programmierer, daher als Frage formuliert:
o gibt es Messungen der für die Ausführung von gcode benötigten Zeit (als Quelle für den Zufall), die in Richtungs- oder Geschwindigkeitskalkulationen einfließen und dort ggf. einen Vorzeichenwechsel verursachen können (Rollover eines Counters)?
o kann es bei SKETCH passieren, dass "inkompatible" Variablen (eine "länger" als die andere, signed/unsigned,...) ineinander überführt werden? Oder anders: Arbeitet Sketch hier eher wie "C" oder wie "Java"?
o gibt es im FW-Code parallele Abläufe? Z.b. über Interrupts?
Und um dem Problem auf die Schliche zu kommen: Was kann man in der FW alles (voübergehend) abschalten (und wie), um den Fehler einzugrenzen?
Im Quellcode gibt es diverse Blöcke, die die Z-Achse besonders behandeln - für mich (keine SKETCH-Kenntnisse, keine FW-Kenntnisse) ist das aber gerade die Suche nach ner Nadel im Heuhaufen.
@nibbels: Einfach "E-" drücken während er die Startmade macht? Garade getan - (leider) keine E-Umkehr...
Re: Extruder bohrt sich in Druckobjekte
Verfasst: So 4. Jun 2017, 12:57
von Nibbels
[email protected] hat geschrieben:Mich stört die Tatsache, dass der Fehler "zufällig" auftritt... (also bei identischem gcode an unterschiedlichen Stellen).
Mir fällt dazu spontan folgendes ein - bin leider kein SKETCH-Programmierer, daher als Frage formuliert:
o gibt es Messungen der für die Ausführung von gcode benötigten Zeit (als Quelle für den Zufall), die in Richtungs- oder Geschwindigkeitskalkulationen einfließen und dort ggf. einen Vorzeichenwechsel verursachen können (Rollover eines Counters)?
o kann es bei SKETCH passieren, dass "inkompatible" Variablen (eine "länger" als die andere, signed/unsigned,...) ineinander überführt werden? Oder anders: Arbeitet Sketch hier eher wie "C" oder wie "Java"?
o gibt es im FW-Code parallele Abläufe? Z.b. über Interrupts?
Und um dem Problem auf die Schliche zu kommen: Was kann man in der FW alles (voübergehend) abschalten (und wie), um den Fehler einzugrenzen?
Im Quellcode gibt es diverse Blöcke, die die Z-Achse besonders behandeln - für mich (keine SKETCH-Kenntnisse, keine FW-Kenntnisse) ist das aber gerade die Suche nach ner Nadel im Heuhaufen.
Die Repetier-Firmware ist C++.
Zu deinen anderen Fragen: Ich blicke noch nciht völlig durch Besonders Bewegungen habe ich meist ignoriert.
[email protected] hat geschrieben:@nibbels: Einfach "E-" drücken während er die Startmade macht? Garade getan - (leider) keine E-Umkehr...
Ok, dann ist das komisch. Evtl. habe ich das dann durch einen Fix von etwas anderem so verdreht, oder ich habe eine leicht andere Einstellung.
gregre150_3.gcode.txt
(das ist der Code mit meiner Startmade.)
Mein Ursprungsverdacht war, dass wenn zufällig die Z-Kompensation nach unten korrigiert, während Z nach oben gefahren wird (oder umgekehrt) dieser Zufall stattfinden könnte.
Der Umstand, dass laut dir bei einer Umkehr einer Bewegung bei größeren Retracts auch größere Fehler stattfinden hat mich weiter motiviert daran zu glauben.
Ich habe in diesem Fall allerdings nicht in den Code geschaut. Nichts geprüft, nichts widerlegt...
Nibbels hat geschrieben:
Die Repetier-Firmware ist C++.
Zu deinen anderen Fragen: Ich blicke noch nciht völlig durch Besonders Bewegungen habe ich meist ignoriert.
[email protected] hat geschrieben:@nibbels: Einfach "E-" drücken während er die Startmade macht? Garade getan - (leider) keine E-Umkehr...
Ok, dann ist das komisch. Evtl. habe ich das dann durch einen Fix von etwas anderem so verdreht, oder ich habe eine leicht andere Einstellung.
gregre150_3.gcode.txt(das ist der Code mit meiner Startmade.)
Mein Ursprungsverdacht war, dass wenn zufällig die Z-Kompensation nach unten korrigiert, während Z nach oben gefahren wird (oder umgekehrt) dieser Zufall stattfinden könnte.
Der Umstand, dass laut dir bei einer Umkehr einer Bewegung bei größeren Retracts auch größere Fehler stattfinden hat mich weiter motiviert daran zu glauben.
Werde deinen Code gleich testen (und E- drücken)... aber vermutlich klappt der bei mir gar nicht, oder? (weil MOD)
3 weitere Versuche mit gregre150 und "E-" bei der Startmade: keine E-Umkehr
Re: Extruder bohrt sich in Druckobjekte
Verfasst: Di 6. Jun 2017, 07:55
von Marcometaner
Ich habe jetzt mehrmals gleichzeitig 15 kleine Zylinder gedruckt. jeder ist 10mm im Durchmesser und doppelt so hoch.
Bedeutet jede menge Retracts. Bislang traten keine Fehler auf... Alles sehr merkwürdig.
Auch die flower02, welche ich selbst gesliced habe mit Lift-Z 1mm hatte keine Fehler,
muss aber nichts bedeuten da die Fehler nicht immer auftreten.
Ich habe das mal an den Firmwareentwickler weitergeleitet, mal sehen was dabei raus kommt.
Eventuell macht der Prozessor Fehler, fragt sich dann nur wieso...
Wenn ich eine Rückmeldung habe, gebe ich sie weiter.
Besonders Bewegungen habe ich meist ignoriert.