Laut Logdatei ist nur eine Matrix vorhanden, die mit einer Firmware älter als die RF.01.21 erstellt worden ist. D.h. du musst den Scan mit der RF.01.25 durchführen, damit die Matrix auch von der RF.01.25 verwendet werden kann.

Nur um hoffentlich Verwirrung zu vermeiden:

- Z-Lift (oder "Retraction Vertical Lift" in S3D) hat nichts mit Z-Kompensation zu tun, außer das es beides den Z-Motor anspricht.

- Wenn es wegen Z-Lift zu solchen Fehlern kommt, ist das eine wertvolle Erkenntnis, aber natürlich keine Lösung. Auch das muss ja funktionieren. Beim Z-Lift ist es wohl nur so, dass es kaum jemand benutzt. Daher kann es durchaus sein, dass da schon länger ein Problem schlummert.

Hallo Blech,


kann ich bitte auch die Slicer-Einstellungen bekommen, mit denen du diesen G-Code (= "Z-Achsen-Fehler.gcode") erzeugt hast?

Wenn wir deinen G-Code auf einem RF1000 mit Standard-Extruder und 0,5er-Düse und 3mm Filament drucken dann kommt da viel zu viel Material heraus. Wir haben deine "Z-Achsen-Fehler.amf" daher selbst gesliced und dieser Druck läuft noch die nächsten 6 Stunden, im Moment bei einer Höhe von ca. 17 mm.

Welchen Extruder mit welchem Düsendurchmesser verwendest du?


Danke im Voraus,
RF1000

Hallo RF1000

ich verwende den V2 Extruder mit 1,75mm Düse 0,3mm.
Material PLA, Schichtdicke 0,2mm.
Mein Extrudermotor ist übersetzt 950 Steps/mm ist in EEprom eingetragen.

Slicer Einstellungen kommen gleich.

Grüße
Blech

Hallo Blech,


wir konnten dein Problem bei unserem Druck nicht feststellen. Wir könnten dir die von uns verwendeten Slicer-Einstellungen und den daraus erzeugten G-Code geben, aber zumindest der G-Code würde ja auf deiner Hardware nicht sinnvoll laufen können.

Ich denke, du musst noch einmal versuchen, den Fehler "hinzubekommen". Sobald er aufgetreten ist (und bevor die Z-Stepper ausgeschalten werden) musst du vergleichen, ob der reale Abstand Heizbett <-> Düse dem entspricht, was auf dem Display als Z-Position angezeigt wird. Laut deinem Bild von http://www.rf1000.de/download/file.php? ... &mode=view beträgt der Versatz ja mehrere mm, was messbar sein sollte.

Wenn es zwischen der Anzeige und der Messung einen messbaren Unterschied gibt dann ist die Z-Achse nicht dorthin gefahren, wo die Firmware es wollte. Eine möglich Ursache dafür könnte ein Fehler in den Kabeln zum Z-Motor sein, d.h. falls es einen Unterschied gibt solltest du diese Kabel und Steckverbindungen überprüfen.
Falls die Z-Achse wieder offensichtlich um mehrere mm daneben ist, Anzeige und Messung aber übereinstimmen müssen wir hier noch einmal weiter schauen. Da du dieses Verhalten bei gleichem G-Code aber an unterschiedlichen Stellen hast und wir es bei unseren Geräten mit der selben Firmware nicht reproduzieren konnten könnte es aber irgendwie an deiner Hardware liegen.


mfG
RF1000

Hallo RF1000,

habe noch einen Extruder V2 für 3mm Material. Dann sollte es mit dem von dir erzeugten G-Code funktionieren. Auch die Extrudermotorübersetzung kann ich rausnehmen. Also Bitte zusenden.

Grüße
Blech

Here you are.


mfG
RF1000

Hallo RF1000

ohne Z-Lift mit meinem Setup komplett durchgelaufen.
Am Wochenende teste ich noch mal mit aktivierten Z-Lift.

Grüße
Blech

Ich muss diesen Thread leider aufwärmen.
Auch ich arbeite mit Z-Lift bei Bewegungen und Perimeterkreuzung. Leider habe ich bei diversen Testdrucken feststellen müssen, dass mein RF1000 sporadisch während des Druckes in die falsche Z-Richtung fährt - mal um 2-3 Layer ins Objekt, was im Besten Fall nur durch eine Störstelle im Objekt auffällt, im schlimmsten zum Mitnehmen des Objektes durch den Extruder führt, und manchmal um ein paar Layer nach unten, so dass folgend in die Luft gedruckt wird.

Ich konnte das Problem reproduzieren mit
FW01.10
FW01.37
Druck von SD-Karte
Druck via Repetierserver

Im Repetierserver-Logfile sind alle z-Bewegungen korrekt aufgeführt und ohne Fehler bestätigt worden. In Folge des Fehlers stimmen die von der Firmware gemeldeten Z-Koordinaten nicht mehr mit der tatsächlichen Extruderhöhe überein.

Außerdem (dieses Problem habe ich aber weniger genau untersucht) kann ich einen zweiten Fehler reproduzieren:
Bei Anbindung über Repetierhost->Raspi-Repetierserver->RF1000(FW01.37) kann ich - nachdem ein Druck abgeschlossen wurde - durch schnelles betätigen beliebiger Achsen-Steuerung am Repetierhost (z.B. ganz schnell und oft X-Achse um 1mm nach links) einen Fehler auslösen, der dazu führt, dass der Kopf anstatt UM -1mm AUF -1mm absolut) läuft. Das tritt nur auf, wenn zuvor G90 gesetzt war - dann kann man im Log beim betätigen der Steuerung eine Befehlssequenz "G90 G91 G1 Z-1" sehen - die offensichtlich sporadisch fehlinterpretiert wird. Setze ich manuell ein G91 ab, so verändert sich das Verhalten: Die Sequenz im Log ist jetzt nur noch "G1 Z-1" und der Fehler tritt nicht mehr auf...

Gibt es hier einen bekannten BUG???

cu. Tim

[email protected] hat geschrieben: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 ...

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...

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