Neue Development Firmware (RF.01.31)

[RF1000]

Hallo mhier,


deine Tests 1 und 2 fangen damit an, dass die Einstellung von Z-Min signifikant außerhalb der vom Handbuch vorgegebenen Toleranz erfolgt. Weder der Microschalter vom RF1000 noch die Lichtschranke vom RF2000 überleben es auf Dauer, wenn sie um z.B. 5 mm überfahren werden, der Heizbettscan ist in einer derartigen Konfiguration daher mit der originalen Hard- und Firmware nicht möglich.

Wenn du einen Z-Min Schalter verwenden würdest der diese Attacke überlebt, dann würde dein Test 1 tatsächlich nicht die gewünschte Objekthöhe bringen. Test 2 sollte aber problemlos funktionieren.

Solche Tests sind extrem wichtig, werden aber anscheinend nicht durchgeführt von Conrad.

Das ist eine falsche Annahme. Beide Tests kannst du auch mit einem korrekt eingestellten Z-Min Schalter durchführen, mit einer Abstandslehre kann man den Abstand von Heizbett <-> Extruder schließlich auf zumindest 0,05 mm genau ermitteln. Zusätzlich kann man sich die Z-Position auch im Display wahlweise auch "ab Heizbett" oder "ab Z-Min" anzeigen lassen und kann damit die Messung laut Abstandslehre kontrollieren. Falls du Interesse an unseren entsprechenden G-Codes dafür hast kann ich sie dir einmal zusammen mit dem Testablauf zusenden.

Wir sind bei der Diskussion nun an dem Punkt angelangt wo wir grundsätzlich darüber übereinstimmen, dass die RF.01.31 die Höhe von den ersten Layern exakt so abfährt, wie der G-Code es will (und zwar unabhängig davon, ob dafür Z-Min überfahren werden muss oder nicht). Korrekt? Diese Funktionalität wird durch FEATURE_Z_MIN_OVERRIDE_VIA_GCODE erreicht - wenn dieses Funktionalität aktiv ist kann G-Code den Z-Min Schalter überfahren. Z_OVERRIDE_MAX ist die daraus resultierende, notwendige Konsequenz die verhindert, dass der G-Code den Z-Min Schalter zu weit überfährt. Bis zu diesem Punkt ist es noch nicht relevant, ob die Z-Kompensation aktiv ist oder nicht, weil ich ja ein "G1 Z-10" jederzeit an die Firmware senden könnte ... und die Firmware muss das korrekt verarbeiten, ohne den Extruder durch das Heizbett zu stoßen.

Die nächste Evolutionsstufe wäre das Verhindern der Berührung zwischen Heizbett und Extruderspitze auf Basis der bekannten Heizbettmatrix. Das wurde in diesem Schritt noch nicht umgesetzt weil:

- es unter normalen Bedingungen nicht auftreten kann (weil G-Code keine negativen Z-Positionen anfährt, Z-Min mechanisch korrekt eingestellt ist und die Firmware immer korrekt erkennt, ob Z-Min oder Z-Max ausgelöst ist)
- dieser Schritt weitere Abhängigkeiten erzeugt, z.B. muss ja der Extruder potenziell auch bei X/Y-Bewegungen vom Heizbett weggefahren werden, um den gewünschten Sicherheitsabstand zu behalten
- dieser Schritt unter manchen Umständen keine Verbesserung bringt, z.B. wenn die Heizbettmatrix nicht vorhanden oder falsch ist, wenn die Z-Kompensation nicht eingeschalten worden ist, wenn das Bett sehr schräg ist und die Geschwindigkeit in X/Y-Richtung sehr schnell ist, ...

Ist dir denn ein Scenario bekannt, bei dem es mit der RF.01.31 und einem korrekt (= laut Anleitung) eingestellten Z-Min Schalter zur Berührung zwischen Extruder und Heizbett kommen kann, ohne dass du die Z-Achse manuell bis zur Berührung nach oben fährst? Falls ja, können wir bitte den entsprechenden G-Code bekommen?


mfG
RF1000

[RF1000]

