Endposition M3079

[Byterunner]

Hallo
Habe die .51 als Firmware drauf und mit repitierhost 1.06 gedruckt
Beim Befehl M3079 (Endcode) fuhr die z Achse nach unten... Aber bis zum Anschlag (also z weit)
Bedingt durch den Umbau auf Miller hat die ZAchse noch einen ZEndschalter dazu bekommen. Was passiert ... Z Achse wird scheinbar von 200 auf 0 gesetzt.

Jetzt ist es nicht mehr möglich die Z Achse zu reseten und eingentlich sagen -200 = 0
Jetzt meine Frage:
Befehl M3079 wird glaube ich in communication.h eingestellt (Udo ???)
Dass sichergestellt ist, dass Endposition z199 ist... Oder???

Wie bekomme ich den Tisch wieder auf die eigentliche z Position?
Heatbed scan geht... Aber geht's vielleicht einfacher?
Byte

[shaddi]

Hi,

das ist mir auch aufgefallen. Vor allem bei der y-Achse schlägt das mir dauernd an den Anschlag...

Das M3079 wird in Configuration.h definiert:
[code:2g715y2e]#define OUTPUT_OBJECT_SCRIPT "G21
G91
G1 E-10
G1 Z210 F5000
G1 X0 Y220 F7500
"[/code:2g715y2e]

G21 - Auf Millimeter umstellen
G91 - Auf relative Einheiten umstellen (und ich glaube hier ist der Fehler)
G1 E-10 - Filament zurück ziehen
G1 Z210 - Z 210mm "runter"
... usw usw.....

Wenn man also ein Objekt mit 100mm höhe gedruckt hat, schiebt er das Bett an die theoretische Position Z=310...

Verstehe ich den Gcode nicht, oder ist das wirklich broken?

[riu]

Also Z210 ist definitiv falsch. Der Z Verfahrweg ist beim RF1000 200 mm. Wenn man ein Objekt mit 100 mm Höhe druckt, und dann auf z.B. Z 200 mm fährt dann wird das auch gemacht. Relative Positionierung ist natürlich quatsch, so wie die 210 mm. Ist das define wirklich aus dem aktuellen Quellcode für den RF1000?

Gruß,
Udo

[Byterunner]

Kennt ihr einen Befehl, der die Zachse neu justiert...
Also wo sagt in druckermode fahre das Ding gegen den oberen Z Schalter bzw. im Millermode gegen den unteren Z Schalter?
Zumindest im Druckermodus?
Wie schalte ich eigentlich zwischen den zwei Modis um? Muss mal suchen ... Wenn es jemand schon weiß ist es besser:)

[Byterunner]

Ja der String ist tatsächlich im 51 Code
Ich ändere es mal ab g91 zu g90 und die z von 210 auf 200
Compilere das Zeug neu und Grüße ans eeprom

[Byterunner]

Habe jetzt mal CNC enabled und die Grundfunktion auf Printer gelegt.
Das ändern der OUTPUT_OBJECT hat nichts gebracht, außer dass ich mir beim sielen den ZSchalter platt machte.
Aber ich hatte ja schon den Umbausatz (Udo danke) da, inkl. den neuen Halter ausgedruckt (auch danke an den edlen Spender)

Was mir aber auffiel bzw. durch dén Kopf geht:

Die Ganze Y Plattform wurde doch durch den Umbau zum CNC um 4mm dicker, da der Untertisch nicht mehr 4mm sondern 8 mm ist.
Ergo: Oben zum Hotend wird der Abstand 4mm mehr. Also wird der Z Raum um 4mm kleiner also 196 mit eine kleiner Fehler bedingt durch den zusätzlichen Z Endanschlag.

Was ich in der Firmware gesehen habe, dass es im CNC Mode den Z-END MIN und MAX gibt... aber leider nicht in der Funktion als Drucker...
Da aber die Schalter parallel geschalten sind kommt es nach meiner Meinung unweigerlich zur Fehlinterpretation, wenn bei der Z Achse >195 angefahren wird.

Was denkt ihr darüber? Ich habe von den Ding von Drucker und Code eigentlich keine große Ahnung.

Ralf

[rf1k_mjh11]

Hallo allerseits,

Ich habe im GitHub Forum eben das Problem gemeldet. Wie Udo, usw. erkannt haben, ist die Umstellung auf relative Koordinaten nicht unbedingt die schlaueste Lösung.

Ich schlage vor den String in Zeile 1503 (der Datei Configuration.h) wie folgt umzuändern:

Alt/Falsch:
#define OUTPUT_OBJECT_SCRIPT "G21
[color=#ff0044:1d117812]G91[/color:1d117812]
G1 E-10
G1 Z210 F5000
G1 X0 Y220 F7500
"

[color=#008800:1d117812][size=4:1d117812]Neu[/size:1d117812][/color:1d117812], Variante "A":
#define OUTPUT_OBJECT_SCRIPT "G21
M83
G1 E-10
G1 Z210 F5000
G1 X0 Y220 F7500
"
Variante "B":
#define OUTPUT_OBJECT_SCRIPT "G21
G91
G1 E-10
G90
G1 Z210 F5000
G1 X0 Y220 F7500
"

Bei Variante A wird nur der Extruder in den relativen Modues versetzt (mittels M83 statt G91), damit haben die X, Y und Z Koordinaten weiterhin ihre Gültigkeit. Bei Variante B wird gleich nach dem Retract wieder in den absoluten Koordinatenmodus zurück gewechselt (mittels G90), womit die X, Y und Z Koordinaten auch wieder OK sein sollten.
Ich habe beide Varianten mittels manueller Eingabe in Repetier-host ohne Probleme getestet.

Mit dem Originalskript gibt es interessanterweise bei mir aber kein Z-Crash - da kommt eventuell eine zusätzliche Firmware-Absicherung zum Tragen. In Y, jedoch, fährt das Bett auf mechanischen Anschlag. Der Extruder bleibt übrigens stehen und fährt nicht, wie man vielleicht erwarten würde, auf die Seite.
Ich nehme an das der Firmware-Skript sowohl über die Tastenbedienung, als auch über den M3079-Befehl aufgerufen wird. Ich kann es leider nicht bestätigen, da ich diesen Fehler schon vor dem Firmware-Upgrade gesehen und behoben habe (mittels variante "A").

Angehängt ist, mehr oder weniger, der Text den ich bei der Issue-Eingabe im GitHub Forum verwendet habe.

Mal gespannt, bis wann sich einer meldet.
Schon lange nichts von RF1000 gehört - ist der überhaupt noch aktiv? Wäre schade wenn er sich von den vielen negativen Bemerkungen verscheuchen ließe. Das wäre nämlich ein guter Punkt für ihn oder sie, um es an die richtigen Stellen weiterzuleiten.

mjh11

[rf1k_mjh11]

Byterunner,

Siehe meine vorgeschlagene Änderung. Die bloße Änderung von G91 auf G90 könnte beim folgenden Befehl "G1 E-10" unter Umständen zu gänzlich unerwarteten Ergebnissen führen. Nicht unbedingt, aber möglicherweise.
Besser wäre das Austauschen vom G91 Befehl durch M83. Da wird nur der Extruder in den relativen Modus versetzt, die anderen Koordinaten bleiben davon unberührt.

Andererseits wird deine Vorgehensweise wahrscheinlich auch funktionieren. Probleme gäbe es nur, wenn aus irgendeinem skurrilen Grund der Extruder schon auf einen negativen, oder hohen Wert wäre. Wenn der Extruder, wie gesagt, auf z.B. -15 stünde, würde der G1 E-10 Befehl dazu führen, dass der Extruder 5mm Filament ausspuckt - da kommt ein schoner Batzen auf das Werkstück. Wahrscheinlicher ist es (je nach Slicer Software), dass der Extruder einen hohen Wert hat, z.B. 45 oder 65. In so einem Fall führt der Befehl dazu, dass der Extruder 65 oder 75mm Filament wieder hochzieht. Und da kann es passieren, dass das heiße, weiche Filament bis zur Rändel hochgezogen wird - da es noch weich ist, wird es durch die Andruckrolle breitgequetscht - dann ist es kalt und kann weder vor noch zurück und muss abgeschnitten werden. (Das passierte einmal bei meinem Mendel Drucker - ich musste den Extruder teilzerlegen, da man nicht so gut dazu kam wie beim RF1k).

mjh11

[RF1000]

Hallo,


ich bin natürlich noch da
Im Grunde habe ich die Parallel-Diskussion auf GitHub ja schon beantwortet, aber als Zusammenfassung gerne auch noch einmal hier:

Ein Befehl wie z.B. "G1 Y500" macht normalerweise keinen Quatsch, und zwar egal ob der RF1000 gerade auf absolute oder auf relative Koordinaten eingestellt ist. Aufgrund von Y_MAX_LENGTH weiß der RF1000 nämlich, wie weit er sich vom Y-Min Endschalter wegbewegen darf. Und er fährt die Y-Achse dann auch nicht weiter, selbst wenn der Anwender/G-Code bis Y500 wollen würde.

Im OUTPUT_OBJECT_SCRIPT ist mit Absicht ein relativ großer Y- (und auch Z-) Wert genommen worden, damit der Tisch eben ganz nach unten und ganz nach vorne rausfährt.


mfG
Euer RF1000


PS: Die ursprünglichen Fragen von Byterunner waren ja folgende:
- Wie schalte ich eigentlich zwischen den zwei Modis um?
-> Das geht direkt im Menü des RF1000 ("Configuration" -> "General" - > "Mode"). Nur für den Fall, dass es noch nicht gefunden worden ist.
-> Den Defaultmodus kann man auch in Configuration.h einstellen (siehe DEFAULT_OPERATING_MODE).

- Bedingt durch den Umbau auf Miller hat die ZAchse noch einen ZEndschalter dazu bekommen. Was passiert ... Z Achse wird scheinbar von 200 auf 0 gesetzt.
-> Das schauen wir uns an. Als Workaround hilft es derweil, beim Drucken den Z-Max Endschalter abzustecken. In dem Fall muss natürlich sichergestellt werden, dass der Weg vom (aktiven) Z-Min bis zum (abgesteckten) Z-Max Endschalter kleiner ist als Z_MAX_LENGTH - dieser Wert muss in Configuration.h also gegebenenfalls angepasst werden.

[rf1k_mjh11]

RF1000 und Forumsmitglieder,

Ich hatte heute schon einigen eMail-Verkehr mit RF1000 über das GitHub Forum. Ich muss meine Aussage bzgl. Crash in Y revidieren.

Ich hatte von Anfang an meine Endschalterstellung für Y so geändert, dass die Düse nur 3-4mm über das Bettende hinausragte - in der irrigen Annahme dadurch einen größeren druckbaren Bereich zu erreichen. Als Folge fährt der Drucker auf einen mechanischen Anschlag wenn der OUTPUT_SCRIPT abgearbeitet wird. Inzwischen habe ich meinen Y-Anschlag wieder auf den Wert der Montageanleitung gstellt und der Skript läuft ohne Crash ab.
Wie RF1000 richtig hervorhebt, die Firmware hat zusätzliche Sicherheiten eingebaut, dass normalerweise kein Crash stattfinden kann. Ist der Drucker in irgendeiner weise modifiziert, könnte ein Crash stattfinden (so wie bei mir). Hat einer z.B. einen längeren Extruder eingebaut, könnte es zum Z-Crash kommen, muss aber nicht.
So viel zum Y-Crash.

Unglücklich bin ich aber weiterhin mit dem Umschalten in den relativen Modus. Aus mindestens zwei Gründen. Einmal merkt sich der Drucker ja, dass er im relativen Modus ist. Gibt man manuell weitere GCodes ein, z.B. "G1 X50", fährt der Extruder nicht dorthin, wo ich es als Laie erwarte, zu einer Position 50mm rechts vom linken Rand, sondern 50mm nach rechts von der augenblicklichen Position. So was kann sogar einen Druckversuch unbrauchbar machen, wenn man unmittelbar nach dem OUTPUT_SCRIPT ein weiteres Projekt über ein GCode-File absendet - das ist allerdings abhängig von der Slicer-Software, falls kein "G90" Befehl rechtzeitig abgesendet wird. Ich hatte genau deswegen Probleme beim Simulieren des Problems. Ich hatte ja meine Firmware schon (mittels M83 Befehl) geändert und musste daher alles manuell nachvollziehen. Jedesmal stolperte ich über den "eingeschlichenen "G91" Befehl als ich versuchte die Koordinaten (GCode Befehle) einzugeben und die Ergebnisse meinen Erwartungen widersprachen.

[size=5:13ae12uc]Zusammengefasst:[/size:13ae12uc]

Falls der Drucker dem Originalzustand entspricht, sollte der Skript keine Probleme bereiten.
Der Extruder wird nicht nach links, zu X=0 bewegt (mittels G1 X0), was keine Konsequenzen hat, und laut letzter eMail von RF1000 auch mittlererweile aus dem Skript entfernt wurde
Falls also ein Rattern auftritt (Hinweis auf eine Fahrt gegen mechanischen Anschlag), sollte man nochmals alle Enschalterstellungen kontrollieren und den Einfluß von etwaigen Modifikationen berücksichtigen.

Sorgt auf jeden Fall für ein "G90" Befehl im jeweiligen Start Code der verwendeten Slicer-Software um scheinbar skurriles Verhalten zu vermeiden (Kode möglichst nahe am Anfang unterbringen).

mjh11