Der HBS mit v RF.01.11 läuft bei mir problemlos durch. Sowol kalt als auch im warmen Zustand.

Logs sind im Anhang zum vergleich.

Neuerlicher HBS fertig.

Ergebnis wieder ähnlich der vielen vorhergegangenen Scans: Leichte Unterschiede gab es beim Offsetwert (ich hatte nur 216° statt 232° dieses Mal - Folge der Extruderlängung?). Auch der Unterschied zwischen dem höchsten und niedrigsten Punkt hat sich leicht geändert - keine Panik, ist bloß eine Folge der thermischen Ausdehnung und Verwerfungen die da stattfinden.

Test erfolgreich - Bug meinerseits nicht bestätigt.

mjh11

(Jetzt wieder zurück zur 0.91.51....)

Hallo zusammen

Danke für eure Arbeit und testen der Firmware.

Nachdem ich gestern beim ersten Versuch die Logdateien zu generieren, den EEPROM-Wert nicht geändert hatte, gab es keine Ausgabe und direkt einen Abruch beim Scan (allerdings keine Logdatei).
Der Nächste Start war dann erfolgreich, die Log-Daten wurden nach Repetier übertragen und egal was ich machte der Scan klappte immer.
Keine Verzögerung beim Start von manchmal 30 Sekunden, direkte Ausführung und plausible Daten, kein undefiniertes Motorbrummen.
Dann Grafiken generiert (Danke an Jens für das Script zur Erzeugung der Grafiken).
Irgendwie stand alles schief, entweder meine Fehlversuche beim Scannen oder die Einschläge des Druckbettes auf die untere Lichtschranke (die sich dadurch erfolgreich zerlegt hatte, allerdings schon letzte Woche).
Alles neu ausgerichtet und für eine genauere Analyse der Höhenunterschiede ein paar Excelblätter erstellt (Datei angehängt).
Scan gemacht und brauchbare Druckergebnisse bekommen, allerdings noch einen Tick zu hoch. Nachdem den Z-Schalter gestern noch nachgesetzt habe, könnte man nochh einen neuen Scan machen (Z-Abstand von 0,5 auf ca. 0,3 mm reduziert).
Logdatei mitgeschnitten, der Anfang direkt sehr laut, die X-Achse in starken Schwingungen mit lautem Motorgeräusch und Erschütterungen auch im Bett, aber egal wird schon gehen.
Nein, in der zweiten Reihe Abruch, die Digitzahl stieg auf ca. 16000, heftige Geräusche, dann NOT-AUS gedrückt.
F-Digit Wert steht jetzt dauerhaft bei -4837. Die einzige Änderung ist die Höhe des Ref-Schalter Z von 0,5mm auf 0,3mm.

Ich dachte schon ich hätte Halluzinationen, jetzt habe ich belegende Log-Dateien aber vermutlich sind die/der DMS-Kraftaufnehmer geschrottet.
Gruß Frank

RF1000 hat geschrieben:Korrekt. Wobei man natürlich Z-Min trotzdem unbedingt so einstellen sollte, dass der Extruder beim Auslösen von Z-Min noch nirgends das Bett berühren kann. Ansonsten könnte man ja mit X/Y-Bewegungen nach dem Z-Homing jederzeit eine (sehr, sehr unerwünschte) Kollision "erzeugen".

