Hallo Patrick,

hast du im Slicer (Orca) auch mal die Diversen Firmware gcodes angeschaut?

Ansonsten schaue dir doch den SuperSlicer mal an.



Klipper auf dem RFxxxx würde ich dir auch empfehlen, einfacher in Handling und Qualität des Drucks ist besser.

Dennis

Ja, ich habe alle außer Klipper ausprobiert, da ändert sich nichts.

Wie ist der aktuelle Stand bei Klipper? Lässt sich Klipper mittlerweile ohne Umweg installieren oder empfiehlt sich noch die Anleitung von mhier mit seinem Repository?

Superslicer soll auch sehr gut sein, aber den Orca will ich nutzen weil ich damit auch meinen Bambu ansteuern kann und er mir recht gut gefällt. Sollte ich ich ihn nicht zur Zusammenarbeit mit dem RF1000 überreden können bleibe ich vermutlich bei Cura.

Hallo PatrickB,

der oben angesprochene hat geschrieben:@rfjik_mjh11 Nutzt Du den Orca Slicer auch für den RF1000?

Nee, ich habe bloß schnell eine portable Version 'runtergeladen, gestartet und durchgesucht. Da bin ich auf die Skriptfähigkeit gestolpert.

Derzeit habe ich meist Superslicer im Einsatz, gelegentlich noch PrusaSlicer. Davor war Slic3r dran, vor etwa einem Jahrzehnt arbeitete ich mit Skeinforge (für die alten Hasen, die sich noch daran erinnern können).

PatrickB hat geschrieben:Das Post-Processing ist entweder schlecht dokumentiert oder kaum jemand schreibt darüber ....

Nachdem Orca an der entsprechenden Stelle einen Dateinamen erwartet (vermutlich samt Pfad), dürfte die Funktionalität des Postprocessings von Slic3r vererbt worden sein. Stimmt das, könnte dieser Link auf GitHub nützlich sein (Writing-post-processing-scripts). Die Skripts scheinen in Perl und Python geschrieben zu sein. Hier ein Link mit Beispielen. Mein Vorschlag: schreibe einfach ein Skript, dass alle Vorkommnisse von "G1" durch "Juhu" ersetzt, erzeuge einen beliebigen GCode und guck nach.
Wenn das klappt, kannst du dir das Umpfriemeln auf Marlin ersparen und machst alles mit einem oder mehreren Skripts.

PatrickB hat geschrieben:und ob es dann auch ausgeführt wird wenn man die Datei an den Drucker schickt scheint fraglich zu sein.

Damit wird mir wieder vor Augen geführt, dass ein jeder seinen (ihren) eigenen Prozess hat. Ich slice das Objekt (erzeuge also den GCode), starte Repetier-Host, lade den GCode und sende dann den GCode an den Drucker. Damit wäre das Postprocessing für meinen Prozess völlig unsichtbar und es nicht direkt beeinflussen. Die Datei wäre schon korrigiert, wenn ich sie in Repetier-Host lade.
Ich weiß, viele nutzen den eingebundenen Slicer in Repetier-Host und drucken quasi direkt aus dem Slicen heraus. Ich sehe mir einfach gerne den GCode an, bevor ich es an den Drucker schicke (sei es per Host oder SD-Karte). Ich slice auch nie über RH, sondern immer nur über den separat aufgerufenen Slicer, da hat man mehr Einstellmöglichkeiten.

mjh11

Ich hatte ein Install Script geschrieben für die Originalen Rfxxxx Klassen. Du kannst es dir einfach installieren und wirst sehen macht einfach Spaß. Auch bei der älteren Klipper Version wird dir Nix fehlen.

Dennis

Ich hatte bisher mit Cura und SD-Karte gearbeitet. Da hatte ich für ein paar Kleinigkeiten das Post-Processing genutzt, das ist zwar eingeschränkt, war aber für mich völlig ausreichend und absolut bequem.

Mit dem Bambu kam dann ein neuer Slicer dazu und ich muss zugeben dass es schon bequem ist, den Druck einfach übers Netzwerk zu starten. Deswegen habe ich jetzt meine uralten RasPi ausgegraben und einen mit Octopi versehen, auf dem anderen läuft schon Klipper, aber es ist noch nichts konfiguriert.

