Ich habe RF100.
Ich drucke meine Objekte mit Simplify3D.
Nachdem Drucken ist der Extruder automatisch immer nach Home gefahren.
Aber letzte Zeit geht er nicht mehr nach Home.
Muss ich irgendwas einstellen bei Simplify3D?

Yalcin,

Deine Fehlerbeschreibung ist etwas vage. Ich muss mutmaßen.

Yalcin hat geschrieben:Nachdem Drucken ist der Extruder automatisch immer nach Home gefahren.

Wenn der Drucker unmittelbar nach dem Drucken nach Home fährt, wäre das eine Katastrophe. Das Druckobjekt liegt da vermutlich noch auf dem Bett. Es käme daher zu einer Kollision zwischen gedrucktem Objekt und Düse und/oder anderer Teile des Druckers.

Ich denke, du meinst eher, dass ganz am Ende des Drucks die Düse nicht mehr zur Seite fährt?
Falls das dein Problem ist, musst du den End-GCode anpassen. Damit kann man bestimmen, was der Drucker am Ende des Druckauftrags machen soll.
In deinem Fall (den ich oben annahm), würde ein
G1 X0 Y0 F2000
reichen, dass die Düse vom Objekt wegfährt.

Wo man den End-GCode in Simplify findet, weiß ich nicht - ich verwende das Programm nicht.

mjh11

Ja ich meine, dass ganz ende des Drucks die Düse fährt nicht zur Seite. Die bleibt am Ende des Drucks , wo die ist.

Yalcin hat geschrieben:Ich habe RF100.
Nachdem Drucken ist der Extruder automatisch immer nach Home gefahren.
?

M3079 output objekt ist bei Slic3r der Befehl wenn das Druckobjekt fertig ist.
Davor und dahinter steht allerdings M400 : Warte bis alle gepufferten Befehle abgearbeitet wurden.
Könnte es sein, dass der Drucker da auf etwas wartet, was nicht kommt ?

Wenn ich mit Cura für den RF1000 slice passiert bei mir allerdings dasselbe: der Tisch fährt nicht abwärts.

Der RF100 hat von Haus aus auch Cura - dort hatte ich das Problem aber nicht.

Man muss offenbar den GCode immer durchsuchen bzw. überprüfen, dass gilt vermutlich für jeden Slicer.