Drum hatte ich ja (im Rahmen des anderen Threads wo ich leider nichts mehr von Dir gehört hatte) angemerkt, dass im Rahmen des HBS zwar Z=0 als Definition für den Abstand Extruder_auf_Bett angenommen werden sollte, bei Fahrbefehlen der Extruder aber niemals näher als die minimale Z-Druckerauflösung (0,05mm oder ein entsprechend änderbares #define) kommen dürfen sollte.

Zaldo hat geschrieben:

RF1000 hat geschrieben: Korrekt. Wobei man natürlich Z-Min trotzdem unbedingt so einstellen sollte, dass der Extruder beim Auslösen von Z-Min noch nirgends das Bett berühren kann. Ansonsten könnte man ja mit X/Y-Bewegungen nach dem Z-Homing jederzeit eine (sehr, sehr unerwünschte) Kollision "erzeugen".

Drum hatte ich ja (im Rahmen des anderen Threads wo ich leider nichts mehr von Dir gehört hatte) angemerkt, dass im Rahmen des HBS zwar Z=0 als Definition für den Abstand Extruder_auf_Bett angenommen werden sollte, bei Fahrbefehlen der Extruder aber niemals näher als die minimale Z-Druckerauflösung (0,05mm oder ein entsprechend änderbares #define) kommen dürfen sollte.

Man kann sich viel überlegen, was die Firmware sinnvolles tun könnte wenn die richtige Heizbettmatrix bekannt und die Z-Kompensation eingeschalten ist. Trotzdem darf der Extruder beim Auslösen von Z-Min nirgends das Bett berühren, weil es damit diverse Möglichkeiten gibt, die zur Kollision führen können - z.B.:
- Der Auslösepunkt von Z-Min wurde nach dem Heizbettscan verändert.
- Die Heizbettmatrix ist nicht vorhanden (weil noch kein erfolgreicher Scan durchgeführt worden ist).
- Die Heizbettmatrix ist nicht aktuell (weil nach einer mechanischen Änderung kein erfolgreicher Scan mehr durchgeführt worden ist).
- Die Z-Kompensation ist nicht eingeschalten.
- ...

Alle diese Möglichkeiten kann der Anwender natürlich verhindern, aber die Firmware kann nicht davon ausgehen, dass er das auch immer tut/getan hat. Daher gilt auf jeden Fall, dass der Extruder beim Auslösen von Z-Min nirgends das Bett berühren darf.
Einige der angeführten Möglichkeiten können natürlich auch jetzt schon zur Kollision führen, z.B. wenn der Anwender den Auslösepunkt von Z-Min nach dem Heizbettscan verändert, ohne danach einen neuen Scan durchzuführen - in dem Fall würde die Firmware mit dem falschen Abstand arbeiten und eine Kollision ist ebenso möglich. Das wäre aber ein klarer Anwenderfehler, den die Firmware nicht verhindern kann.

In dem anderen Thread geht es darum, ob G0/G1 weiter nach oben fahren können soll wenn Z-Min bereits ausgelöst hat, das ist nicht exakt das Gleiche, auch wenn die Problemstellung ähnlich ist. Wenn die Funktionalität von G0/G1 so verändert wird, dass damit Z-Min überfahren werden kann, dann kann man bei diesem Mechanismus natürlich auch gleich "deinen" minimalen Abstand zwischen Extruder und Heizbett berücksichtigen.


mfG
RF1000

Ach RF1000, den Panic User Error kannst Du so oder so nicht verhindern. Ich habe mit einem Modell auf der Platte Z-Home gemacht, die FW hat es nicht verhindert. Ausgehend von Deiner Logik müsste ich von euch jetzt Schadensersatz verlangen, weil die FW das nicht verhindert hat.

Wenn garkeine HBS Matrix gespeichert ist, kann man verhindern dass die Z-Komp aktiviert werden kann. Für diesen Fall also - ebenso wie wenn die Kompensation garnicht eingeschaltet ist - hatte ich bereits mehrmals erwähnt, dass der Drucker dann die Z-Schalter Position als Nullpunkt annehmen soll/muß.

Mechanische Änderung nach HBS. Sorry, aber auch wenn ich mit der gegenwärtigen (total sicheren) FW nen erfolgreichen HBS mache, und danach mein Druckbett auf 5mm Abstandsrollen aufbocke, verhindert auch die jetzige FW den Crash nicht. Es ist also Quatsch zu behaupten, die angeregte Änderung der Z-Logik würde die Firmware hier unsicherer machen. Du hast im weiteren selber geschrieben, dass dies ein klarer Benutzerfehler ist, den die FW nicht verhindern kann. Nach der angeregten Änderung genausowenig wie aktuell.

Und auch mit der jetzigen FW kann man den "Endschalter" bis zum absoluten Nullpunkt überfahren. Halt nur mit dem allerersten Fahrbefehl. Aber mit diesem kann ich trotzdem die Düse aufs Bett setzen, und solange ich keine neue Z-Höhe anfahre, stundenlang in X und Y kreuz und quer über das Bett brettern. Das verhindert die Firmware ebensowenig.

Ja, die Problemstellung ist ähnlich, die besagte Anregung nicht höher als die minimale Z.Auflösung fahren zu können ist eine zusätzliche Sicherheit. Eine die Aktuell noch garnicht gegeben ist, siehe vorheriger Absatz.

Und zum tausensten mal, dieser Schalter ist nicht Z-Min! Endschalter KANN MAN NICHT ÜBERFAHREN da sie wie der Name schon sagt, EIN ENDE DEFINIEREN! Und nur Chuck Norris ist in der Lage ein Ende zu überfahren! Vielleicht wäre die ganze Debatte über die Z-Logik weniger missverständlich, wenn Du nicht immer eine Terminologie gebrauchen würderst, bei der jeder Maschinenbaustudent Gehirnkrämpfe bekommt. Dieser Schalter liefert einen Referenzpunkt. Es ist damit ein Referenzschalter. Unter bestimmten Bedingungen (Z Kompensation aus) kann man dann Z-Min = Z-Ref definieren.

Ich hatte ja ein konstruktives Brainstorming angeboten. Leider kam von Deiner Seite nix.

Zaldo hat geschrieben: Ausgehend von Deiner Logik müsste ich von euch jetzt Schadensersatz verlangen, weil die FW das nicht verhindert hat.

Also bitte. In welcher von meinen Aussagen willst du eine derartige Logik heraus gelesen haben? Bitte bleiben wir sachlich.

Zaldo hat geschrieben: Wenn garkeine HBS Matrix gespeichert ist, kann man verhindern dass die Z-Komp aktiviert werden kann.

Natürlich. Die Firmware hat es noch nie zugelassen, die Z-Kompensation zu aktivieren wenn keine gültige Kompensationsmatrix vorhanden ist.

Zaldo hat geschrieben: Mechanische Änderung nach HBS. Sorry, aber auch wenn ich mit der gegenwärtigen (total sicheren) FW nen erfolgreichen HBS mache ...

Auch die bisherige Firmware kann nichts gegen derartige Anwenderfehler ausrichten. Ich habe auch nirgends behauptet, dass die bisherige Firmware "total sicher" gegen Anwenderfehler wäre.

Zaldo hat geschrieben: Es ist also Quatsch zu behaupten, die angeregte Änderung der Z-Logik würde die Firmware hier unsicherer machen.

Ich mache fast nie Quatsch ...
Beim Z-Homing wird Z-Min zweimal angefahren, einmal schneller (um ihn zu finden) und danach einmal langsamer (um möglichst exakt den Auslösezeitpunkt zu finden). Wenn du nun mit einem schnellen G0/G1 nach oben fährst und dabei Z-Min um den vom HBS ermittelten Abstand überfahren willst dann wird der Auslösezeitpunkt (und damit die Z-Höhe) evtl. nicht so exakt ermittelt wie beim Z-Homing. Und als Folge davon wird der Z-Abstand trotz überfahren evtl. nicht exakt genug passen - im Worst Case kann es wieder zu einer Kollision kommen, wenn der minimale Abstand klein genug eingestellt worden ist und der Auslösezeitpunkt "falsch genug" ermittelt worden ist. In einem Bad Case würde "nur" die Layerhöhe nicht passen.
Das kann der Anwender natürlich wiederum leicht verhindern, indem dieses G0/G1 mit dem Z-Fahrbefehl für den 1. Layer die Z-Achse langsam genug bewegt. Aber es ist damit auch wieder eine weitere Möglichkeit für einen Anwenderfehler, der so in der bisherigen Firmware nicht vorhanden ist.

Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig

Zaldo hat geschrieben: Und auch mit der jetzigen FW kann man den "Endschalter" bis zum absoluten Nullpunkt überfahren. Halt nur mit dem allerersten Fahrbefehl. Aber mit diesem kann ich trotzdem die Düse aufs Bett setzen, und solange ich keine neue Z-Höhe anfahre, stundenlang in X und Y kreuz und quer über das Bett brettern. Das verhindert die Firmware ebensowenig.

Ohne M3006 sollte es unter realen Druckbedingungen nicht möglich sein, dass die Z-Kompensation zu einer Kollision zwischen Extruder und Heizbett führt. Man könnte natürlich mit G1 Z0.001 eine sinnfreie Z-Höhe einstellen und danach mit maximaler x/y Geschwindigkeit über eine sehr schräge Heizplatte rasen. Aber unter realen Druckbedingungen wird so eine Konstellation wohl kaum erreicht. Derartige Konstellationen gehören auf die Liste der Anwenderfehler (die von der Firmware nicht verhindert werden können).

Zaldo hat geschrieben: Und zum tausensten mal, dieser Schalter ist nicht Z-Min! Endschalter KANN MAN NICHT ÜBERFAHREN da sie wie der Name schon sagt, EIN ENDE DEFINIEREN! Und nur Chuck Norris ist in der Lage ein Ende zu überfahren! Vielleicht wäre die ganze Debatte über die Z-Logik weniger missverständlich, wenn Du nicht immer eine Terminologie gebrauchen würderst, bei der jeder Maschinenbaustudent Gehirnkrämpfe bekommt. Dieser Schalter liefert einen Referenzpunkt. Es ist damit ein Referenzschalter. Unter bestimmten Bedingungen (Z Kompensation aus) kann man dann Z-Min = Z-Ref definieren.

Dieser Schalter heißt "Z-Min" (in Schaltplänen, der Doku und in der Firmware). Wenn du aufmerksam mitgelesen hast dann verwende ich die Bezeichnung "Endschalter" dafür nicht mehr, um genau dieser Diskussion aus dem Weg zu gehen. Wenn ich "Z-Min" schreibe weiß jeder, was gemeint ist. Ich schreibe nicht "Z-Min Endschalter". Du schreibst in deinen Beiträgen auch immer "Z-Min" und eher nicht "Z-Min Referenzschalter".

Und der Vollständigkeit halber: "Z-Min" verhält sich wie ein Endschalter, solange die Z-Kompensation ausgeschalten ist. "Z-Min" verhält sich wie ein Referenzschalter, wenn die Z-Kompensation ein ist. Die Bezeichnung "Z-Min" sollte daher eindeutig sein, ohne Gehirnkrämpfe zu provozieren.
Ich bin dagegen anstelle von "Z-Min" z.B. "Z-Ref" verwenden, weil a) es auch "Z-Max" gibt, b) "Z-Min" eben auch ein Endschalter sein kann und c) "Z-Min" im Rahmen der Firmware und Doku ein etablierter und einigermaßen klarer Begriff ist.


