Fragen habe ich im Moment keine, jetzt muss ich erstmal testen und abwarten, ob der Fehler nochmal auftaucht.

Mit Cura habe ich die Beschleunigung auf 1000 eingestellt wenn es schnell gehen soll und auf 500 reduziert wenn ich kein Ringing haben will, für Leerfahrten ist sie bei 900.
Mit Orca habe ich selbst bei 400 noch Layer Shift in Y Richtung, bei 100 nicht mehr. Hier muss ich noch testen und mir auch mal ein einfaches Objekt zeichnen, in dem ich im GCODE die Unterschiede finden kann damit ich die Beschleunigung wieder erhöhen kann.

PatrickB hat geschrieben: Mit Orca habe ich selbst bei 400 noch Layer Shift in Y Richtung, bei 100 nicht mehr.

In X und Y darf ein Layershift nicht einmal mit ACC 3000 vorkommen!
Wenn deine Riemen Ritzel alle fest sind, dann solltest du den Motorstrom erhöhen.

Ist dein Druckbett mit Druckplatten, etwa um 1 Kg schwerer geworden?

Der Nachteil einer Motorstrom Erhöhung ist, Motoren werden wärmer und lauter.
Darum schaue dir meine Empfehlung an.
Die Parameter lassen sich alle über das Druckermenü ändern.

Deinen Start Code habe ich mir heute auch etwas genauer angeschaut.
Ändere bitte:

PatrickB hat geschrieben: G1 X220 Y0 Z0.35 F5000

Auf G1 X220 Y0 Z0.2 F5000

Deine Startmade sowie der erste Layer, dürfen in unserer Community FW nicht höher als 0,2 mm sein.
Ansonsten spinnt unser Community FW!
Auch wird deine Made besser haften.

PatrickB hat geschrieben: G1 F800 E13

Ich vermute hier, dass zu wenig Material für die Startmade gefördert wird.
Mit einem 3,0 mm Schmelzdraht könnte die Menge vielleicht noch ausreichen.
Für einen Schmelzdraht mit 1,85 mm ist es viel zu wenig.
Hierbei ist ausprobieren angesagt.

G1 F800 E13

Hier geht es in unser Wiki für die Community FW:
wiki/index.php/Kategorie:CommunityMod_Firmware

Schaue ins besondere nach:
SenseOffset und DigitFlowCompensation.

SenseOffset ist Pflicht für alle Conrad (Pimmel) Hotends.
Da diese Hotends aus Kunststoff sind, wird mit diesem Tool die Wärmeausdehnung (Nachlängung) kompensiert.

DigitFlowCompensation, ist ein feines Tool um zu hohe Extrusionsdrücke zu minimieren.
Ich benutze beide Tools auch mit meinem E3D V6 Hot End.

LG AtlonXP

AtlonXP hat geschrieben: ↑Mo 4. Nov 2024, 11:32 In X und Y darf ein Layershift nicht einmal mit ACC 3000 vorkommen!

Deswegen muss ich noch den Fehler suchen.
Mit Cura habe ich keine Probleme, daher muss der Fehler beim Orca Slicer liegen.

AtlonXP hat geschrieben: ↑Mo 4. Nov 2024, 11:32 Deine Startmade sowie der erste Layer, dürfen in unserer Community FW nicht höher als 0,2 mm sein.
Ansonsten spinnt unser Community FW!
Auch wird deine Made besser haften.

Das war bisher kein Problem, werde ich aber testen.
In Cura ist der erste Layer noch bei 0,3, in Orca bei 0,2, beides funktioniert gut.

AtlonXP hat geschrieben: ↑Mo 4. Nov 2024, 11:32 Ich vermute hier, dass zu wenig Material für die Startmade gefördert wird.
Mit einem 3,0 mm Schmelzdraht könnte die Menge vielleicht noch ausreichen.
Für einen Schmelzdraht mit 1,85 mm ist es viel zu wenig.
Hierbei ist ausprobieren angesagt.

Für 3mm ist die Menge genau richtig, für 1,75 deutlich zu wenig.

AtlonXP hat geschrieben: ↑Mo 4. Nov 2024, 11:32 Schaue ins besondere nach:
SenseOffset und DigitFlowCompensation.

SenseOffset ist Pflicht für alle Conrad (Pimmel) Hotends.
Da diese Hotends aus Kunststoff sind, wird mit diesem Tool die Wärmeausdehnung (Nachlängung) kompensiert.

DigitFlowCompensation, ist ein feines Tool um zu hohe Extrusionsdrücke zu minimieren.
Ich benutze beide Tools auch mit meinem E3D V6 Hot End.

