Z Achse, Fahrweg verkleinern / Wer kann helfen?

[AtlonXP]

Und noch einen Gummipunkt nach Österreich.

Danke mjh11.

Am WE werde ich es mal an testen.

LG AtlonXP

[mhier]

Vielleicht sollten wir einen Firmware-Befehl einführen, mit dem sich das direkt konfigurieren lässt, ohne all diese Details zu wissen. Also irgend ein M-Befehl, der X, Y und Z als (jeweils optionale) Parameter akzeptiert, mit denen der maximale Verfahrweg in der jeweiligen Achse festgelegt wird. Macht das Sinn? Das müsste sich recht einfach implementieren lassen (könnte ich evtl. morgen abend mal in Angriff nehmen).

[rf1k_mjh11]

mhier,

Ich theoretisiere wieder in den Tag hinein und überlege ob ein eigener GCode Sinn macht.

a)
Für jene, die immer zwischen Fräs- und Druckoption (oder Laser) wechseln: Ja, da sich immer einer der Achsen ändern könnte oder tut. (Beim Fräsen sollte die Z-Achse eigentlich nicht notwendig sein, da ein zweiter Endschalter eingebaut sein sollte).
Andererseits reicht ein einmalig erarbeiteter GCode-Skript ebenfalls, um das selbe zu erreichen (mit M206 Befehl).

b)
Für jene, die nur (mit einem unveränderten Drucker) Drucken, sollte so eine Option überflüssig sein.

c)
Andere, die ihren Drucker modifiziert haben (anderes Hot End, z.B.) fallen in die erste Kategorie hinein. Den Drucker einmalig über deinen vorgeschlagenen GCode anpassen, oder einmalig sich die Syntax des M206-Befehls zu Herzen nehmen.

Off Topic - Keine Angst vor M206

---

Ich selbst habe keine Angst mehr, den M206-Befehl einzusetzen. Ich musste das öfters machen um mir die PID-Werte für meine beiden Hot Ends anzupassen (Pico und V2), da ich gelegentlich noch hin und her wechsle. Nachdem ich die Werte einmal erarbeitete, kamen diese in die entsprechenden Start-GCodes der Profile.

Vielleicht haben andere auch ihre Gedanken dazu?

mjh11

[AtlonXP]

Ich habe das noch nicht getestet, aber das sollte ich wohl mal machen, damit er mir nicht immer in den unteren Z-Schalter fährt

Hallo mhier,

zu deinem Problem habe ich (vorübergehend) folgende einfache Lösung als Vorschlag.

Du benötigst folgendes:
- Miniatur Schiebeschalter Z.B:

https://www.conrad.de/de/schiebeschalte ... 08046.html

- Miniatur- Microschalter nur diesen !:

https://www.conrad.de/de/Search.html?se ... 6%2BTaster

- Und natürlich den Fahrweg einmalig verkürzen in der Firmware.

Den Miniatur Schiebeschalter (Wechsler) baust du in dein Y Kabel als Umschalter für deine beiden Z Endschalter ein. Du kannst hier auch einen Doppelten nehmen und eine Kontrolllampe mit schalten.

Den Miniatur- Microschalter benötigst du aus dem gleichen Grund wie der Z Endschalter oben. Ich lege hier aber Wert auf einen Wechsler.
(Die Auflösung kommt nächstes Jahr).

Fräse oder Druck dir was, damit der untere Schalter in Deckung ist und nur die Fahne über dem Schalter heraus schaut. Falls die Z- Achse mal wieder zu tief fährt, dann geht der Schalter nicht kaputt.
Zur Erinnerung: Wer dem RFXXX am oberen Z- Schalter Weg klaut, dieser Weg fehlt dann unten in der Output Position!

Ich würde das meiste fliegend (also nur am flexiblen Kabel hängend) Verbauen und die offenen Kontakte mit Heißkleber isolieren.
Der Fahrweg sollte dann so begrenzt werden, dass der untere Z- Endschalter gedrückt wird, aber die Z- Achse nicht mehr auf Kollision fahren kann.

Für mich selber ist hier noch eine Frage offen:

„Was macht der RFXXX, wenn der Homingendschalter schon gedrückt ist und man am RFXXX homing startet?“
Ehrlich gesagt, ich trau mich nicht es aus zu Probieren.

Ein Nachteil natürlich noch angesprochen:
Wenn der Schalter im Druckbetrieb auf der falschen Stellung steht, dann knallt es und es gibt Scherben!

LG AtlonXP

[mhier]

Ich selbst habe keine Angst mehr, den M206-Befehl einzusetzen.