mfG
RF1000

RF1000 hat geschrieben:Also bitte. In welcher von meinen Aussagen willst du eine derartige Logik heraus gelesen haben? Bitte bleiben wir sachlich.

Ich schließe das daraus, dass Du bei beinahe jedem Vorschlag einer Veränderung/Verbesserung der Z-Funktionalität betreffend entgegenstellst, dass ein Benutzerfehler eine [größere] Crashgefahr nach sich ziehen könnte, und die Änderung deshalb nicht gut sei.

Ich wollte mit diesem überzogenen Argument lediglich mal herausstellen, dass bei Benutzerfehlern immer eine Crashgefahr besteht (und nebenbei noch anmerken, dass die FW durchaus noch Potential hat den einen oder anderen Benutzerfehler abzufangen)

RF1000 hat geschrieben: Natürlich. Die Firmware hat es noch nie zugelassen, die Z-Kompensation zu aktivieren wenn keine gültige Kompensationsmatrix vorhanden ist.

Und warum führst Du dann genau das als Gegenargument an?

weil es damit diverse Möglichkeiten gibt, die zur Kollision führen können - z.B.:
[...]
- Die Heizbettmatrix ist nicht vorhanden (weil noch kein erfolgreicher Scan durchgeführt worden ist).
[...]

RF1000 hat geschrieben: Auch die bisherige Firmware kann nichts gegen derartige Anwenderfehler ausrichten. Ich habe auch nirgends behauptet, dass die bisherige Firmware "total sicher" gegen Anwenderfehler wäre.