(Circuit; Warum konnte man hier keinen zweiten Eingang nutzen? Es war bekannt, dass Fräsen kommen sollte.

Meine Idee war das nicht, aber manchmal wird nicht alles so gemacht, wie ich es gerne machen würde ...

[mhier]

deine Tests 1 und 2 fangen damit an, dass die Einstellung von Z-Min signifikant außerhalb der vom Handbuch vorgegebenen Toleranz erfolgt. Weder der Microschalter vom RF1000 noch die Lichtschranke vom RF2000 überleben es auf Dauer, wenn sie um z.B. 5 mm überfahren werden, der Heizbettscan ist in einer derartigen Konfiguration daher mit der originalen Hard- und Firmware nicht möglich.

Dass das nicht mit der originalen Hardware geht, habe ich geschrieben. Die nötigen Modifikationen sind relativ trivial machbar. Seit mal nicht so fantalsielos. Man kann auch einfach einen entsprechend dicken Metallklotz zwischen Schalter und Schraube halten während das Z-Homing durchgeführt wird, und ihn dann wieder rausnehmen. Das hat den selben Effekt, denk ich. Sonst halt eine horizontale Gabellichtschranke, die kann man beliebig weit überfahren!

Wenn du einen Z-Min Schalter verwenden würdest der diese Attacke überlebt,

Das wäre keine Attacke. Eher im Gegenteil, ein entsprechend konstruierter Z-Min wäre von vorn herein wünschenswert gewesen...

dann würde dein Test 1 tatsächlich nicht die gewünschte Objekthöhe bringen.

Eben. Das ist der eine der beiden Bugs.

Test 2 sollte aber problemlos funktionieren.

Nein, wegen Z_OVERRIDE_MAX. Und das ist dann der andere der beiden Bugs! Wenn Z_OVERRIDE_MAX so groß wäre, dass lediglich der Z-Min-Schalter mechanisch geschützt wäre, könnte ich das ja noch verstehen. Es ist aber meines Wissens bei 0.5mm, was die obere Grenze für den laut Handbuch zugelassenen Abstand zwischen Düse und Heizbett bei der Kalibration ist. Dazu kann dann aber noch Unebenheit des Heizbetts kommen!

Solche Tests sind extrem wichtig, werden aber anscheinend nicht durchgeführt von Conrad.

Das ist eine falsche Annahme. Beide Tests kannst du auch mit einem korrekt eingestellten Z-Min Schalter durchführen, mit einer Abstandslehre kann man den Abstand von Heizbett <-> Extruder schließlich auf zumindest 0,05 mm genau ermitteln.

Ok, hier habe ich vielleicht etwas übertrieben. Richtig ist, dass sich mit der entsprechenden Messpräzision die Bugs auch bei spezifikationsgemäßer Justage nachweisen lassen. Eben deswegen ist es ja ein Bug. Ich glaube, das von mir beschriebene Messverfahren ist aber dennoch einfacher, um die Problematik zu sehen. Der Umbau am Z-Schalter ist vergleichsweise einfach gegenüber einer auf 0.05mm genauen Messung bei Z>HEAT_BED_Z_COMPENSATION_MAX_STEPS. So oder so, die beschriebenen Tests wurden offensichtlich nicht oder nicht richtig durchgeführt, oder die dabei sichtbar gewordenen Probleme schlicht ignoriert bzw. auf Anforderungen an die Kalibrationsgenauigkeit abgewälzt. Gaaanz tolle Lösung...

Zusätzlich kann man sich die Z-Position auch im Display wahlweise auch "ab Heizbett" oder "ab Z-Min" anzeigen lassen und kann damit die Messung laut Abstandslehre kontrollieren. Falls du Interesse an unseren entsprechenden G-Codes dafür hast kann ich sie dir einmal zusammen mit dem Testablauf zusenden.

Die Frage ist, ob man der Anzeige vertrauen kann. Die basiert ja auch nur auf u.U. fehlerhaften Rechnungen. Wahrscheinlich kann man beide beschriebene Bugs aber auch da schon sehen, wenn man denn genau genug hinsieht und alles nachrechnet. Das wäre mir zu Mühsam...

Wir sind bei der Diskussion nun an dem Punkt angelangt wo wir grundsätzlich darüber übereinstimmen, dass die RF.01.31 die Höhe von den ersten Layern exakt so abfährt, wie der G-Code es will (und zwar unabhängig davon, ob dafür Z-Min überfahren werden muss oder nicht). Korrekt?

Ich glaube, dieser Punkt war nie ernsthaft strittig?

Diese Funktionalität wird durch FEATURE_Z_MIN_OVERRIDE_VIA_GCODE erreicht - wenn dieses Funktionalität aktiv ist kann G-Code den Z-Min Schalter überfahren. Z_OVERRIDE_MAX ist die daraus resultierende, notwendige Konsequenz die verhindert, dass der G-Code den Z-Min Schalter zu weit überfährt. Bis zu diesem Punkt ist es noch nicht relevant, ob die Z-Kompensation aktiv ist oder nicht, weil ich ja ein "G1 Z-10" jederzeit an die Firmware senden könnte ... und die Firmware muss das korrekt verarbeiten, ohne den Extruder durch das Heizbett zu stoßen.

Ich möchte nicht den ganzen Sermon noch zum 10. Mal wiederholen. Z_OVERRIDE_MAX verhindert nicht, dass der Extruder ins Heizbett fährt! Umgekehrt verhindert Z_OVERRIDE_MAX, dass der G-Code korrekt interpretiert wird, wenn die Justage von Z-Min nicht perfekt ist, und das stillschweigend! Das ist wie gesagt der zweite Bug. Und du gehst hier schon wieder nicht darauf ein!

Die nächste Evolutionsstufe wäre das Verhindern der Berührung zwischen Heizbett und Extruderspitze auf Basis der bekannten Heizbettmatrix.

Das ist die einzige Möglichkeit, diese Berührung zu verhindern!

Das wurde in diesem Schritt noch nicht umgesetzt weil:

- es unter normalen Bedingungen nicht auftreten kann (weil G-Code keine negativen Z-Positionen anfährt, Z-Min mechanisch korrekt eingestellt ist und die Firmware immer korrekt erkennt, ob Z-Min oder Z-Max ausgelöst ist)

Und wozu soll dann Z_OVERRIDE_MAX da sein? Wenn ihr der Meinung seid, dass dieses Sicherheitsfeature aktuell nicht nötig ist, schmeisst bitte Z_OVERRIDE_MAX raus! Es kann übrigens auch mit G-Codes, die nur positive Z-Positionen haben, passieren, wenn der Nutzer zu lange manuell mit den Pfeiltasten nach oben fährt. Von mir aus kann das unter Bedienfehler laufen, aber dann nehmt das falsche Z_OVERRIDE_MAX raus!

- dieser Schritt weitere Abhängigkeiten erzeugt, z.B. muss ja der Extruder potenziell auch bei X/Y-Bewegungen vom Heizbett weggefahren werden, um den gewünschten Sicherheitsabstand zu behalten

Nein, nein und nochmals nein! Wenn der G-Code zu einer Unterschreitung des Sicherheitsabstands führt, muss bedingungslos der Druck gestoppt werden! Es gibt nichts schlimmeres, als einen klaren Fehler dadurch zu "korrigieren", dass stillschweigend der nächst erlaubte Zustand verwendet wird. Wenn der G-Code so geschrieben ist, dass der Sicherheitsabstand unterschritten wird, ist der G-Code falsch und kann nicht gedruckt werden! Auch wenn Z_OVERRIDE_MAX den Schalter mechanisch schützen soll, gibt es wieder keinen Grund, dann weiterzudrucken aber das Objekt zu verhunzen. Da muss eine klare Fehlermeldung her!

- dieser Schritt unter manchen Umständen keine Verbesserung bringt, z.B. wenn die Heizbettmatrix nicht vorhanden oder falsch ist, wenn die Z-Kompensation nicht eingeschalten worden ist, wenn das Bett sehr schräg ist und die Geschwindigkeit in X/Y-Richtung sehr schnell ist, ...

Wenn der Scan ungültig ist, gibt es absolut keine Möglichkeit die Kollision zu verhindern. Dann muss eben ein Überfahren des Z-Schalters ganz unterbunden werden. Auch schon x-mal durchgekaut und x-mal von euch ignoriert
Klar, wenn das Bett sehr schräg ist, wird irgendwann die Kompensation zu ungau werden. Dann muss das Bett aber extrem schräg sein, und zwar mit dem blosen Auge sichtbar. Ich denke, es ist unstrittig, dass das kein erlaubter Benutzungszustand ist.
Was das mit der Geschwindigkeit in XY zu tun hat, überblicke ich gerade nicht. Falls die Korrektur in Z u.U. nicht schnell genug erfolgen kann, darf die Bewegung in XY halt nicht mit der Geschwindigkeit durchgeführt werden, sonst erfüllen wir ja wieder nicht die Geometrie, die der G-Code vorgibt.

Ist dir denn ein Scenario bekannt, bei dem es mit der RF.01.31 und einem korrekt (= laut Anleitung) eingestellten Z-Min Schalter zur Berührung zwischen Extruder und Heizbett kommen kann, ohne dass du die Z-Achse manuell bis zur Berührung nach oben fährst? Falls ja, können wir bitte den entsprechenden G-Code bekommen?

Jetzt mach ich mir extra die Mühe und schreibe ganz klar auf, wo die Bugs liegen, und dann liest du es nicht.... grrr.... Also noch mal:

• Das langsame "Ausschleichen" der Z-Kompensation (HEAT_BED_Z_COMPENSATION_MIN_STEPS/HEAT_BED_Z_COMPENSATION_MAX_STEPS -> schlechte Namen übrigens...) fährt nicht nur die Kompensation der Unebenheiten zurück sondern auch die Korrektur des mittleren Abstand zwischen Düse und Heizbett bei Z=0 (Z-Min-Schalter). Da dieser Abstand nie im Mittel 0 sein kann/darf (laut Bedienungsanleitung), führt dies zu falschen Objekthöhen.
• Das FEATURE_ENABLE_Z_SAFETY (=Z_OVERRIDE_MAX ??? Eure Namensgebung ist echt schwer nachzuvollziehen... Ich meinte hier Z_OVERRIDE_MAX) ist falsch umgesetzt und behindert u.U. stillschweigend die Z-Kompensation (nämlich dann, wenn das Limit greift). Umgekerht bietet es gerade keinen Schutz gegen Berühren von Düse und Heizbett. Dieses Feature ist zwar nicht explizit in der Produktbeschreibung erwähnt, man darf jedoch davon ausgehen, dass mit vernünftigem Aufwand umsetzbare Schutzmechanismen in einem Gerät dieser Preisklasse implementiert sind, und dass diese nicht den normalen Betriebsablauf unnötigerweise stören. Eine korrekte Implementierung würde aus der bekannten Vermessung des Heizbettes jeweils den wahren Abstand zwischen Heizbett und Düse berechnen und jeden Befehl, der zur Unterschreitung führen würde, verweigern. Dies darf auch nicht stillschweigend passieren sondern muss zu einem sofortigen Abbruch des Druckes führen.

Es geht mir nicht primär darum zu verhindern, dass die Berührung stattfinden kann. Ich will einfach nur anständig drucken können... Vielleicht kommt das Missverständnis daher, dass ich mich über die zugeschliffene Düse beschwert hatte. Die Situation war hier aber eben, dass Z_OVERRIDE_MAX verhindert hat, dass die Bewegung wegen zu großen Drucks gestoppt wurde. Ein weiterer unangenehmer Nebeneffekt von Z_OVERRIDE_MAX, aber hier eher nicht Gegenstand der Diskussion!

[Zaldo]

In letzter Konsequenz fragt man bevor man einen Schrittbefehl an den Motor in Z-Minus Richung abgibt ab, ob besagte Variable noch schritte in dieser Richtung zulässt, und wenn nicht, führt man die Bewegung nicht aus.

Reicht nicht! Man kann auch mit einer reinen XY-Bewegung den Sicherheitsabstand unterschreiten!

Falsch, da hier die Z-Kompensation die Höhe nachführt. Das könnte lediglich bei ausgeschalteter Kompensation ein Problem werden. Drum bin ich ja auch der Meinung, dass auch wenn die Kompensation überhaupt nicht benutzt werden soll, ein HBS trotzdem obligatorisch sein muß, nicht kompensieren schließt ja nicht zwangsläufig aus, dass der Drucker nicht trotzdem wissen kann, wo er ist und wieviel Futter er noch hat. Und wenn Du meinen UP zum Thema Z Logik gelesen hast, weisst Du das (wie auch heute schon) bei ausgeschalteter Kompensation Z=0 dem Auslösepunkt des oberen Schalters entsprechen solle, bei korrekter Einstellung also 0,5mm. Und bei diesem Abstand kanst Du eben nicht mit einer reinen X/Y Bewegung ins Bett fahren, es sei denn, du hast irgendwas grob falsch zusammengebaut.

Aber darum ging es mir garnicht, es ging mir bei diesem Feature darum Firmwarefehlerbedingte Z-Fehlsteuerungen, wie das versehentliche Fahren in die falsche Richtung, auf unterster Ebene abzufangen.

Ähm, Ich wollte nix mehr dazu sagen.

[RF1000]

Wenn Z_OVERRIDE_MAX so groß wäre, dass lediglich der Z-Min-Schalter mechanisch geschützt wäre, könnte ich das ja noch verstehen. Es ist aber meines Wissens bei 0.5mm, was die obere Grenze für den laut Handbuch zugelassenen Abstand zwischen Düse und Heizbett bei der Kalibration ist. Dazu kann dann aber noch Unebenheit des Heizbetts kommen!

Und davon weg kommt dann noch die Höhe vom 1. Layer. Ich habe es an einer anderen Stelle schon geschrieben und ich denke es ist nachvollziehbar, dass man gute Ergebnisse mit kleinen Layerhöhen (also z.B. 0,1 mm für den 1. Layer, was doch eher untypisch klein ist) nur dann erreichen kann wenn man auch Z-Min sorgfältig eingestellt hat. Eine Layerhöhe von 0,1 mm in Kombination mit einem sehr schrägen/unebenen Bett (dZ z.B. 0,5 mm) kann auch nicht so gute Ergebnisse liefern wie der gleiche G-Code mit einem sehr geraden/ebenen Bett (dZ z.B. 0,1 mm).

Die Frage ist, ob man der Anzeige vertrauen kann. Die basiert ja auch nur auf u.U. fehlerhaften Rechnungen.

Also die Anzeige im Modus "Surface" kann man doch ganz einfach mit der Abstandslehre kontrollieren. Für den Abstand ab "Z-Min" muss man natürlich rechnen, mit den in der Firmware vorhandenen Debugausgaben ist aber auch das kein Hexenwerk. Und wir haben uns diese Mühe natürlich gemacht.

Wir sind bei der Diskussion nun an dem Punkt angelangt wo wir grundsätzlich darüber übereinstimmen, dass die RF.01.31 die Höhe von den ersten Layern exakt so abfährt, wie der G-Code es will (und zwar unabhängig davon, ob dafür Z-Min überfahren werden muss oder nicht). Korrekt?

Ich glaube, dieser Punkt war nie ernsthaft strittig?

Das freut mich

Und wozu soll dann Z_OVERRIDE_MAX da sein?

Das habe ich bereits beschrieben:

Diese Funktionalität wird durch FEATURE_Z_MIN_OVERRIDE_VIA_GCODE erreicht - wenn dieses Funktionalität aktiv ist kann G-Code den Z-Min Schalter überfahren. Z_OVERRIDE_MAX ist die daraus resultierende, notwendige Konsequenz die verhindert, dass der G-Code den Z-Min Schalter zu weit überfährt. Bis zu diesem Punkt ist es noch nicht relevant, ob die Z-Kompensation aktiv ist oder nicht, weil ich ja ein "G1 Z-10" jederzeit an die Firmware senden könnte ... und die Firmware muss das korrekt verarbeiten, ohne den Extruder durch das Heizbett zu stoßen.

Ohne dem Limit von Z_OVERRIDE_MAX würde ein "G1 Z-10" zur Kollision führen. Das ist die letzte zur Verfügung stehende Verteidigungslinie, wenn die Z-Matrix nicht vorhanden, nicht aktiv oder nicht korrekt ist.

Umgekehrt verhindert Z_OVERRIDE_MAX, dass der G-Code korrekt interpretiert wird, wenn die Justage von Z-Min nicht perfekt ist, und das stillschweigend! Das ist wie gesagt der zweite Bug. Und du gehst hier schon wieder nicht darauf ein!

Ich bin darauf eingegangen, ich habe geschrieben:

Ist dir denn ein Scenario bekannt, bei dem es mit der RF.01.31 und einem korrekt (= laut Anleitung) eingestellten Z-Min Schalter zur Berührung zwischen Extruder und Heizbett kommen kann, ohne dass du die Z-Achse manuell bis zur Berührung nach oben fährst? Falls ja, können wir bitte den entsprechenden G-Code bekommen?

Und um es gleich vorweg zu nehmen: Ja, ich bestätige, wenn man Z-Min außerhalb des vom Handbuch geforderten Toleranzbereichs eingestellt hat dann kann es sein, dass das Druckergebnis nicht dem entspricht, was man sich erhofft. Die Abhilfe ist in diesem Fall, Z-Min so einzustellen wie es im Handbuch beschrieben ist.

Und wozu soll dann Z_OVERRIDE_MAX da sein? Wenn ihr der Meinung seid, dass dieses Sicherheitsfeature aktuell nicht nötig ist, schmeisst bitte Z_OVERRIDE_MAX raus!

Und was soll dann deiner Meinung nach passieren, wenn ich ein "G1 Z-10" zum RF1000 sende?

Es kann übrigens auch mit G-Codes, die nur positive Z-Positionen haben, passieren, wenn der Nutzer zu lange manuell mit den Pfeiltasten nach oben fährt. Von mir aus kann das unter Bedienfehler laufen, aber dann nehmt das falsche Z_OVERRIDE_MAX raus!

Z_OVERRIDE_MAX berücksichtigt jede Bewegung in Z-Richtung, egal ob sie vom G-Code, von der Z-Kompensation, von M3006 oder von den Hardwaretasten kommt. Niemand kann Z-Min um mehr als Z_OVERRIDE_MAX überfahren. Warum sollte es eine Verbesserung sein, dass ich mit den Hardwaretasten Z-Min beliebig überfahren kann?

Nein, nein und nochmals nein! Wenn der G-Code zu einer Unterschreitung des Sicherheitsabstands führt, muss bedingungslos der Druck gestoppt werden! Es gibt nichts schlimmeres, als einen klaren Fehler dadurch zu "korrigieren", dass stillschweigend der nächst erlaubte Zustand verwendet wird. Wenn der G-Code so geschrieben ist, dass der Sicherheitsabstand unterschritten wird, ist der G-Code falsch und kann nicht gedruckt werden! Auch wenn Z_OVERRIDE_MAX den Schalter mechanisch schützen soll, gibt es wieder keinen Grund, dann weiterzudrucken aber das Objekt zu verhunzen. Da muss eine klare Fehlermeldung her!

Hast du ein Beispiel (Heizbettmatrix + G-Code), wo dieser Mechanismus greifen würde?
Ich werde diesen Vorschlag intern diskutieren, zumindest eine Warnung im Display (ohne Abbruch vom Druck) könnte sinnvoll sein. Die Annahme ist ja weiterhin, dass diese Meldung unter normalen Umständen nicht ausgelöst werden kann. Von mir aus könnte man auch in den Sourcen wählen, ob diese Meldung nur eine Warnung ist oder auch wirklich den Druck beendet.

Wenn der Scan ungültig ist, gibt es absolut keine Möglichkeit die Kollision zu verhindern.

Der Scan könnte auch gültig sein, wenn danach etwas mechanisch verändert worden ist (anderes Heizbett, Heizbett anders montiert, Auslösepunkt von Z-Min verändert, ...) dann kann sich die Firmware genausowenig auf die Matrix verlassen. Von daher gibt es mit Z_OVERRIDE_MAX eben ein Limit, das zwar niemals erreicht werden sollte, welches als letzte Verteidigungslinie aber eben doch die Z-Bewegung stoppt.

Klar, wenn das Bett sehr schräg ist, wird irgendwann die Kompensation zu ungau werden. Dann muss das Bett aber extrem schräg sein, und zwar mit dem blosen Auge sichtbar. Ich denke, es ist unstrittig, dass das kein erlaubter Benutzungszustand ist.

Jein. Du hast so eine Konfiguration für deinen Test 2 vorgeschlagen.
Beim Fräsen wäre z.B. eine "runde" Oberfläche mit mehreren mm Höhenunterschied möglich und kann z.B. zum Gravieren dieser "runden" Oberfläche verwendet werden. Beim Drucken würden so große Unterschiede zu deutlichen Kompensationsbewegungen führen, die sich natürlich auch im gedruckten Objekt niederschlagen und kaum erwünscht sind.

Was das mit der Geschwindigkeit in XY zu tun hat, überblicke ich gerade nicht. Falls die Korrektur in Z u.U. nicht schnell genug erfolgen kann, darf die Bewegung in XY halt nicht mit der Geschwindigkeit durchgeführt werden, sonst erfüllen wir ja wieder nicht die Geometrie, die der G-Code vorgibt.

Die Z-Kompensation wird nicht vorausgeplant, die Firmware ermittelt ständig die aktuelle X/Y-Position und die dort notwendigen Schritte zur Z-Korrektur. Diese Korrektur ist ja nicht über die gesamte X/Y-Bewegung linear. Von daher kann auch die Geschwindigkeit der gesamten Bewegung nicht im Vornhinein an die notwendige Z-Korrektur angepasst werden.

Ich will einfach nur anständig drucken können

Und ich will einfach nur ein konkretes Beispiel (Heizbettmatrix + G-Code), wo du das mit der RF.01.31 nicht kannst.

Ähm, Ich wollte nix mehr dazu sagen.

Auch wenn wir nicht immer derselben Meinung sind und die Diskussion ab und zu von der eigentlichen Thematik abdriftet freue ich mich trotzdem, dass du dich weiterhin daran beteiligst


mfG
RF1000

[rf1k_mjh11]

Ich gebe auch meinen Senf dazu:

....
Ich werde diesen Vorschlag intern diskutieren, zumindest eine Warnung im Display (ohne Abbruch vom Druck) könnte sinnvoll sein. Die Annahme ist ja weiterhin, dass diese Meldung unter normalen Umständen nicht ausgelöst werden kann. Von mir aus könnte man auch in den Sourcen wählen, ob diese Meldung nur eine Warnung ist oder auch wirklich den Druck beendet.
....

Guter Vorschlag. Und wenn die Standardeinstellung 'nur' die Warnung ist, ändert sich für den normalen Benutzer nichts und das Verhalten wäre beinahe wie bisher.

mjh11

[mhier]

Irgendwie verstehe ich nicht, wie ein Firmware-Entwickler (das bist du doch?) das Problem nicht sehen kann... Ich konzentrieren mich mal auf das Wesentliche, sonst kommen wir nicht vorwärts (sorry, wenn ich deswegen jetzt nicht auf alles eingehen kann):

Ohne dem Limit von Z_OVERRIDE_MAX würde ein "G1 Z-10" zur Kollision führen. Das ist die letzte zur Verfügung stehende Verteidigungslinie, wenn die Z-Matrix nicht vorhanden, nicht aktiv oder nicht korrekt ist.

Mit dem Limit von Z_OVERRIDE_MAX fürt der Befehl auch zur Kollision!

Ist dir denn ein Scenario bekannt, bei dem es mit der RF.01.31 und einem korrekt (= laut Anleitung) eingestellten Z-Min Schalter zur Berührung zwischen Extruder und Heizbett kommen kann, ohne dass du die Z-Achse manuell bis zur Berührung nach oben fährst? Falls ja, können wir bitte den entsprechenden G-Code bekommen?

Laut Anleitung soll ich den Abstand zwischen Düse und Heizbett auf irgendwas zwischen 0.2 und 0.5mm einstellen, richtig? Wie kommst du darauf, dass Z_OVERRIDE_MAX=0.5mm dann eine Kollision verhindert?

Und um es gleich vorweg zu nehmen: Ja, ich bestätige, wenn man Z-Min außerhalb des vom Handbuch geforderten Toleranzbereichs eingestellt hat dann kann es sein, dass das Druckergebnis nicht dem entspricht, was man sich erhofft. Die Abhilfe ist in diesem Fall, Z-Min so einzustellen wie es im Handbuch beschrieben ist.

Hier kommen die wichtigesten Punkte:

• Das Druckergebnis ist auch dann nicht das gewünschte, wenn ich alles innerhalb der vom Handbuch geforderten Toleranzen einstelle! Das Objekt wird schlicht in der Höhe um 0.2 bis 0.5mm falsch!
• Sobald ich bei der Justage den Toleranzbereich auch nur ein wenig verlasse (evtl. sogar davor, wenn der 1. Layer eher dünn ist - nirgendwo im Handbuch steht, dass das nicht erlaubt ist, oder?), führt Z_OVERRIDE_MAX=0.5mm dazu, dass die Z-Kompensation teilweise nicht mehr korrekt durchgeführt wird.
• Die im Handbuch geforderten Toleranzen sind unnötig klein. Mechanisch wären größere Tolerazen problemlos möglich. Die Firmware rechnet nur nicht korrekt, deshalb würden größere Toleranzen zu größeren Fehlern im Druck-Ergebnis führen.
• Die geforderten Toleranzen einzuhalten ist nicht ganz einfach. Letztlich geht es nur, wenn man nach jedem Filament- oder Düsenwechsel Z-Min für die jeweilige Temperatur neu einstellt. Nochmal: der Grund für die niedrigen Toleranzen sind ausschließlich Probleme in der Software, die Hardware kann erheblich mehr!

Und ich will einfach nur ein konkretes Beispiel (Heizbettmatrix + G-Code), wo du das mit der RF.01.31 nicht kannst.

Ich hab dir sehr konkrete Beispiele genannt, wo es falsch läuft. Entweder liest du meine Posts nicht richtig, oder du suchst nur nach einer Ausrede, das von mir beschriebene Verhalten wieder auf eine Justage zu schieben, die nicht im erlaubten Toleranzbereich liegt. Langsam glaube ich, du versuchst dich nur rauszureden, und das macht mich wahnsinnig. Was ich beschreibe, habe ich größtenteils aus deinen Aussagen und Beschreibungen abgeleitet (und meinen Beobachtungen). Ich brauche keine konkrete Heizbettmatrix und einen G-Code um zu wissen, dass die Objekthöhe falsch wird. Du hast das selbst gesagt und aus dem Source-Code geht es auch hervor.

Also was soll das? Auch dass die Z-Kompensation in ihrer Arbeit behindert wird, wenn sie mal mehr als Z_OVERRIDE_MAX kompensieren soll, ist doch eine völlig logische Folge. Wozu brauchst du da Code? Ja, das betrifft vor allem Kalibrationen (knapp) außerhalb dessen, was nach Handbuch zulässig wäre, aber nenn mir einen mechanischen Grund, warum das nicht gehen sollte? Selbst der Original-Z-Schalter hat problemlos 1mm mitgemacht. Das würde die Kalibration soooo viel einfacher machen! Wahrscheinlich wären viele ihre Haftungssorgen los! Also warum macht ihr das nicht anständig? Wollt ihr eure Kunden ärgern? Ich versteh es nicht! Wir reden über nen halben Tag Arbeit! Wahrscheinlich diskutieren wir schon länger da drüber! Wenn ihr mal endlich das be**** Repository anständig machen würdet, würde ich es ja selbst machen (und euch zur Verfügung stellen)!

[rf1k_mjh11]

mhier,

Ich bin kein Programmierer. Aber eines kann ich zu der folgenden Aussage hinzufügen:

....
Hier kommen die wichtigesten Punkte:

• Das Druckergebnis ist auch dann nicht das gewünschte, wenn ich alles innerhalb der vom Handbuch geforderten Toleranzen einstelle! Das Objekt wird schlicht in der Höhe um 0.2 bis 0.5mm falsch!
• ....

....
Ich brauche keine konkrete Heizbettmatrix und einen G-Code um zu wissen, dass die Objekthöhe falsch wird.
...

Ich brauche auch keine HBS-Matrix, ja nicht einmal einen Drucker, dass die Objekthöhe falsch wird. Das macht bei mir schon der Slicer (Slic3r). Nehme ich, zum Beispiel, ein Objekt mit 2.91mm Höhe und slice es mit einer Layerhöhe von 0.4mm (für meine 0.6mm Düse), kommt zum Schluss eine Objekthöhe von 3.2mm heraus - ein Zuwachs von 0.29mm! Mit oder ohne Z-Kompensation. In so einem Fall nützt eine perfekte FW nichts. Ob Cura, KissSlicer, S3D, oder andere Slicer das besser können, weiß ich nicht.

Die Zehnprozenthürde

---

Falls das niemandem aufgefallen ist, das sind beinahe 10% Zuwachs.

Aber - Alex, der Entwickler von Slic3r, hat die GitHub-Sache recht gut im Griff. Du könntest ihm den Vorschlag machen, dass das letzte Layer immer zur genauen Objekthöhe führt (Pull Request, oder ähnlich, heißt es). Man muss bloß beim letzten Layer die Höhe entsprechend ändern und die Extrusionsraten extra ausrechnen - oder noch einfacher, mittels M221 einmalig am Anfang des letzten Layers anpassen (klappt bei den wichtigsten Firmware-Variationen).

Auch wenn Conrad die Repository nicht ordentlich macht ...

Wenn ihr mal endlich das be**** Repository anständig machen würdet, würde ich es ja selbst machen (und euch zur Verfügung stellen)!

... sollte das dich nicht daran hindern, RF1000 deinen Code zukommen zu lassen.

mjh11

[mhier]

Hallo rf1k_mjh11,

du sprichst ein ganz anderes Thema an hier, Ungenauigkeiten im Slicer habe nichts damit zu tun, dass der Drucker nicht die im G-Code angegebene Höhe anfährt. Das kommt dann noch dazu! (Generell gilt natürlich, dass definitionsgemäß bei 0.4mm Layerhöhe die Objekthöhe ein ganzzahliges Vielfaches von 0.4mm haben muss. Die Frage ist in deinem Fall nur, warum wird das Objekt nicht 2.8mm hoch, das wäre näher an der gewünschten Höhe. Ich drucke aktuell mit 0.05mm Layerhöhe, weil ich eben eine deutlich bessere Maßhaltigkeit brauche. Das ist offiziell von Conrad unterstützt!)

Auch wenn Conrad die Repository nicht ordentlich macht ...

Wenn ihr mal endlich das be**** Repository anständig machen würdet, würde ich es ja selbst machen (und euch zur Verfügung stellen)!

... sollte das dich nicht daran hindern, RF1000 deinen Code zukommen zu lassen.

Mich hindert, dass ich Zeit investieren muss, ohne Garantie, dass Conrad es einbaut. Wenn sie es nicht tun, muss ich jedesmal erheblich Zeit investieren muss, wenn Conrad wieder ein Update rausbringt, oder meinen Änderung wegwerfen. Dafür ist mir meine Zeit zu schade. Vor allem, wenn man bedenkt, dass ich über 2000 EUR für den Drucker ausgegeben habe! Da sollte so etwas nicht nötig sein!

[RF1000]

Ohne dem Limit von Z_OVERRIDE_MAX würde ein "G1 Z-10" zur Kollision führen. Das ist die letzte zur Verfügung stehende Verteidigungslinie, wenn die Z-Matrix nicht vorhanden, nicht aktiv oder nicht korrekt ist.

Mit dem Limit von Z_OVERRIDE_MAX fürt der Befehl auch zur Kollision!

Ja natürlich, dieser Befehl muss zwangsläufig zur Kollision führen. Aber es ist ein Unterschied, ob die Kollision 0,5 mm (= Z_OVERRIDE_MAX) nach Z-Min oder 10 mm (= was der G-Code will) endet. Nochmal: Dieser Mechanismus ist vorhanden und muss funktionieren egal, ob die Z-Kompensation ein oder aus ist (ergo auch bei nicht vorhandener oder nicht gültiger Z-Matrix).
Er würde auch greifen, wenn du

• G28 Z0 ; home Z
  G1 Z1 ; fahre Z auf 1,0 mm
  ... fahre Z per Hardware Taster um 0,9 mm nach oben, d.h. Z steht auf einer Position 0,1 mm vor dem Auslösen von Z-Min ...
  G1 Z0.1 ; fahre Z auf 0,1 mm ... ohne weitere Maßnahmen würde das eine Bewegung um 0,9 mm nach oben, also 0,8 mm nach dem Auslösepunkt von Z-Min ausführen ... aufgrund von Z_OVERRIDE_MAX stoppt die Bewegung aber 0,5 mm nach dem Auslösepunkt von Z-Min

ausführen würdest. Und das ist ein real mögliches Beispiel ohne negative G-Codes, dem man in ähnlicher Form auch in der freien Wildbahn begegnen kann.

Ist dir denn ein Scenario bekannt, bei dem es mit der RF.01.31 und einem korrekt (= laut Anleitung) eingestellten Z-Min Schalter zur Berührung zwischen Extruder und Heizbett kommen kann, ohne dass du die Z-Achse manuell bis zur Berührung nach oben fährst? Falls ja, können wir bitte den entsprechenden G-Code bekommen?

Laut Anleitung soll ich den Abstand zwischen Düse und Heizbett auf irgendwas zwischen 0.2 und 0.5mm einstellen, richtig? Wie kommst du darauf, dass Z_OVERRIDE_MAX=0.5mm dann eine Kollision verhindert?

Ich komme da drauf weil ich denke, dass die von dir beschriebene theoretische Kollision in der Praxis nicht auftritt. Vielleicht habe ich auch einen Knoten zu viel im Gehirn deswegen wäre ich dir sehr dankbar, wenn du mir mit einem echten, nachvollziehbaren Beispiel aus der Patsche helfen könntest. Du musst es auch nicht selbst ausprobieren wenn du das deiner Hardware nicht antun willst. Die folgenden Schritte führen nicht zur Kollision, was muss ich anders machen, um doch eine hinzubekommen?

• - Ausgangslage:
  • - Z-Min löst ca. 0,4 mm über dem höchsten Punkt vom Heizbett aus, wenn sowohl Heizbtt als auch Extruder die Drucktemperatur haben.
    - Das Heizbett wurde mit dem PLA oder ABS Modus vom Heizbettscan erfolgreich abgetastet.
  - Drucker einschalten.
  - Druck starten (egal ob via Repetier-Host oder SD Karte). M3006 muss im G-Code nicht enthalten sein (bzw. kann als "M3006 S0" vorhanden sein).
  - Ergebnis:
  • - Der Druck startet.
    - Der Druck wird ausgeführt, die Höhe vom ersten Layer passt automatisch. Über die Hardwaretaste könnte man Z leicht nach oben oder unten bewegen (eine Bewegung über mehr als eine Layerhöhe würde ja bedeuten, dass entweder die Mechanik nicht stimmt oder die Heizbettmatrix).
    - Der Druck wird erfolgreich beendet.

Das Druckergebnis ist auch dann nicht das gewünschte, wenn ich alles innerhalb der vom Handbuch geforderten Toleranzen einstelle! Das Objekt wird schlicht in der Höhe um 0.2 bis 0.5mm falsch!

Richtig. +/- eine falsche Höhe aufgrund von dem, was der Slicer aus der Objekthöhe und der Höhe der einzelnen Layer macht +/- eine falsche Höhe aufgrund dessen, wie stark sich dein Material beim Abkühlen zusammenzieht oder ausdehnt.

Sobald ich bei der Justage den Toleranzbereich auch nur ein wenig verlasse (evtl. sogar davor, wenn der 1. Layer eher dünn ist - nirgendwo im Handbuch steht, dass das nicht erlaubt ist, oder?), führt Z_OVERRIDE_MAX=0.5mm dazu, dass die Z-Kompensation teilweise nicht mehr korrekt durchgeführt wird.

Falsch. Die Z-Kompensation kann Z-Min auch um mehr als Z_OVERRIDE_MAX überfahren. Das habe ich im vorangegangenen Post im Eifer des Gefechts falsch beschrieben. Z_OVERRIDE_MAX verhindert also "nur", dass man Z-Min per G-Code oder über die Hardwaretaster um mehr als 0,5 mm überfährt.

Die im Handbuch geforderten Toleranzen sind unnötig klein. Mechanisch wären größere Tolerazen problemlos möglich. Die Firmware rechnet nur nicht korrekt, deshalb würden größere Toleranzen zu größeren Fehlern im Druck-Ergebnis führen.

Das ist ein anderer Text für das Gleiche wie bei deinem Punkt 1. Die Firmware berechnet die Objekthöhe bisher ab Z-Min. Ungeachtet dessen sind die Standardschalter nun mal nicht für beliebig weites Überfahren gedacht und das Einstellen von Z-Min entsprechend den Toleranzen vom Handbuch ist a) einfach möglich und b) typischerweise kein Vorgang, den man oft ausführen muss.
Und der Vollständigkeit halber: Wenn man anstelle von Z-Min einen anderen Referenzpunkt verwenden würde dann könnte die Höhe vom gedruckten Objekt immer noch anders sein als erwünscht, z.B. wenn der Referenzpunkt vorne links wäre, das Objekt auf einem eher kleinen Bereich hinten rechts gedruckt wird und zwischen diesen beiden Flächen ein Höhenunterschied von z.B. 0,2 oder 0,3 mm wäre. Das würde dann daher kommen, dass die Firmware ja den zu bedruckenden Bereich vor dem Start vom Druck nicht kennt und der Referenzpunkt dann eben auch 0,2 oder 0,3 mm weg von der eigentlich verwendeten Heizbettoberfläche wäre.

