Vergleich von gcode

[Rentier]

Moin zusammen,
als neuer Nutzer unterschiedlicher Slicer (Repetier-Host und Simplify3D) stelle ich zwischen beiden Unterschiede im Druckoutput fest, ohne gezielt Parameteränderungen vorgenommen zu haben. Damit stellt sich mir die Frage nach der Ursache. Konkret bedeutet dieses, ich möchte die beiden gcode-Dateien vergleichen. Leider habe ich noch keine Möglichkeit gesehen, die gcode-Dateien irgendwie in irgendeinen Editor zu bringen. Welche Möglichkeit könnt Ihr mir nennen?
Gruß Bernd

[GreyEnt]

Hi Bernd.
Du möchtest ein Editor mit zwo Ansichtsfenster haben?
Müste der Editor spezielle Funktionen haben?
Abgesehen von den zwo Fenster nebeneinander?

Kenne jetzt keine Software. Könnte das aber recht schnell aufziehen.

Gruß
GreyEnt

[rf1k_mjh11]

Hallo Bernd/Rentier,

Erstmals: Repetier-Host ist kein Slicer. Man kann es sich in etwa wie eine grafische Benutzeroberfläche vorstellen, welches ihrerseits einen Slicer einbindet (in deinem Fall vermutlich Slic3r).

Davon abgesehen, wird sich dein Problem nicht einfach lösen lassen. Ein direkter Vergleich des GCodes wird fehlschlagen.

Nehmen wir ein einfaches Werkstück: ein Quader mit 20mm x 20mm Seitenlänge und 3mm Dicke. Angenommen, das Werkstück ist in beiden Programmen exakt gleich positioniert - beginnen beide Slice-Programme in derselben Ecke mit dem Perimeter? Und arbeiten die Slicer diese in der selben Richtung (in Uhrzeigerrichtung oder entgegen) ab? Dann kommt noch der Infill hinzu - wird dieser in der selben Art abgearbeitet?
Der GCode-Standard ist auch recht einfach gehalten. Es gibt keine Vorschrift ob eine Koordinate zwingend ausgegeben werden muss oder nicht.
Beispielsweise machen:

G1 X10 Y10 Z0.5 E1.15

G1 X20 Y20 Z0.5 E1.15

und

G1 X10 Y10 Z0.5 E1.15

G1 X20 Y20

absolut dasselbe! Es werden im ersten Block, in der zweiten Zeile einfach redundante Koordinaten für Z und E angegeben. Dieses Prinzip gilt für alle Achsen. Das heißt, ändert sich der Wert nicht, kann ich mir die Angabe der Achse in der Befehlszeile sparen, darf es aber sehr wohl trotzdem hinschreiben. Das ist nicht falsch und ist erlaubt. Ob S3D so was macht, weiß ich nicht. Slic3r tut es meines Wissens nicht. Dafür setzt Slic3r recht häufig den E-Wert wieder auf '0' zurück (mittels G92 E0). Ist auch nicht falsch, wenn S3D das aber nicht tut, wird es mit dem Vergleich schwierig. Auch wenn S3d den E-Wert regelmäßig zurücksetzt, macht er es immer zur gleichen Zeit wie ein anderer Slicer?