Siehe mein erster Absatz in diesem Post.

RF1000 hat geschrieben: Ich mache fast nie Quatsch ...
Beim Z-Homing wird Z-Min zweimal angefahren, einmal schneller (um ihn zu finden) und danach einmal langsamer (um möglichst exakt den Auslösezeitpunkt zu finden). Wenn du nun mit einem schnellen G0/G1 nach oben fährst und dabei Z-Min um den vom HBS ermittelten Abstand überfahren willst dann wird der Auslösezeitpunkt (und damit die Z-Höhe) evtl. nicht so exakt ermittelt wie beim Z-Homing.

Nichts würde die Firmware daran hindern, auch bei einem Fahrbefehl diesen Doppelschritt zu machen, und unterhalb des Referenszschalters grundsätzlich Z nur langsam zu verfahren. Bei Drucken die Stunden dauern ist diese Verzögerung von ein oder zwei Sekunden sicherlich zu verschmerzen.

RF1000 hat geschrieben: Und als Folge davon wird der Z-Abstand trotz überfahren evtl. nicht exakt genug passen - im Worst Case kann es wieder zu einer Kollision kommen.

Ein Grund mehr, den anfahrbahren Abstand auf die minimal sinvolle Z Höhe (0,05mm) zu begrenzen. Bietet eine zusätzliche Sicherheitszone.