Die geforderten Toleranzen einzuhalten ist nicht ganz einfach. Letztlich geht es nur, wenn man nach jedem Filament- oder Düsenwechsel Z-Min für die jeweilige Temperatur neu einstellt. Nochmal: der Grund für die niedrigen Toleranzen sind ausschließlich Probleme in der Software, die Hardware kann erheblich mehr!

Das sehe ich nicht ganz so. Du kannst mit der RF.01.31 bis zu 9 Heizbettmatrizen abspeichern. D.h. wenn du 9 verschiedene Materialen mit 9 verschiedenen Temperatureinstellungen verwendest dann könntest du 9 Scans mit diesen 9 Temperatureinstellungen machen und jeder Druckvorgang sollte dann ohne jede manuelle Z-Korrektur automatisch die Höhe vom 1. Layer korrekt rauswerfen (sofern im G-Code die entsprechende Z-Matrix als Basis für die Z-Korrektur geladen wird).
Ein Düsenwechsel ist ein anderes Thema, das ist ja eine wirkliche Änderung der Hardware, die die Firmware bisher nicht erkennen kann. Mögliche Ansätze für solche Szenarien haben wir auch bereits schon durchgesprochen, sie werden aber nicht Teil vom kommenden Masterstand sein.

Und ich will einfach nur ein konkretes Beispiel (Heizbettmatrix + G-Code), wo du das mit der RF.01.31 nicht kannst.

