OutputObject weist Fahrt über Bauraumgrenzen hinaus an

[ChristophWWagner]

Hallo liebe Community-Entwickler und Entwickler-Community,

bei der Ausführung von outputObject() werden die Strings OUTPUT_OBJECT_SCRIPT_PRINT oder OUTPUT_OBJECT_SCRIPT_MILL als G-Code ausgeführt. Hierbei ist die feste Endposition Z200 Y245 kodiert. Eventuell gibt es noch mehr fest kodierte C-Godes, da habe ich mich noch nicht genauer umgeschaut.

Da der Bauraum auch durchaus etwas kleiner sein kann (zweiter Z-Endstopp, etc.) sollten die hier (und auch anderswo) eingetragenen Werte die spezifizierten Limits Y_MAX_LENGTH und Z_MAX_LENGTH in derRFx000.h` nicht überschreiten. Grundsätzlich sollte sich nicht auf Sicherungsmechanismen verlassen werden, welche über den Bauraum hinausgehenden G-Code in letzter Instanz beschränken. Stattdessen dürfen statische und fest programmierte Anweisungen nur stets innerhalb der Grenzen der Maschine operieren, um gekoppelte Fehlereffekte zu verhindern.

Aktuell führt das zu dem Problem, dass bei kleinerem Bauraum alle fest kodierten G-Codes manuell an die Limits angepasst werden müssen. Mein Vorschlag zur Lösung ist es, Strings für die Zahlenwerte der Einträge X_MAX_LENGTH, Y_MAX_LENGTH und Z_MAX_LENGTH zu generieren und diese dann in die Strings einzubinden.

Ich wünsche Euch allen ein frohes Osterfest!

Gruß, Christoph

[Nibbels]

Hallo Christoph,

diese OutputObject konstanten sind mir noch bekannt. Es gibt mehrere Fälle: RF2000 und RF2000v2: Diese haben einen Z-Max-Endstop. Wird der Endstop erreicht sollte in jedem Fall Ende der Achse sein. RF1000: Dabei muss man sich auf die Z_MAX_LENGTH (bzw. das EEPROM) verlassen.

Z_MAX_LENGTH ansich hat nichts mehr zu sagen, sobald man den Wert im EEPROM überschreibt. Dieser Wert in Z_MAX_LENGTH wird nur von EEPROM::restoreEEPROMSettingsFromConfiguration() und Printer::setup() als Init Wert verwendet. Entsprechend dient die reine Konstante nur als default-Wert für den Fall eines Werksreset. Man müsste beim OutputObject die Werte aus dem EEPROM einfügen. Ich arbeite in C ungern mit Strings, die ich dynamisch verwende. Und man hätte im OutputObjectScript Platzhalter einführen müssen. Darum habe ich damals meine Finger davon gelassen. Diese hart codierten Scripte gefallen mir selbst nicht. Ich bin mehr ein Freund von einer sauberen Funktion, die nacheinander die entsprechenden Funktionen aufruft.

-> Das Limit das du anstelle von Z_MAX_LENGTH eigentlich anpassen musst, ist das EEPROM, nicht die Konstante. Der Wert bleibt (Beim Community-Mod) auch nach dem flashen einer neuen FW normalerweise erhalten.

Noch was, soweit ich mich noch erinnere: Ich habe mal die Logik so umgebaut, dass der Drucker "virtuell" aus seinem XYZ-Bauraum rausfahren kann, aber dort nicht mehr extrudieren darf. Die Achsen bewegen sich auch nicht mehr ausserhalb des Bauraums. Das habe ich gemacht, um relative Bewegungen korrekt Rückabwickeln zu können. Und wenn ichs noch richtig weiß ist der maximale Bauraum in Z definiert durch (Endschalter ODER dem EEPROM-Wert von Zmaxlength)

Wenn du C gut verstehst, kannst du gerne Pull-Requests erstellen und die FW mit verbessern. Das Output-Object-Script als Konstante braucht ansich niemand. Man kann das auch komplett ersetzen und aus der Config entfernen. Oder wir setzen das Default auf viel zu kleine 180, weil das fast jeder RF kann. Auch mit E3D Vulcano oder anderen Mods. Und wer mehr kann/braucht soll sich das auf seinen Realwert freischalten.

Mein RF2000 schafft 196mm in Z, wenn ichs grad richtig weiß. Mich freuts grundsätzlich, wenn sich noch jemand für die FW interessiert. Ideen und Pull-Requests sind immer willkommen. Nur habe ich selbst nicht mehr viel Zeit um an der FW zu arbeiten. NiceToHaves sind bei mir eher auf der langen Warteliste. Bugs mach ich wenns geht zeitnah weg. Meine eigene Todo: Wenn der Drucker aufgrund der Auto-Pause bei verstopfter Düse in die Pause geht, schaltet sich die Temperatur nicht runter. Das stört mich aktuell noch. Zudem würde ich gerne einen Standard-Filament-Sensor (Rolle zuende) in die FW einpflegen.

LG Stefan

[mhier]

Die Output-Object Logic nervt mit regelmäßig, aus verschiedenen Gründen:

• Warum immer ganz nach unten fahren, das kostet nur unnötig Zeit.
• Beim RF1000 fährt er per default so weit, dass anschließend der untere Z-Schalter gedrückt ist. Wenn man den Z-Schalter trotzdem auf "single" statt "circuit" konfiguriert hat (Workaround für die bekannten Probleme - immer noch nicht gelöst, oder?), kommt man da nicht wieder weg.
• Manchmal macht er output object wenn man es gar nicht will. Im Fräsmodus z.B. will ich mehrere Dateien hintereinander Fräsen können, output object macht mir dann die Origins kaputt (stepper werden abgeschaltet).

Pragmatische Lösung: komplett deaktivieren und bei Bedarf in den G-Code im Slicer einbauen.

Allerdings: schön wäre eine Logik nach dem Motto: fahre 50 mm nach unten, aber maximal bis Zmax erreicht ist. Das lässt sich per G-Code im Moment aber nicht ohne Weiteres erreichen (außer der Slicer hat das aktuelle Z als Variable zur Verfügung und erlaubt Rechenoperationen...). Vielleicht sollte man dafür einen speziellen G-Code einführen?

[Nibbels]

Wie das mit dem OutputObject gerade geregelt ist, weiß ich spontan nicht auswendig. Im Druckmodus muss man immer zwischen SD und USB-Druck unterscheiden, darum kann ich ohne Test und reinschauen nichts kommentieren. Zudem müsste ich prüfen, was mein Repetier-Server vor und nach dem Druck als Macro schickt.

Das mit dem RF1000 und dem Circuit: Drive-Free haben wir zum Schutz des oberen Endschalters radikal entfernt. Ich hab anschließend vergeblich versucht, Tester für das Problem zu finden, aber damals hat sich niemand gemeldet. Beim RF2000 funktioniert das. Die meisten haben den Schalter nicht und nutzen das Z-Max im EEPROM zum Stoppen der Achse vor dem ratternden Ende.

Wenn man im Fräsmodus ein Output-Object nicht haben will kann man das bestimmt einfach rausnehmen. Es macht beim Fräsen wohl auch Sinn wie du sagst. Zuerst mal würde ich wegen dem Fräsen die Funktion beim Drucken nicht anfassen aber im Fräsmodus das OutputObject durch Compiler-Anweisungen ausklammern, oder?

[Nibbels]

Ich hab nochmal geschaut: Würden wir im statischen Script Z nicht auf 200mm schicken, sondern auf halbe Höhe etc. so könnte es bei großen Bauteilen dazu führen, dass das Teil am Ende zerquetscht wird. Also müssten wir relative Koordinaten einbauen. Zumindest wird auch dann das Limit ohne Endstop und Achsenlimit nicht beachtet.

Das automatische Output-Object beim Stoppen vom SD-Druck sollte in der nächsten Version für den Milling-Mode (>1.45.00) raus sein. Dann muss man immer M3079 am Ende seiner Scripte einfügen, wenn man das möchte. Bitte testet das auch, ich code das nur nach bestem Gewissen, aber werde es nicht live testen.

[Nibbels]

https://github.com/RF1000community/Repetier-Firmware/commit/6f78ba84ebaeaa4f66e44f87e82433f339efe286

Ich habe das output_object nur im Milling-Mode rausgenommen. Nun würde ich das Issue hier erstmal schließen. Wenn noch was wäre oder jemand auf eine bestimmte Änderung besteht einfach wieder öffnen und weiter diskutieren.

Wegen dem Circuit / Single und dem Drive-Free habe ich das wiederentdeckt: https://github.com/RF1000community/Repetier-Firmware/issues/44