RF1000 hat geschrieben: In einem Bad Case würde "nur" die Layerhöhe nicht passen.

Vielleicht doch nochmal ein Grund über eine einmalige Abstandsmessung unmittelbar vor Druckstart nachzudenken. Gäbe es nämlich diese Möglichkeit wäre die gesamte Diskussion hier größtenteils obsolet. Weil garnicht mehr nötig wäre, das Druckbett auf minimalsten mechanischen Abstand zu justieren. Weil unmittelbar bevor der Extruder dem Bett zu nahe kommen könnte, der reale Abstand nochmals kontrolliert und korrigiert wird. Und selbst bei der Einmalmessung Messung geooztes Filament an der Düse (Dein Gegenargument dazu - wobei Du nie auf meine Ansätze dieses zu beseitigen eingegangen bist) würde schlimmstenfalls zu einer unwesentlichen Verkleinerung des Abstands führen, aber niemals dazu, dass der Extruder dem Bett gefährlich näher kommen würde als er darf.
Die Layerhöhe passt übrigens auch dann nicht, wenn ich auf 0,2mm drucken will, der Drucker mich aber minimal auf 0,5mm fahren lässt!! Dieser Zustand ist aktuell Systemstandard und nur durch abweichen vom mitgelieferten Start-Gcode (Fehlerquelle), abweichen von der empfohlenen mechanischen Grundeinstellung (Fehlerquelle) oder eigenmächtiger Modifikation der Firmware (Fehlerquelle) zu umgehen.

RF1000 hat geschrieben:Das kann der Anwender natürlich wiederum leicht verhindern, indem dieses G0/G1 mit dem Z-Fahrbefehl für den 1. Layer die Z-Achse langsam genug bewegt.

Siehe oben, das könnte die FW dem Andwender abnehmen und eine potentielle Fehlerquelle ausschließen.

RF1000 hat geschrieben: Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig

Das ist schön zu hören.

RF1000 hat geschrieben: Ohne M3006 sollte es unter realen Druckbedingungen nicht möglich sein, dass die Z-Kompensation zu einer Kollision zwischen Extruder und Heizbett führt. Man könnte natürlich mit G1 Z0.001 eine sinnfreie Z-Höhe einstellen und danach mit maximaler x/y Geschwindigkeit über eine sehr schräge Heizplatte rasen. Aber unter realen Druckbedingungen wird so eine Konstellation wohl kaum erreicht. Derartige Konstellationen gehören auf die Liste der Anwenderfehler (die von der Firmware nicht verhindert werden können).