Ich hab dir sehr konkrete Beispiele genannt, wo es falsch läuft. Entweder liest du meine Posts nicht richtig, oder du suchst nur nach einer Ausrede, das von mir beschriebene Verhalten wieder auf eine Justage zu schieben, die nicht im erlaubten Toleranzbereich liegt. Langsam glaube ich, du versuchst dich nur rauszureden, und das macht mich wahnsinnig. Was ich beschreibe, habe ich größtenteils aus deinen Aussagen und Beschreibungen abgeleitet (und meinen Beobachtungen). Ich brauche keine konkrete Heizbettmatrix und einen G-Code um zu wissen, dass die Objekthöhe falsch wird. Du hast das selbst gesagt und aus dem Source-Code geht es auch hervor.

Du vermischt jetzt Dinge. Ich wollte ein konkretes Beispiel dafür, dass Z_OVERRIDE_MAX eine Kollision im Normalbetrieb nicht verhindert hat oder dass es dazu geführt hat, dass die Höhe vom 1. Layer nicht passt.

Auch dass die Z-Kompensation in ihrer Arbeit behindert wird, wenn sie mal mehr als Z_OVERRIDE_MAX kompensieren soll, ist doch eine völlig logische Folge.

Wie oben beschrieben habe ich das in einem vorherigen Post leider falsch beschrieben. Z_OVERRIDE_MAX verhindert nicht die Arbeit der Z-Kompensation.

