Ist dokumentiert welche GCodes implementiert sind?

Firmware Veröffentlichungen und Einstellungen können hier angekündigt und diskutiert werden.
loonquawl
Filamenttester
Filamenttester
Beiträge: 13
Registriert: So 12. Okt 2014, 13:52
Hat sich bedankt: 2 Mal

Ist dokumentiert welche GCodes implementiert sind?

Beitrag #1 von loonquawl » Mo 5. Jan 2015, 21:24

Mich würde interessieren, welche Gcodes schon umgesetzt sind - gibt es da eine leicht zugängliche (leicht downloadbar, aber auch "aufgearbeitet" :whistle: ) Liste, oder muss man in die Source der firmware kucken?

Danke!

loonquawl
Filamenttester
Filamenttester
Beiträge: 13
Registriert: So 12. Okt 2014, 13:52
Hat sich bedankt: 2 Mal

Re: Ist dokumentiert welche GCodes implementiert sind?

Beitrag #2 von loonquawl » Mo 5. Jan 2015, 21:30

:lol:
... oder ich google einfach mal vernünftig....
https://github.com/repetier/Repetier-Fi ... ki/G-codes ... ki/G-codes

Benutzeravatar
rf1k_mjh11
Developer
Developer
Beiträge: 1704
Registriert: Di 6. Jan 2015, 19:44
Wohnort: Autriche
Hat sich bedankt: 214 Mal
Danksagung erhalten: 434 Mal

Re: Ist dokumentiert welche GCodes implementiert sind?

Beitrag #3 von rf1k_mjh11 » Mi 7. Jan 2015, 21:39

Hallo allerseits - bin Forums-Neuling.

Habe einen RF1k seit vergangenen Mai, und schon seit 2011 einen Reprap Mendel.

Zu loonquawl, RE: Implementierte GCOdes:

Die Wiki-Seite, die angegeben ist, sagt dir welche offiziellen gcodes in der Repetier-Firmware verwendet werden, aber es fehlen viele in der Liste. Die Firmware für den RF1k verwendet mehrere dutzend zusätzliche, eigens auf die Maschine zugeschnittenen Codes.

Diese speziellen Codes kann man in zwei der Firmware-Dateien finden:
in "Repetier.ino" findet man die implementierten gcodes der standard Repetier-Firmware
in "RF1000.h" findet man die speziell angepassten gcodes (alles M3xxx - Befehle)

Wenn man vorsichtig ist (ja nichts ändern!) kann man die Textstellen mittels editor (notepad.exe o. Ä.) mittels Cut&Paste in eine neue Referenz-Datei schreiben, so wie ich es tat. Ich hänge diese Datei an, aber Vorsicht!! in den letzten Firmware Versionen haben sich einige Befehle geändert, wurden gelöscht oder sind dazugekommen. Daher muss man meine Liste als 'OHNE GEWÄHR' akzeptieren - sie gilt nur bedingt für andere Versionen, und auch für die angegebene, sind Fehler nicht ausgeschlossen.

mjh11
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Merke, am PC gibt es immer einen Weg!
Schafft es der Mensch, einmal etwas idiotensicher zu machen, kontert die Natur sofort mit einem besseren Idioten.

loonquawl
Filamenttester
Filamenttester
Beiträge: 13
Registriert: So 12. Okt 2014, 13:52
Hat sich bedankt: 2 Mal

Re: Ist dokumentiert welche GCodes implementiert sind?

Beitrag #4 von loonquawl » So 11. Jan 2015, 13:55

Da habe ich doch glatt meinen Post von "gelöst" auf "Frage" zurückgestellt...
Ich hatte den RepetierHost geupdated, und dabei natürlich(?) das RF1000 Flavor (also RF1000-Bild bei Programmstart, etc) verloren (die alte Version ist aber noch parallel installiert, und hat das Flavor behalten).
Meine aktuelle Repetierversion ist 1.0.6, meine Slic3r-Version 1.1.7. Ich habe leider vor dem Update nicht danach gesehen, aber aktuell ist in Slic3r (egal von welcher Repetier-Version gestartet) unter PrinterSettings/Firmware das "G-Code Flavor" als "RepRap[...]" angegeben, keine spezielle RF1000-Einstellung auswählbar. Der produzierte Gcode enthält aber beispielsweise M3001 und M3004 - woher hat sich der Slic3r also die . h geholt, und an welcher Stelle kann man das beeinflussen?

Benutzeravatar
rf1k_mjh11
Developer
Developer
Beiträge: 1704
Registriert: Di 6. Jan 2015, 19:44
Wohnort: Autriche
Hat sich bedankt: 214 Mal
Danksagung erhalten: 434 Mal

Re: Ist dokumentiert welche GCodes implementiert sind?

Beitrag #5 von rf1k_mjh11 » Mo 12. Jan 2015, 13:09

Diese M3001, bzw. M3004 Befehle stehen gewiss ganz am Anfang des GCodes, also im Start.Code-Bereich, welche man selbst definiert hat (durch Eintippen oder durch Übernahme des Codes von einem Dritten).

Stehen diese zwei Befehle jedoch irgendwo in der Mitte des GCodes, sollte man diese grundsätzlich in Frage stellen da sie dort keinen Sinn ergeben - wozu sollte man z.B. erst mitten im Druck die Z-Kompensation einschalten? Gerade diese Funktion ist in den ersten Layern sehr wichtig um eine eventuelle Bettunebenheit auszugleichen. Bei mir ist das Bett ziemlich 'horizontal, so gut ich es halt hinbekommen habe. Aber die Keramikplatte selbst ist leicht bombiert. Ohne Z-Kompensation könnte ich das nicht ausgleichen.
Übrigens gleicht die Firmware, meiner Beobachtung nach, so eine Unebenheit oder Schieflage nur eine Zeitlang aus, nach 1 oder 2mm Höhe hört die Kompensation auf - die Z-Achse ist also nicht dauernd am arbeiten, was immer wieder angedeutet wird. Dazu wird der Fehler pro Layer nur zum Teil kompensiert. Nehmen wir als Beispiel an, die Mitte des Betts wäre um 0.1mm zu hoch. Beim Drucken der ersten Lage fährt das Bett als Ausgleich z.B. nur 0.09mm beim Drüberfahren nach unten (Die Layer-Höhe schluck das fehlende 0.01mm locker). Beim nächsten Layer fährt das Bett nur 0.08mm hinunter. Und so weiter. Nach einigen Layern gibt es dann keine Notwendigkeit mehr, mit der Z-Höhe zu jonglieren (in diesem Fall nach 10 Layern). Verwerfungen des Heizbettes werden ziemlich sicher so behandelt. Wie es bei einer Schieflage des Betts gehandhabt wird, kann ich nicht bestätigen.

mjh11
Merke, am PC gibt es immer einen Weg!
Schafft es der Mensch, einmal etwas idiotensicher zu machen, kontert die Natur sofort mit einem besseren Idioten.


Zurück zu „Firmware / Tweaks“