Das war genau das was ich damit herausstellen wollte. Man kann es. Ob es Sinn macht steht auf einem anderen Blatt. Und das ist eben das was ich damit sagen wollte. Immerzu zu sagen "Wenn wir das so machen würden besteht aber die Gefahr das der Anwender einen Fehler macht und...." Diese Gefahr besteht sowieso an allen ecken und enden.

RF1000 hat geschrieben: Dieser Schalter heißt "Z-Min" (in Schaltplänen, der Doku und in der Firmware). Wenn du aufmerksam mitgelesen hast dann verwende ich die Bezeichnung "Endschalter" dafür nicht mehr, um genau dieser Diskussion aus dem Weg zu gehen. Wenn ich "Z-Min" schreibe weiß jeder, was gemeint ist. Ich schreibe nicht "Z-Min Endschalter". Du schreibst in deinen Beiträgen auch immer "Z-Min" und eher nicht "Z-Min Referenzschalter".

Nein, das ist mir in der Tat nicht aufgefallen, dass Du den Begriff "Endschalter" mittlerweile vernünftigerweise ebenfalls meidest. Wenn ich aber - wie Du korrekt anmerkst - ebenfalls von einem Z-Min schalter rede, dann tue ich das bestenfalls weil Du den Begriff zuvor gebraucht hast, und unbeteiligte Aussenstehende durchaus verwirrt werden können, dass wir von zwei verschiedenen Schaltern reden wo doch nur einer ist.

RF1000 hat geschrieben:Und der Vollständigkeit halber: "Z-Min" verhält sich wie ein Endschalter, solange die Z-Kompensation ausgeschalten ist. "Z-Min" verhält sich wie ein Referenzschalter, wenn die Z-Kompensation ein ist.

Das ist exakt dasselbe wie meine Aussage "Unter bestimmten Bedingungen (Z Kompensation aus) kann man dann Z-Min = Z-Ref definieren."

RF1000 hat geschrieben: Die Bezeichnung "Z-Min" sollte daher eindeutig sein, ohne Gehirnkrämpfe zu provozieren.

Nicht wirklich, den "Min" beschreibt ein Minimum.

RF1000 hat geschrieben: Ich bin dagegen anstelle von "Z-Min" z.B. "Z-Ref" verwenden, weil a) es auch "Z-Max" gibt, b) "Z-Min" eben auch ein Endschalter sein kann

Der Z-Max Schalter (Fräsbetrieb) beschreibt aber tatsächlich ein Maximum, denn hinter dem Schalter geht es tatsächlich nicht weiter.

RF1000 hat geschrieben: c) "Z-Min" im Rahmen der Firmware und Doku ein etablierter und einigermaßen klarer Begriff ist.

Etabliert ja. Einigermaßen klar? Ich würde sagen, die die hier schon länger sind, haben sich mit der unscharfen Definition einfach mittlerweile arangiert.


Lieber RF1000, wenn Du zwischen den Zeilen liest könntest Du durchaus merken, dass ich weder euch noch das Produkt pauschal dissen will (sonst hätte ich mir den RF1000 trotz meiner Vorgeschichte mit Conrad garnicht erst gekauft), und mir sehr wohl genaue Gedanken darüber mache, wie eine Änderung aussehen könnte, was für Vor- und eventuell Nachteile, und natürlich auch potentielle Risiken damit einher gehen könnten. Natürlich ist es möglich in so einer Überlegung auch etwas zu übersehen, und miteinander somit generell besser als gegeneinander. Jedoch ist es mitnichten so, dass ich hier einfach ein "Ich will das aber so" in den Raum werfe ohne mir irgendwelche weiteren Gedanken darüber zu machen. Ich glaube also nicht, dass Du mir Unsachlichkeit andichten solltest.

Beste Grüße
Holger