Das habe ich bisher beides völlig übersehen, da muss ich mich einlesen.

EXECUTABLE_BLOCK_START konnte ich entfernen, woher die Werte kommen habe ich auch gefunden, der Reiter ist bei den Einstellungen für den Drucker. Ob diese Einstellungen sich trotzdem auf den GCODE auswirken muss ich noch testen.

Ein Testdruck ohne den zusätzlichen Startcode und ohne Z-hop steht noch aus.

Ein Wechsel des Layers passiert über den Orca Slicer mit F9000 ca. 15 x so schnell wie mit Cura, auf die Schnelle konnte ich keine Möglichkeit finden, das einzustellen, es gibt im Orca Slicer leider auch kein Post Processing. Da muss ich nochmal in Ruhe ran. Der restliche GCODE zeigt bei einem einwandigen Würfel sonst keine großen Unterschiede zwischen Cura und Orca. Wenn der nächste Probedruck wieder fehlerhaft ist muss ich mir wohl doch noch den Temp Tower anschauen, bei dem erzeugt Orca bisher zuverlässig zufällige Layer Shift auf Y sobald die Beschleunigung bei 400 ist (100 ist OK, dazwischen habe ich nicht getestet).

Acceleration über M204 einstellen wird von der Firmware ignoriert, sie kennt den Parameter P nicht. Das kann den Layer Shift also auch nicht auslösen.

Liest hier noch jemand mit, der sich mit dem Quellcode auskennt?
Ich würde gerne die Befehle an Marlin anpassen, die aktuellen Slicer scheinen kein Repetier mehr zu sprechen. Auf den ersten Blick ist das eine simple Änderung der commands.cpp, laufe ich da in eine Falle?

Wenn ich DigitFlowCompensation richtig verstehe klingt es sehr sinnvoll, dürfte aber bei richtig eingestelltem Slicer arbeitslos sein und sollte für die Ermittlung des richtigen Flow aus sein. Oder liege ich falsch?

SenseOffset muss ich in Ruhe konfigurieren, würde ich aber auch für die Flow Kalibrierung ausschalten und lieber 20 Minuten vorheizen wenn es genau werden soll.

M3900 habe ich bisher übersehen.
Spricht etwas dagegen, M3900 in den Startcode aufzunehmen und darüber vor Druckbeginn einen Z-Offset-Scan durchzuführen?

PatrickB hat geschrieben: es gibt im Orca Slicer leider auch kein Post Processing

Eventuell kannst du über das Druckermenü nachschauen wie er gerade läuft.
Ich weiß jedoch nicht, ob du im Betrieb Zugriff auf alle Parameter hast.

Nur so als Idee.
Schaue dir die Befehle von M500 bis 503 an.
Vielleicht kannst du da was überlisten….

Ob du die G- Code Befehle an Marlin anpassen kannst weiß ich nicht.
Unser Programmierer haben hier alle den Hut gezogen…
Wenn du da was hinbekommst. Wäre es nett, es hier zu veröffentlichen.

PatrickB hat geschrieben: Wenn ich DigitFlowCompensation richtig verstehe klingt es sehr sinnvoll, dürfte aber bei richtig eingestelltem Slicer arbeitslos sein und sollte für die Ermittlung des richtigen Flow aus sein. Oder liege ich falsch?

DigitFlowCompensation läuft nur im Hintergrund mit, wenn dein Drucker innerhalb der dort bestimmten Parameter läuft, greift es nicht ein.
Es ist Sinnvoll, wenn dein Teil Warpt und sich dadurch die Layerhöhen verkleinern.
Durch Reduzierung des Material Flow wird es ausgeglichen.
Auch wenn du mit Gummiartigem Material druckst, macht dieses Tool Sinn.
Wenn sich das Material wegen zu hohem Gegendruck auf staucht wird dann automatisch die Geschwindigkeit reduziert.
Logisch, Fehleinstellungen im Slicer kompensiert es mit.
Bei mir läuft es immer im Hintergrund mit.

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.

Du kannst Z-Offset-Scan ebenso in deinem Start Code dauerhaft eintragen.
Dann macht der Drucker bei jedem Druckbeginn eine Z- Messung.
Das gibt dann jedes Mal einen Knubbel auf deinem Druckbett.
Auch wird das Z- Messergebnis nur im RAM abgelegt und geht bei jedem Rest vom Drucker verloren.
Ich mache die Z- Messung nur nach Bedarf und speichere das Ergebnis im ROM.

LG AtlonXP

Hallo PatrickB,

PatrickB hat geschrieben:... es gibt im Orca Slicer leider auch kein Post Processing.

Siehe hier:

PatrickB hat geschrieben:Auf den ersten Blick ist das eine simple Änderung der commands.cpp, laufe ich da in eine Falle?

Du müsstest verdammt gut in der Programmierung sein, um die jetzige Firmware auf 'Marlin' um zu schreiben. Es sind sicher auch andere Bereiche, bzw. Dateien betroffen, nicht nur die commands.cpp.
Die Firmware (nicht nur Repetier, auch Marlin) ist sehr konfus und verstrickt aufgebaut (laut ehemaligem User mhier, der deswegen nichts mehr damit zu tun haben wollte und auf Klipper umgestiegen ist).
Aber, falls es dir tatsächlich gelingen sollte, wären sicherlich einige im Forum daran interessiert.

Eine der Probleme könnte (muss nicht) sein, dass Marlin einige Befehle kennt, die Repetier nicht kennt, beziehungsweise diese anders implementiert oder interpretiert (wichtig auch u.U. die Position/Reihenfolge der Parameter!). Wenn diese Befehle nicht wichtig sind, werden sie, da sie nicht erkannt werden, ignoriert. Haben diese GCodes ('G' oder 'M') eine wichtige Funktion, müsstest du diese von Grund auf auch in die Firmware einarbeiten. Da könnte es sein, dass es mit dem Speicher nicht mehr ausgeht. Die Community FW kam schon recht knapp an die (leider) begrenzten Speicherfähigkeiten unserer Systemplatine.

Übrigens scheint Orca eine der ganz wenigen Slicer zu sein, die Repetier nicht unterstützen, obwohl es auf BambooLab aufbaut, das wiederum auf PrusaSlicer aufbaut, was auf Slic3r aufbaut, welche alle Repetier unterstützen.

mjh11

Das habe ich gesucht, danke. Mit der Google-Suche war ich da weniger erfolgreich und in den Filamenteinstellungen habe ich nicht gesucht.

So gut bin ich nicht im Programmieren und auch die Zeit dafür habe ich leider nicht, aber meine Hoffnung ist, dass es ausreicht, die Befehle umzubenennen. Ich will ja kein komplettes Marlin schreiben, aber wenn z.B. die Firmware auf den Marlin-Befehl M204 die Beschleunigung anpasst anstatt ihn zu ignorieren weil sie PID-Werte erwartet wäre das schon sehr hilfreich. Ich werde das demnächst mal angehen.

Die Firmware muss sowieso auf beide Drucker neu aufgespielt werden weil ich festgestellt habe dass die 5015 Lüfter, die ich gerade verbaut habe, den Port überlasten und wenn ich den wechsle werde ich das wohl der Firmware mitteilen müssen.

Klipper reizt mich auch, aber erstmal will ich die Kühlung in den Griff bekommen (das sieht schon deutlich besser aus als vorher) und bei einem Drucker muss ich mich noch mit dem Z-Wobble auseinandersetzen.

Gerade läuft ein Testdruck ohne Z-Hop und ohne den "falschen" Startcode, wenn der durch ist weiß ich hoffentlich schon etwas mehr.

Es ist nicht der Z-Hop, es ist nicht der Startcode und es ist auch nicht der Layerwechsel mit F9000, jetzt wird die Suche nach Unterschieden im GCODE sehr aufwendig ...

@rfjik_mjh11 Nutzt Du den Orca Slicer auch für den RF1000?

Das Post-Processing ist entweder schlecht dokumentiert oder kaum jemand schreibt darüber, aber wenn ich das bisschen, das ich finde, richtig interpretiere, muss ich ein externes Python-Script einbinden und ob es dann auch ausgeführt wird wenn man die Datei an den Drucker schickt scheint fraglich zu sein.

Könnte es auch an der Datenübertragung liegen?
Die Bautrate sollte 115200 betragen.

Mir ist nicht klar, warum du den M203 Befehl benötigst?

Eigentlich sollte es funzen, wenn du am Ende des Start Cods folgendes einfügst:

M201 X900 Y900 Z80 E5000
M202 X900 Y900 Z80 E5000

Es sollten somit die vom Slicer (eventuellen Schrott- Werte) wieder überschrieben werden.

ich wünsche dir viel Erfolk.

LG AtlonXP

Der Fehler ist von der SD-Karte der selbe wie über Octopi, die Datenübertragung schließe ich aus.

M203 brauche ich nicht, das ist die maximale Feedrate, die der Slicer in den Startcode geschrieben hatte.

M201 und M202 ist in meinem Startcode, das setzt die Werte für die Beschleunigung auch sauber.
Ich habe die E-Werte jetzt ergänzt, auf zum nächsten Testdruck.