Ja, das Scripting ist von einem anderen Slicer übernommen und ich glaube auch gelesen zu haben, dass der Ursprung bei slic3r liegt. Ich glaube dass Orca nicht nur den Dateinamen inkl. Pfad erwartet sondern einen ganzen Befehl in dem auch z.B. Python aufgerufen wird.
Einfach mal etwas ersetzen oder im ersten Schritt einfach nur reinschreiben wäre auch mein erster Ansatz um das Script zu testen.

Die Befehle über ein Script austauschen wäre eine Möglichkeit, wenn ich aber wirklich nur in einer Datei der Firmware die paar unterschiedlichen Befehle austauschen könnte wäre das für alle Slicer nutzbar und vielleicht auch für andere interessant. Ich lese hier seit fast 10 Jahren mit und konnte mir auch viel Information rausziehen, vielleicht kann ich ja so auch mal etwas zurückgeben. Wenn ich mir damit die Firmware zerschieße bleibt ja noch immer das Post-Processing oder Klipper. Vielleicht macht ja die Kombination Klipper und Orca weniger Probleme.

Ein paar Unterschiede habe ich heute im GCODE gefunden, ob das wirklich für den Layershift verantwortlich ist muss ich testen, logisch wäre es nicht. Wenn ich die neuen Lüfter am richtigen Port anschließe prüfe ich aber sicherheitshalber auch die Mechanik. An ein großes Objekt traue ich mich mit dem überlasteten Port nicht mehr ran und bei kleinen Objekten taucht der Z Versatz bisher nicht wieder auf.

DennisNochmal hat geschrieben: ↑Mi 6. Nov 2024, 18:25 Ich hatte ein Install Script geschrieben für die Originalen Rfxxxx Klassen. Du kannst es dir einfach installieren und wirst sehen macht einfach Spaß. Auch bei der älteren Klipper Version wird dir Nix fehlen.

Gut dass Du das erwähnst, ich hatte bisher nur beim RF1000 gesucht, auf die Idee, im RF2000-Forum zu suchen, bin ich nicht gekommen. Das werde ich auf jeden Fall testen.

Das ist jetzt so richtig peinlich und zeigt mal wieder, dass man besser prüft als Schlüsse zu ziehen ...
Der Y-Layershift kam tatsächlich von einem losen Ritzel, dass die Testdrucke mit Cura nochmal fehlerfrei waren muss Zufall gewesen sein.

Aber wenigstens kann ich mich jetzt wieder mit sinnvollen Dingen beschäftigen, z.B. die Lüfter richtig anschließen, die Z-Achse mechanisch prüfen und die Firmware neu aufspielen.

Das muss dir nicht peinlich sein.
Viel wichtiger ist die Ehrlichkeit zu sich selbst.

Genau diese vermisse ich bei unseren Politikern.

LG AtlonXP

Hallo AtlonXP,

AtlonXP hat geschrieben:Viel wichtiger ist die Ehrlichkeit zu sich selbst.

Genau diese vermisse ich bei unseren Politikern.

Tja, das fehlt nicht nur bei 'unseren' Politikern, ALLEN Politikern fehlt es offensichtlich!

mjh11                                         (Sorry, hat natürlich nichts mit dem Thema zu tun.)

Mir ist gerade noch etwas anderes aufgefallen. Dass ich die Firmware aufgespielt habe ist lange her, daher weiß ich nicht mehr, was ich damals konfiguriert hatte. Kann ich irgendwie herausfinden, ob SenseOffset aktiviert ist?

AtlonXP hat geschrieben: ↑Di 5. Nov 2024, 13:53 SenseOffset kannst du genauso im Hintergrund mit laufen lassen.
Solange du nicht außerhalb deiner eingestellten Parameter druckst verhält sich dieses Tool ebenso neutral.
Sollte jedoch einmal deine Düse verstopft sein während dem ersten Layer, dann fährt die Z- Achse Stück für Stück von deinem Druckbett weg.

Passiert das nur auf dem ersten Layer? Wenn nicht könnte auch das eine Ursache für meinen Versatz sein.

Hallo PatrickB,

PatrickB hat geschrieben:Kann ich irgendwie herausfinden, ob SenseOffset aktiviert ist?

Aus GitHub:

auf GitHub hat geschrieben:Use "M3909 P0" for manual shutdown of the feature, but normally this is not necessary.

Damit kann man es scheinbar wieder deaktivieren.
Wenn du es spezifisch deaktivierst, kannst du testen, ob das Problem daran liegt. (Danach nicht vergessen, es wieder zu aktivieren.)

(Hinweis: ich verwende die Community Version nicht, falls ich hier falsch liege, wird sich hoffentlich einer melden.)

mjh11