Zaldo hat geschrieben: Nichts würde die Firmware daran hindern, auch bei einem Fahrbefehl diesen Doppelschritt zu machen, und unterhalb des Referenszschalters grundsätzlich Z nur langsam zu verfahren.

Diese Annahme ist falsch. Die Firmware bekommt G-Codes gefüttert und plant ihre nächsten Schritte voraus, inkl. koordiniertes fahren aller Achsen, Beschleunigungen und Verzögerungen aller Achsen. Es ist ihr daher nicht so einfach möglich, zusätzliche Schritte in eine Richtung so einzufügen, dass es passt. Es ist auch bisher nicht vorgesehen, dass die Firmware die Fahrgeschwindigkeit laut G-Code automatisch/temporär anpasst.
Möglich ist natürlich nahezu alles.

Zaldo hat geschrieben: Die Layerhöhe passt übrigens auch dann nicht, wenn ich auf 0,2mm drucken will, der Drucker mich aber minimal auf 0,5mm fahren lässt!! Dieser Zustand ist aktuell Systemstandard und nur durch abweichen vom mitgelieferten Start-Gcode (Fehlerquelle), abweichen von der empfohlenen mechanischen Grundeinstellung (Fehlerquelle) oder eigenmächtiger Modifikation der Firmware (Fehlerquelle) zu umgehen.

Wir haben mehrere funktionierende Workarounds für das Drucken von 0,2 mm Schichten angeboten. Wenn nicht jeder dieser Workaround mit jeder Kombination von Slicer/PC-Software funktioniert ist das grundsätzlich vielleicht nicht unbedingt etwas, was immer die Firmware korrigieren muss.
Aber bevor wir da jetzt wieder die Grundsatzdiskussion anstoßen gilt:

Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig

Zaldo hat geschrieben: Immerzu zu sagen "Wenn wir das so machen würden besteht aber die Gefahr das der Anwender einen Fehler macht und...." Diese Gefahr besteht sowieso an allen ecken und enden.

"Immer" trifft nicht zu. Manchmal müssen wir aber natürlich auch diesen Aspekt in die Bewertung mit einfließen lassen, ob und wie etwas umgesetzt wird.

Zaldo hat geschrieben: Ich glaube also nicht, dass Du mir Unsachlichkeit andichten solltest.

Pauschal mache ich das auch nicht, aber "überzogene Argumente" (O-Ton Zaldo) möchte ich schon ansprechen dürfen, wenn sie aus meiner Sicht nicht zutreffend sind und/oder die Diskussion nicht sinnvoll weiterbringen.
Im übrigen bin ich dir (meistens ) dankbar für deine Beiträge, auch wenn wir nicht immer der gleichen Meinung sind.


mfG
RF1000

Dann überlege doch mal warum ich zu überzogenen Argumenten greife (greifen muß)

RF1000 hat geschrieben: Diese Annahme ist falsch. Die Firmware bekommt G-Codes gefüttert und plant ihre nächsten Schritte voraus, inkl. koordiniertes fahren aller Achsen, Beschleunigungen und Verzögerungen aller Achsen. Es ist ihr daher nicht so einfach möglich, zusätzliche Schritte in eine Richtung so einzufügen, dass es passt. Es ist auch bisher nicht vorgesehen, dass die Firmware die Fahrgeschwindigkeit laut G-Code automatisch/temporär anpasst.
Möglich ist natürlich nahezu alles.

Also ist die Annahme richtig. Es ist möglich. Ich habe nicht behauptet das es trivial ist.
Wäre übrigens überflüssig, wenn man vor dem Druckbeginn den Abstand nochmal messen würde

RF1000 hat geschrieben: Wir haben mehrere funktionierende Workarounds für das Drucken von 0,2 mm Schichten angeboten. Wenn nicht jeder dieser Workaround mit jeder Kombination von Slicer/PC-Software funktioniert ist das grundsätzlich vielleicht nicht unbedingt etwas, was immer die Firmware korrigieren muss.

Nur die Hervorhebungen, mehr brauch ich dazu glaube ich nicht zu sagen