Das größte Problem, das ich sehe, ist, dass man sich damit extrem abhängig von eigentlich versteckten Details der Firmwareimplementierung macht. Ein Update auf eine andere Version kann im Prinzip jederzeit alles im EEPROM verschieben. Wenn alles richtig gemacht ist, wird der dann einmal neu initialisiert mit Default-Werten beim Update, aber dein G-Code macht dann evtl. kompletten Unsinn (schreibt wahllos an die falschen Adressen). Wenn man stattdessen für alles, was man gerne mal umstellen möchte, eigene GCode-Befehle einführt, hat man das Problem nicht.

Ich habe gelernt, bei der Software-Entwicklung immer so viel wie möglich zu abstrahieren, das hier ist genau so ein Fall. Es ist doch recht mühsam, beim Firmware-Update ggf. sämtliche Slicer-Profile und evtl. auch Fräs-Profile anpassen zu müssen und ggf. bei Vergessen schlimmstenfalls etwas zu zerstören (PID-Parameter auf völlig falsche Werte setzen, weil man ausversehen irgendwas anderes drüber geschrieben hat, kann evtl. das Hotend zerstören, denke ich). Daher meine Idee mit dem Befehl. Wer ihn nicht braucht, den stört er ja auch nicht

zu deinem Problem habe ich (vorübergehend) folgende einfache Lösung als Vorschlag.

Danke, aber mein Problem ist weniger, dass der untere Z-Schalter kaputt geht (das hält er schon aus). Das Problem ist vor allem, dass ich noch immer im Druck-Betrieb den Z-Schalter-Typ auf "Single" stellen muss, da sonst beim Homing gelegentlich das "driving free"-Problem auftritt. Ich habe das noch nicht näher untersucht, da anderes noch höher in meiner Prioritätenliste steht und meine Zeit leider viel zu knapp ist. Durch diese Einstellung wird der untere Z-Schalter ja bereits ignoriert. Da der Verfahrweg in der Firmware aber zu lang ist, fährt er regelmäßig zu weit. Da komm ich auch ohne Hardware-Eingriff wieder raus, ich muss nur den Schalter auf "Circuit" umkonfigurieren und den Drucker neu starten. Aber das ist eben alles etwas lästig... Ein kürzerer Z-Fahrweg würde schon enorm helfen.

Ein Nachteil natürlich noch angesprochen:
Wenn der Schalter im Druckbetrieb auf der falschen Stellung steht, dann knallt es und es gibt Scherben!

Genau deswegen würde ich das nicht machen. Früher oder später passiert nämlich genau das. Murphy's Law halt

[rf1k_mjh11]

Martin/mhier,

Das größte Problem, das ich sehe, ist, dass man sich damit extrem abhängig von eigentlich versteckten Details der Firmwareimplementierung macht. {damit spricht mhier die Verwendung des M206 Befehls an} Ein Update auf eine andere Version kann im Prinzip jederzeit alles im EEPROM verschieben. Wenn alles richtig gemacht ist, wird der dann einmal neu initialisiert mit Default-Werten beim Update, aber dein G-Code macht dann evtl. kompletten Unsinn (schreibt wahllos an die falschen Adressen). Wenn man stattdessen für alles, was man gerne mal umstellen möchte, eigene GCode-Befehle einführt, hat man das Problem nicht.

Besteht aber mit deiner Methode nicht eine genauso große Gefahr? Nur wenn die "C"-Entwickler deinen vorgeschlagenen GCode-Befehl implementieren, klappt es 'problemlos' (hoffentlich). Implementierst du den zusätzlichen Befehl, besteht genauso eine Gefahr, wenn man diese Änderung jedes mal an die neue Firmware Version angleichen muss. Ein kleiner Fehler und ....

Oder läuft so was durch GitHub dann automatisch?

Ich stimme dir zu, wenn die Firmware Programmierer an der EEPROM-Reihenfolge herum'murksen' könnte man Probleme bekommen. Ich kann in meinem Fall nur hoffen, dass so was im Changelog festgehalten wird - dann fällt es mir auf und ich kann entsprechend reagieren.

mjh11

[mhier]

So, ich habe einen entsprechenden Befehl implementiert. Die modifizierte Version der RF.01.33er Firmware gibt es hier:
https://github.com/mhier/Repetier-Firmw ... s_lenghtes

Der neue Befehl heißt M3901 und hat drei optionale Parameter X, Y und Z, mit denen jeweils in Millimetern die Achsenlänge festgelegt werden kann. Der Befehl gibt außerdem in der Konsole die Werte aus (in mm und Schritten) und kann entsprechend ohne Argumente dazu verwendet werden, den aktuellen Zustand abzufragen. Ich habe bewusst darauf verzichtet, die neuen Werte ins EEPROM zu schreiben. Das kann man problemlos mit M500 machen (speichert alle aktuellen Einstellungen ins EEPROM), wenn man möchte. M3901 kann man so jetzt ohne Weiteres z.B. als Start-GCode im Slicer hinzufügen, ohne unnötigerweise immer das EEPROM upzudaten (begrenzte Schreibzyklen...). Übrigens: wenn man zwischen Druck- und Fräs-Modus umschaltet, werden eh die hardgecodeten Defaultwerte eingestellt und das EEPROM damit überschrieben!