Da wird es offensichtlich, das der Code als gesamtes kaum zu vergleichen sein wird. Eher Erfolg wird man beim Vergleich einer einzelnen Raupe haben.
Beim vorhin genannten Quader könnte man eine der vier geraden Außen-Perimeter recht leicht vergleichen (unter Zuhilfenahme eines Taschenrechners oder einer Tabellenkalkulation. Man kann aus dem GCode die Anfangs- und Endkoordinaten einer Raupe herauslesen und damit die Länge der Raupe ermitteln. Ebenso, in derselben Zeile, steht der Filamentverbrauch, versteckt im Wert der 'E'-Koordinate. Dazu muss man aber auch den E-Wert der vorhergehenden Zeile in die Rechnung miteinbeziehen.
Über diesen Weg kannst du schon einmal den 'Filamentverbrauch' der eingesetzten Slicer vergleichen. Wenn die eingesetzten Slicer dieselbe Länge bei der Raupe haben, und gleich viel Material fördern, wird der Qualitätsunterschied am Infill oder am Perimeter-Overlap liegen.

Beim Infill wird es ungleich komplizierter unterschiedliche Slicer zu vergleichen, da hier auch Füllmuster, die scheinbar gleich sind, keinesfalls zwischen Slicer gleich sein müssen.

Ein wenig in das Thema der GCode-Analyse sind wir hier eingetaucht. Der ganze Thread könnte dich interessieren.

Allseits Gesundheit!

mjh11

[Rentier]

Moin Ihr beiden,
zunächst vielen Dank für Dein Angebot GreyEnt. Ich möchte dieses z. Zt. nicht nutzen, da mich die Antwort von mjh11 davon abhält, diese Frage weiter zu verfolgen.
Auch Dir, mjh11, vielen Dank für Deine Ausführungen. Diese sind mir verständlich, da ich jahrzehntelang auch mit Fragen der Anwendungsentwicklung beschäftigt war. Was ich mit diesen Erkenntnissen machen werde, weiß ich aktuell noch nicht.
Gruß Bernd

[zero K]

... Was ich mit diesen Erkenntnissen machen werde, weiß ich aktuell noch nicht.
...

Hallo Bernd

So richtig schlechte Slicer gibt es wohl nicht mehr.
Schwierig ist nicht die Bedienung des Slicers, sondern vom Druckergebnis auf den oder die das Druckergebnis optimierenden Parameter im Slicer zu schließen.

Im ersten Schritt, schau Dir die Benutzeroberflächen bzw die Benutzerführung einiger Slicer an - welche liegt Dir am Besten, z. B. in den Kriterien Seitenaufteilung, Menüstruktur und auch möglichst intuitiver Bedienbarkeit.

Wenn dann ein Druckergebnis, in Teilen oder gar vollständig nicht zufriedenstellt, liegt es an der möglicherweise suboptimalen "fertigungsgerechten" Konstruktion und/oder an der Parametrisierung des Slicers.

Die Bedienung des Slicers folgt sehr eng dem Lernprozess.

Auch wenn ich mein Cura heute einigermaßen im Griff habe, muss ich das Eine oder andere Modell mit veränderten Einstellungen wiederholt drucken.
Dann arbeite ich aber mit angepassten Einstellungen in Cura und wechsele nicht zu einem anderen Slicer.

In Linux ist Slic3r die Alternative für mich.

Beide Programme gibt es als so genannte AppImages, die in irgend einem Verzeichnis abgelegt, bis auf die Einstellung der Ausführbarkeit keinen weiteren Installationsaufwand erfordern.

Vielleicht hilft´s,
schönes verregnetes Wochenende
zero K

[AtlonXP]

Hallo zusammen,

da unsere Community FW noch ein paar Macken hat und um einen Slicer Fehler auszuschließen,
hatte ich S3D und Slic3r Pursa Edition, gegeneinander antreten lassen.

Gedruckt wurde ein 3D Benchy mit denselben Einstellungen.
Das 3D Benchy hat ein Moiré Muster an der Seitenwand und am Dachvorsprung.

Punkt um, beide 3D Benchys sahen gleich aus.
Ich konnte keinen Unterschied mit dem bloßen Auge feststellen.
Das Moiré Muster war auch identisch.

Das Ganze ist schon etwa zwei Jahre her, ich vermute das Moiré Muster ist heute noch drin.

LG AtlonXP

[Rentier]

Moin zusammen,
ich habe mir mittlerweile einiges von dem gesagten zu Herzen genommen, aber im wesentlichen meinem alten Arbeitsstil nachgegangen: Wenn Du etwas intuitiv nicht verstehst, dann verlasse die Arbeitsoberfläche und steige in den generierten Code ein (ist zwar langwieriger, dafür aber erkenntnisreicher). Mein Fazit: es hat gedauert, aber ich habe vieles verstanden und einiges korrigiert. Es hat sich wieder einmal bewahrheitet, dass die Gedankengänge verschiedener Menschen genau so vielfältig sind wie die generierten Codes.
Gruß Bernd