Das würde die Kalibration soooo viel einfacher machen!

Wenn du das so siehst dann gehe ich davon aus, dass du als "Kalibration" den Z-Min Schalter einfach auf Sicht so ungefähr einstellen willst. Das ist natürlich etwas einfacher als mal kurz ein Blatt Papier für die Kalibration aufzutreiben und dieses zwischen Heizbett und Extruder zu stecken. Aber wir stimmen vermutlich darüber ein, dass a) die Sache mit dem Papier nicht soooo viel schwieriger ist, b) bei deiner geplanten Vorgangsweise früher oder später der Schlendrian dazu führt, dass die "Kalibration" einfach nicht gut ist und c) die bisher festgelegte Vorgehensweise für die Hardware die schonendere ist. b) deswegen, weil du "auf Sicht" keine Toleranz einhalten wirst und wenn man bei b) nicht "auf Sicht" sondern mit einem Abstand (z.B. Papier) zwischen Heizbett und Extruder arbeiten würde, ja wieder genau das gleiche macht wie bei der bisher festgelegten Vorgehensweise.

Wahrscheinlich wären viele ihre Haftungssorgen los!

Vielleicht wäre es einmal interessant eine Umfrage zu starten, wer konkret welche Haftungsprobleme hat. An neuen Beiträgen ist zum Thema "Haftung" in den letzten Wochen/Monaten ja eher nicht viel gekommen. Ungeachtet dessen gilt ja, dass deine Annahme ja auf meiner falschen Aussage zum Thema Z_OVERRIDE_MAX und Z-Kompensation basiert ... oder anders, uns sind mit der RF.01.31 im Normalbetrieb bisher keine Haftungsprobleme bekannt.

Wenn ihr mal endlich das be**** Repository anständig machen würdet, würde ich es ja selbst machen (und euch zur Verfügung stellen)!

Das Repository ist bisher eine Veröffentlichungsplattform und in der Form noch nicht ideal für die Cross-Plattform Entwicklung geeignet. Das ist ein offener Punkt, der immer noch auf unserer Liste steht, allerdings mit bisher eher geringer Priorität. Was genau ist dieses "es", das du selber machen willst? Ich denke ich kann dir anbieten, dass du "es" machst, uns zusendest und wir uns dann gemeinsam ansehen, inwieweit das Verhalten deiner Modifikation sich von der RF.01.31 unterscheidet.


mfG
RF1000