Besteht aber mit deiner Methode nicht eine genauso große Gefahr? Nur wenn die "C"-Entwickler deinen vorgeschlagenen GCode-Befehl implementieren, klappt es 'problemlos' (hoffentlich). Implementierst du den zusätzlichen Befehl, besteht genauso eine Gefahr, wenn man diese Änderung jedes mal an die neue Firmware Version angleichen muss. Ein kleiner Fehler und ....

Oder läuft so was durch GitHub dann automatisch?

Nein, die Gefahr besteht nicht. Dafür ist eine Source-Code-Versionsverwaltung wie git da (Github ist lediglich die Serverplattform, aber du hast schon recht im Grunde). Im Übrigen handelt es sich nur um ein paar Zeilen Code, die eingefügt werden. Der Code greift zwar nicht aufs EEPROM zu, selbst wenn der das täte, wäre er aber unempfindlich gegen Änderungen in der Reihenfolge, da er einfach die selben Adressen wie alle anderen Stellen, die auf die gleiche Variable im EEPROM zugreifen, verwenden würde (die sind in gobalen Konstanten gespeichert). Im Programmcode lässt sich so etwas tatsächlich wesentlich besser regeln als "zu Fuß". Außerdem gebe ich die Hoffnung nicht auf, dass Conrad solche Änderungen übernimmt

Ich stimme dir zu, wenn die Firmware Programmierer an der EEPROM-Reihenfolge herum'murksen' könnte man Probleme bekommen. Ich kann in meinem Fall nur hoffen, dass so was im Changelog festgehalten wird - dann fällt es mir auf und ich kann entsprechend reagieren.

Das ist möglicherweise nur sehr indirekt erkennbar...

EDIT: Ich seh gerade, dass wir hier im RF2000 Forum sind. Ich habe die Modifikation nur auf einem RF1000 testen können und entsprechend auch nur im RF1000-Verzeichnis eingepflegt. Da die Modifikation aber wirklich simpel ist, bin ich mir sehr sicher, dass es auch mit dem RF2000 keine Probleme geben wird. Der Unterschied zwischen den beiden Verzeichnissen besteht nur in der Konfiguration, die einmal den RF1000 und einmal den RF2000 konfiguriert. Also einfach die Firmware aus dem RF1000-Verzeichnis bauen und auf den RF2000 umkonfigurieren

[AtlonXP]

Hallo mjh11,

meine Hausaufgabe wurde letztes WE erledigt.
Dein Vorschlag mit dem M206 Befehl finde ich hervorragend.
Das Gute daran ist:

Diese Eingabe ist direkt und wird im EEPROM einfach und dauerhaft übernommen.
Es ist somit kein größerer Aufwand erforderlich.
Eine kurze Zusammenfassung.

Der erste Weg:
Man ändert in der Firmware die Parameter ab und muss somit alles neu kompilieren und einspielen.
Damit das Einspielen der gleichen abgeänderte Firmware klappt, muss zusätzlich noch ein Zahlenwert geändert werden.
Somit ist dieser Weg nur sinnvoll, wenn mehrere Parameter geändert werden sollen.
Beispiel:
In neueren Firmware Versionen könnten diese Werte in der RF1000.h (bzw. RF2000.h) stehen.
- Configuration.h: #define Z_MAX_LENGTH (long)200 -> 198
- Im Slicer : Z Max von 200 -> 198

Damit die Änderungen angenommen werden.
In der Configuration.h, ca. in der Zeile 1046:
#define EEPROM_MODE 1
Da ändert man die "1" (oder was immer) auf einen anderen Wert (nicht "0").
Es gehen auch Zahlenwerte rückwerts.
Kompiliert die FW neu und spielt diese auf.

Der zweite Weg:
Man liest mit dem M205 Befehl den zu ändernden Parameter aus, trägt diesen im M206 in abgeänderter Form ein und sendet diesen per G-Code Eingabe an den Drucker und fertig.

Beispiel:
Mittels G-Code den EEPROM-Wert an Speicherstelle 153 zu ändern (original: 200)
(hier ein Ausschnitt aus dem Ergebnis des M205-Befehls:
M205 -> 20:56:11.84: EPR:3 153 200.000 Z max length [mm]

Befehl per G-Code senden.
M206 T3 P153 X198.0

Zur Erklärung:
Typ: Langer Integer, dann muss man "S" verwenden.
Typ: Fließkommazahl, dann muss man dem Wert ein "X" vorsetzen.

Nochmals mit M205 überprüfen.
Fertig.

Dies war eine schöne Lernstunde zu meinem ersten Firmware fummeln.
Vielen Dank nochmal.

LG AtlonXP