Im 3D-Warehouse von Sketchup (https://3dwarehouse.sketchup.com/model/ ... kinematics) gibt es ein Druckermodell, an dem man gcodes probieren kann, ohne dass gleich was zu Bruch geht: https://www.dropbox.com/s/0pf4azjaxbnpj ... 2.wmv?dl=0

Vom Original ist glaub ich auch ein Video vom Autor selbst auf YouTube zu sehen mit einem anderen Druckobjekt.
In meiner Animation habe ich den GCode von dem Herz verwendet, dass jeder RFxxx-Besitzer wohl unter seinen mitgelieferten GCodes findet.
Man sieht da hinten eine Linie in der Luft hängen, die eigentlich wie beim RF1000 an der Vorderkante des Heizbettes als erstes Zeichen, dass Filament gefördert wird, zu sehen sein sollte. Leider habe ich die entsprechenden Befehlszeilen bisher nicht gefunden.

Yalcin,

ACHTUNG: der M3079-Befehl klappt beim RF100 vermutlich nicht. Der ist anders aufgebaut als der RFx000 und verwendet eine andere Firmware. Die meisten GCodes (wenn nicht alle) ab M3000 werden nicht funktionieren, nehme ich an.

Mein GCode Vorschlag aus der ersten Antwort sollte funktionieren. Du musst die Zeile nur ins End-GCode einpflegen.

mjh11

rf1k_mjh11 hat geschrieben:Yalcin,

ACHTUNG: der M3079-Befehl klappt beim RF100 vermutlich nicht.
Mein GCode Vorschlag aus der ersten Antwort sollte funktionieren. Du musst die Zeile nur ins End-GCode einpflegen.

mjh11

Eigentlich wollte ich ja auf das Fettgedruckte hinweisen. Bei beiden Druckern hatte ich es gelegentlich , dass der Drucker nicht auf das "OUTPUT OBJECT" (im Display) reagierte. Habe keine Ahnung, ob das mit dem GCode zusammenhängt. Würde es aber gerne wissen.
Jedenfalls dürfte "OUTPUT OBJECT" die angestrebte Aktion sein und nicht "HOME", oder?

Yalcin,

hal4822 hat geschrieben:Jedenfalls dürfte "OUTPUT OBJECT" die angestrebte Aktion sein und nicht "HOME", oder?

Hier hat hal4822 auf jeden Fall recht. Wie ich in der ersten Antwort angedeutet habe, wäre ein "Home-All" auf jeden Fall zu vermeiden, da dann auch Z gegen 0 fährt:

rf1k_mjh11 hat geschrieben:Wenn der Drucker unmittelbar nach dem Drucken nach Home fährt, wäre das eine Katastrophe.

Aber "Home" ist ein dehnbarer Begriff. Man kann X homen, Y homen, Z homen. Das geht getrennt, alle zusammen, oder in diversen Kombinationen. Siehe dazu den Wiki Eintrag. Zu beachten ist, dass die Firmware des RF100 eine Marlin-Variante ist (der RFx000 benutzt eine Repetier Variante). Damit sind kleine Abweichungen, was die GCode Syntax betrifft, möglich.

mjh11

Ich habe das Problem gelöst.
Bei Endingt Script habe ich "G28 ; home all axes" geschrieben.

Yalcin hat geschrieben:Ich habe das Problem gelöst.
Bei Endingt Script habe ich "G28 ; home all axes" geschrieben.

Damit nicht jeder das für eine Lösung hält, hier der Text aus dem Wiki:

G28 - Fahre alle Achsen (oder die bezeichnete(n)) zum Ursprung

Parameter
[X Y Z] ... optional. Wird keine Achse angegeben, werden alle Achsen zum Ursprung gefahren.

Beispiel
"G28 Y0 Z0" fährt nur in Y und Z auf "0"

Anmerkung (mjh11): Hier scheint es einen kleinen Bug in der Syntaxabarbeitung zu geben. Bei Eingabe von "G28 X Z" oder "G28 X Y Z" wird nur X zum Ursprung gefahren (bei "G28 Y Z" nur Y, usw.).
Daraus folgt, dass die Angabe von "0" nach der Achsenangabe zwingend notwendig ist, wenn man mehr als eine Achse zum Ursprung fahren möchte.
In Wirklichkeit kann man eine beliebige Zahl angeben, der tatsächliche Wert wird einfach ignoriert. Demnach würde "G28 Y2 Z31" die Y und Z Achse zum Ursprung fahren.
Diese dargestellte Abarbeitung des Befehls weicht damit etwas von der 'offiziellen' Syntax ab.


Auch im Wiki ist rot als Warnung verwendet worden - stammt also nicht als Dramatisierung von mir !

In der Firmware wird beim Ausführen des G-Codes gefragt "ist X vorhanden?" "Ist Y vorhanden?" "Ist Z vorhanden?"
Ist eins vorhanden will die Zahl eingelesen werden, die zum G-Code-Zeichen gehört.
Es kann im Grunde gut sein, dass der Bug vom Encodieren ins "Binary-Format" kommt. Wenn man das über die serielle Leitung schickt, macht irgendeine Software von eurem Text einen komprimierten Befehl für den Drucker.
d.h.
- Die jeweilige Console könnte mitschuld sein.
- Wenn man den Befehl als Gcode-Datei auf die SD-Karte packt, könnte es sich anders verhalten als in Repetier-Host.

(Kann das gerade nicht testen. Die Tage mal ^^)

LG