Neue Development Firmware (RF.01.31)

[mhier]

Klar, aber mir ging es bei dieser "doppelten Buchführung" darum, übergeordnete Firmwarefehler (die es ja gibt - die Fehler und die Crashes - sonst müssten wir darüber ja garnicht diskutieren) auf unterster Ebene abzufangen.

Dann muss man diese doppelte Buchführung aber erstmal korrekt implementieren. Wer sagt, dass da nicht wieder Fehler drin sind? Die Z-Kompensation passiert schon recht weit "unten". Das Problem sind ja auch immer "Sonderfälle", die korrekt behandelt werden müssen (Beispiel: einer der beiden Z-Schalter löst aus). Das muss man dann doppelt implementieren, was die Code-Wartung sehr erschwert, oder gemeinsam abhandeln, was den Vorteil der doppelten Buchführung komplett zunichte macht (weil ein potentieller Bug dann ja beides betrifft). Dann doch lieber dem KISS-Prinzip folgen (keep it safe and simple)...

Ich kann das CTC da wirklich verstehen, ich würde da auch nicht mehr durchblicken, wenn ich irgendwo vor dem tatsächlichen Nullpunkt einen Phantasienullpunkt per Schalter definiere, und dann den tatsächlichen Nullpunkt irgendwo im negativen Bereich reinrechnen muss - wo doch der Slicer wiederum vom absoluten Nullpunkt ausgeht. Bei dieser hin- und herrechnerei passieren halt nunmal Fehler.

Um CTC mal in Schutz zu nehmen: vielleicht argumentieren sie hier manchmal falsch, aber von der Umsetzung her ist das letztlich egal. Die mechanische Z-Achse muss irgendwo ihren Nullpunkt haben. Egal was man macht, der Nullpunkt kann nie dort sein, wo die Düse das Heizbett berührt, weil das Heizbett ja nicht eben ist. Man wählt also einen willkürlichen Nullpunkt für die mechanische Z-Achse und muss dann entsprechend die Z-Werte umrechnen. Da führt leider kein Weg dran vorbei. Die Problematik bei der Umsetzung ist, dass in der Original-Repetier-Firmware sowas wahrscheinlich nicht vorgesehen war. Und dann fängt das große Basteln an... Bedenke, dass durch die Z-Kompensation die Z-Achse plötzlich auch bewegt werden muss, wenn eigentlich eine Bewegung nur in X/Y stattfindet.

Wichtig ist und bleibt aber eben, und da sind wir beide uns ja einig, dass Z-Min ausschließlich als Referenzpunkt für die mechanische Z-Achse zu gebrauchen ist. Es macht überhaupt keinen Sinn, irgendwelche Safety-Features auf Basis der mechanischen Z-Achsensposition zu implementieren. Die Implementierung der Z-Kompensation etc. ist *nur* richtig, wenn ich den Z-Schalter auch ein paar Zentimeter über dem Heizbett auslösen lassen kann (z.B. wenn er als Lichtschranke ausgeführt ist) und ich dennoch das selbe Ergebnis erhalte (abgesehen von einem länger dauernden HBS und einer entsprechenden Umstellung des Grenzwertes, wie weit der HBS fahren darf). Das ist aktuell nicht der Fall, was daran liegt, dass für manche Berechnungen dann doch "Z_mechanisch=0" mit "Druckdüse berührt Heizbett" als Näherung gleichgesetzt wird. Diese Näherung ist aber eben falsch und total unnötig. Im Falle von Safety-Features ist diese Näherung eben sogar gefährlich...

EDIT: Ich würde sagen, den Z-Schalter absichtlich so weit zu verstellen, wäre ein sehr guter Test, ob die Z-Kompensation korrekt funktioniert. Gleiches gilt für ein absichtlich extrem schief angebrachtes Heizbett. Solche Tests müssen zum korrekten Ergebnis führen. Anscheinend hat Conrad solche Tests aber nie durchgeführt, denn es ist ja klar, dass das aktuell nicht geht. Diese Fehler kann man nicht wegdiskutieren. Auch wenn das einer pathologischen Situation entspricht, die sicher kein Anwendungsfall ist, zeigt das einfach, wo die Berechnungen nicht stimmen.

[Zaldo]

Dann muss man diese doppelte Buchführung aber erstmal korrekt implementieren. Wer sagt, dass da nicht wieder Fehler drin sind?

Ich denke das wäre vergleichsweise überschaubar, und würde letztlich auch keine spätere Wartung erfordern. Denn Rudimentär ändert sich daran ja nichts mehr. Letztlich benötigt der Drucker ja zum arbeiten selber die Information, an welcher Z-Position er sich gerade befindet. Man müsste halt nur sicherstellen, dass diese Berechnung autark abläuft, und nicht durch eben diese Sonderfälle beeinflusst werden kann. Aktuell scheint es jedenfalls vor der Schrittausführung keine wirksame Kontrolle zu geben, ob ein Schritt nach Z-Minus überhaupt noch möglich ist.

Die mechanische Z-Achse muss irgendwo ihren Nullpunkt haben. Egal was man macht, der Nullpunkt kann nie dort sein, wo die Düse das Heizbett berührt, weil das Heizbett ja nicht eben ist. Man wählt also einen willkürlichen Nullpunkt für die mechanische Z-Achse und muss dann entsprechend die Z-Werte umrechnen.

Das ist so nicht ganz korrekt. Der absolute Nullpunkt in Z ist an der tiefsten Stelle des Betts. Alles andere ist ein Referenzpunkt. Man könnte jetzt trefflich darüber streiten ob es sinnvoller wäre die höchste Stelle des Betts als den Nullpunkt anzunehmen, dem entgegen stünde dann aber wieder, dass die tiefste Stelle im Bett wiederum im negativen Bereich liegen würde, was nicht wirklich Sinn macht. Aber dieser - ich nenne Ihn jetzt einfach nur noch "obere Schalter" kann bei aktiverter Z-Kompensation niemals Z=0 definieren, das ist und bleibt einfach Unsinn. Und das ist auch nicht "nur unkorrekt ausgedrückt", in früheren FW Versionen hat der Drucker diesen Punkt ja auch definitiv als Z=0 angezeigt. So ist es halt wie die Firmware rechnet. In irgendeinem Thread hatte RF1000 das auch mal so erläutert.

Bedenke, dass durch die Z-Kompensation die Z-Achse plötzlich auch bewegt werden muss, wenn eigentlich eine Bewegung nur in X/Y stattfindet.

Das weiß ich, das habe ich schon erschöpfend mit RF1000 diskutiert, solltest Du eigentlich gelesen haben. Und genau das ist der Punkt. Alles ist bis ins kleinste Ausdiskutiert. Und es ist offensichtlich auch kein Geheimnis, dass die FW aktuell - sagen wir mal diplomatisch - suboptimal ist. sonst würde man seitens Conrad ja auch nicht einräumen, dass man um die Probleme des Druckers wisse.

Alleine so der große Schritt in die richtige Richtung, der bleibt aus. Und das ist der Grund, weshalb ich vor einiger Zeit bereits gesagt habe, dass ich mich aus der Z-Diskussion zurück ziehe (was ich hiermit auch wieder tue), weil das in meinen Augen Zeitverschwendung ist. Es kommt einfach kein konstruktiver Dialog mit Conrad zustande - was ich auch garnicht dem RF1000 persönlich ankreide, denn offensichtlich ist es ja so, dass beim CTC da anscheinend ein größeres Gremium darüber entscheidet was gemacht wird und was nicht. RF1000 ist auch nur ein Rädchen im System, das die Prügel an der Front abbekommt.

[mhier]

Ich denke das wäre vergleichsweise überschaubar, und würde letztlich auch keine spätere Wartung erfordern.

Software muss man immer warten. Hast du schon mal bugfreie Software gesehen, die mehr konnte als "Hallo Welt"? Code-Duplikationen sind eine exterm schlechte Idee, immer. Die Berechnung muss von den Sonderfällen abhängen. Das sind insbesondere Zustandsübergänge (z.B. Z-Kompensation wird eingeschaltet oder Homing wir durchgeführt). Genau die brechen einem aber das Genick. Dazwischen geht auch nix schief. Die Firmware rechnet ja nicht einfach aus heiterem Himmel falsch...

Die mechanische Z-Achse muss irgendwo ihren Nullpunkt haben. Egal was man macht, der Nullpunkt kann nie dort sein, wo die Düse das Heizbett berührt, weil das Heizbett ja nicht eben ist. Man wählt also einen willkürlichen Nullpunkt für die mechanische Z-Achse und muss dann entsprechend die Z-Werte umrechnen.

Das ist so nicht ganz korrekt.

Doch

Der absolute Nullpunkt in Z ist an der tiefsten Stelle des Betts.

Das ist eine mögliche, aber eben auch willkürliche Definition. Negative Zahlen sind nichts schlimmes. Mein Argument war außerdem, es ist egal, wo du diesen Nullpunkt hinlegst. Ein statischer Offset ist nicht das Problem. Die Umrechnung wird kompliziert, da der Offset von X und Y abhängt. Genau hier liegt der Knackpunkt, warum die aktuelle Impementierung schlicht falsch ist. Z=0 in Benutzer-Koordinaten (also wie im GCode angegeben z.B.) ist immer da, wo die Düse gerade das Heizbett berührt. In diesem Koordinaten-System darf Z<0 nicht angefahren werden (oder besser Z < Sicherheits-Abstand), sonst mache ich was kaputt.

Alles andere ist ein Referenzpunkt.

Mathematisch *ist* ein Nullpunkt nichts anderes als ein Referenzpunkt.

Aber dieser - ich nenne Ihn jetzt einfach nur noch "obere Schalter" kann bei aktiverter Z-Kompensation niemals Z=0 definieren, das ist und bleibt einfach Unsinn.

Egal, was der "obere Schalter" genau definiert, er gibt einen Referenz- oder Nullpunkt der mechanischen Z-Achse an, der nicht von X und Y abhängt. Somit taugt er nicht als direkte Referenz für das Benutzerkoordinatensystem.

Und das ist auch nicht "nur unkorrekt ausgedrückt", in früheren FW Versionen hat der Drucker diesen Punkt ja auch definitiv als Z=0 angezeigt. So ist es halt wie die Firmware rechnet. In irgendeinem Thread hatte RF1000 das auch mal so erläutert.

Früher konnte der Drucker die Position im Benutzerkoordinatensystem nicht anzeigen, sondern hat immer nur die mechanische Position angezeigt.

Alleine so der große Schritt in die richtige Richtung, der bleibt aus.

Das siehst du m.E. ein bisschen zu negativ. In vielerlei Hinsicht hat sich die Firmware in letzter Zeit sehr gut in die richtige Richtung entwickelt. Leider wurde in dem hier diskutierten Aspekt ein Schritt in die falsche Richtung gemacht.

Es kommt einfach kein konstruktiver Dialog mit Conrad zustande - was ich auch garnicht dem RF1000 persönlich ankreide, denn offensichtlich ist es ja so, dass beim CTC da anscheinend ein größeres Gremium darüber entscheidet was gemacht wird und was nicht. RF1000 ist auch nur ein Rädchen im System, das die Prügel an der Front abbekommt.

Ich habe zu genüge Sachargumente angeführt. Die wurden nicht entkräftet sondern werden einfach weitgehend ignoriert oder übergebügelt. Das finde ich persönlich nicht in Ordnung. Wer das genau zu verantworten hat, ist mir nicht wichtig, es geht ja nicht um persönliche Verantwortung sondern um die Sache.

[Oo]

was ich auch garnicht dem RF1000 persönlich ankreide, denn offensichtlich ist es ja so, dass beim CTC da anscheinend ein größeres Gremium darüber entscheidet was gemacht wird und was nicht. RF1000 ist auch nur ein Rädchen im System, das die Prügel an der Front abbekommt.

So sieht es aus darum seit lieb zu RF1000 hier nochmal ein DICKES danke an RF1000 dafür das er sich überhaupt die Mühe macht hier im Forum zu diskutieren und sich zu erkennen gibt.
Trotzdem bleib ich lieber erstmal bei der .48

Gruß
Oo

[Zaldo]

Code-Duplikationen sind eine exterm schlechte Idee, immer.

Ich sprach nicht von Duplikationen. Ich sagte doch, es muss eine Referenz geben, eine Variable, die immer den gegenwärtigen Abstand von Extruder zu Bett enthält. Die ist nicht von Sonderfällen abhängig, denn sie reflektiert den aktuellen, tatsächlichen Physikalischen Abstand. Wenn die von Dir angesprochenen Sonderfälle an diesem physikalischen Abstand etwas ändern, dann hat sich auch die Referenz in der Variable zu ändern. Lediglich bei einem Z Home würde die Referenz anhand des Schalters neu bestimmt werden

Das ist eine mögliche, aber eben auch willkürliche Definition. Negative Zahlen sind nichts schlimmes. Mein Argument war außerdem, es ist egal, wo du diesen Nullpunkt hinlegst. Ein statischer Offset ist nicht das Problem. Die Umrechnung wird kompliziert, da der Offset von X und Y abhängt. Genau hier liegt der Knackpunkt, warum die aktuelle Impementierung schlicht falsch ist. Z=0 in Benutzer-Koordinaten (also wie im GCode angegeben z.B.) ist immer da, wo die Düse gerade das Heizbett berührt. In diesem Koordinaten-System darf Z<0 nicht angefahren werden (oder besser Z < Sicherheits-Abstand), sonst mache ich was kaputt.

Ich weiß sehr wohl auf was Du hinaus willst. Ich argumentiere lediglich, dass es sinnlos und unnötig verkomplizierend ist, hier mit unterschiedlichen Koordinatensystemen zu arbeiten, bloß weil man es kann und darf. Bei einer CNC Maschine, bei der ich irgendwo ein Werkstück angespannt habe, macht es durchaus sinn, dass das Maschinenkoordinatensystem und das Userkoordinatensystem unterschiedlich ist, denn hier kann der Werkstück-Nullpunkt an einem völlig anderen Punkt im Maschinenkoordinatensystem liegen.

Bei diesem Drucker allerdings, der bauartbedingt weder in der Luft noch unterhalb des Druckbetts drucken kann ist es schlicht und ergreifend quatsch. Im Fräsmodus mag man das anders handhaben wollen, aber beim drucken ist Maschinen-Null = User-Null.

Aber dieser - ich nenne Ihn jetzt einfach nur noch "obere Schalter" kann bei aktiverter Z-Kompensation niemals Z=0 definieren, das ist und bleibt einfach Unsinn.

Egal, was der "obere Schalter" genau definiert, er gibt einen Referenz- oder Nullpunkt der mechanischen Z-Achse an, der nicht von X und Y abhängt. Somit taugt er nicht als direkte Referenz für das Benutzerkoordinatensystem.

Das ist im Kern zwar richtig, jedoch hatte ich ja geschrieben, dass diese Referenz auf Grundlage der HBS Matrix an einem der durch den HBS ermittelten Meßpunkten gezogen werden soll. Somit bestünde in diesem Fall ein Bezug zur X/Y Koordinate. Muß ja auch zwangsläufig, denn wenn ich anhand des Referenzschalters den korrekten Abstand bestimmen will, kann ich dies nur an einem Punkt tun, wo ich vom HBS einen Messwert habe, da die Punkte dazwischen interpoliert und somit ungenau sind (aus diesem Grund ja auch die Sicherheitszone)

Aber ich wollte mich wirklich nicht mehr weiter mit diesem fruchtlosen Thema befassen, zumal wir hier schon wieder mitten in der Z-Logik Problematik stecken, für die es eigentlich einen eigenen Thread im Forum gibt.

[mhier]

Code-Duplikationen sind eine exterm schlechte Idee, immer.

Ich sprach nicht von Duplikationen. Ich sagte doch, es muss eine Referenz geben, eine Variable, die immer den gegenwärtigen Abstand von Extruder zu Bett enthält. Die ist nicht von Sonderfällen abhängig, denn sie reflektiert den aktuellen, tatsächlichen Physikalischen Abstand. Wenn die von Dir angesprochenen Sonderfälle an diesem physikalischen Abstand etwas ändern, dann hat sich auch die Referenz in der Variable zu ändern. Lediglich bei einem Z Home würde die Referenz anhand des Schalters neu bestimmt werden

Die entscheidende Frage ist aber doch, wo kommt der Zahlenwert der Variable her. Der muss ausgerechnet werden. Da der Wert nur so lange seine Gültigheit hat, bis der Drucker sich das nächste Mal bewegt (egal in welche Richtung), braucht man ihn auch nicht global abzuspeichern. Und dann sind wir bei dem, was es eh schon (mehr oder weniger) gibt.

Das ist eine mögliche, aber eben auch willkürliche Definition. Negative Zahlen sind nichts schlimmes. Mein Argument war außerdem, es ist egal, wo du diesen Nullpunkt hinlegst. Ein statischer Offset ist nicht das Problem. Die Umrechnung wird kompliziert, da der Offset von X und Y abhängt. Genau hier liegt der Knackpunkt, warum die aktuelle Impementierung schlicht falsch ist. Z=0 in Benutzer-Koordinaten (also wie im GCode angegeben z.B.) ist immer da, wo die Düse gerade das Heizbett berührt. In diesem Koordinaten-System darf Z<0 nicht angefahren werden (oder besser Z < Sicherheits-Abstand), sonst mache ich was kaputt.

Ich weiß sehr wohl auf was Du hinaus willst. Ich argumentiere lediglich, dass es sinnlos und unnötig verkomplizierend ist, hier mit unterschiedlichen Koordinatensystemen zu arbeiten, bloß weil man es kann und darf.

Nein, man muss es leider. Das Heizbett ist nicht eben, desegen ist das Nutzer-Koordinatensystem nicht mal karthesisch. Ohne Umrechnung kommst du nicht aus. Die CNC-Maschine hat eine ähnliche Problematik, allerdings sind da i.d.R. beide Koordinatensysteme karthesich (dafür u.U. noch gegeneinander verdreht). Der Vergleich hinkt also etwas...

Bei diesem Drucker allerdings, der bauartbedingt weder in der Luft noch unterhalb des Druckbetts drucken kann ist es schlicht und ergreifend quatsch.

Diese Aussage stimmt nur, wenn das Heizbett exakt eben ist. Ist es aber nicht.

Das ist im Kern zwar richtig, jedoch hatte ich ja geschrieben, dass diese Referenz auf Grundlage der HBS Matrix an einem der durch den HBS ermittelten Meßpunkten gezogen werden soll.

Was du vorhast, ist noch komplizierter als nötig und als aktuell umgesetzt. Das würde nämlich bedeuten, dass du erst von Z-Referenzpunkt, der durch den Schalter gegeben ist, auf einen willkürlichen Referenzpunkt auf dem Heizbett umrechnen musst. Dann musst du aber trotzdem noch bei jeder Bewegung die korrekte Z-Kompensation für den aktuellen XY-Wert addieren. Den Zwischenschritt kann man sich sparen, man addiert einfach bei der Kompensation etwas größere Zahlen.

[Zaldo]

Siehst Du, genau das ist der Grund warum ich mich hierzu schon überhaupt nicht mehr äußern will. Jeder versucht irgendetwas unnötig kompliziertes in das von mir gesagte reinzuinterpretieren, dabei ist es eigentlich ganz einfach, denn der Drucker weiß schon alles und kann auch schon alles. Ich versuch es jetzt nochmal an einem Beispiel:

Nehmen wir an, drei nebeneinanderliegende HBS Scanpunkte, wir nennen Sie mal X1, X2 und X3. Der Drucker macht einen HBS. Ausgehend vom "Oberen Schalter" stellt er nun fest, bei X1 kann er den Tisch 540 µSteps nach oben fahren, bei X2 580 µSteps und bei X3 560 µSteps. Das ist soweit noch nix neues, das macht er beim HBS ja heute schon so.

Er müsste nun lediglich noch die Erkenntnis treffen, dass X2 folglich der tiefste Punkt im Bett ist, und diesen als Z=0 definieren, und die Differenz in µSteps zu den anderen Punkten als Offset anwenden. Somit weiß der Drucker fortan an jedem Scanpunkt, wieviele µSteps er den Tisch ab Auslösung des "Oberen Schalters" noch hochfahren darf, bis der Extruder gerade so das Bett berührt. Voila, da hast Du deine zwei Koordinatensysteme. Aber das musst Du nicht erst erschaffen, das gibt es schon. Man muß es nur richtig anwenden. X1 Z0,0 entspricht Oberer Schalter + 540µSteps rauf, X2 Z0,0 entspricht Oberer Schalter + 580µSteps rauf, X3 Z0,0 entspricht Oberer Schalter + 560µSteps rauf. Diese Divergenz kann man dann wunderbar bis zur maximalen Kompensationshöhe ausschleichen, sodaß dann X1/2/3 Z0,5 jeweils Oberer Schalter +0 entspricht (bei einer angenommenen Kompensationshöhe von 0,5mm und einer "Oberer Schalter" Grundeinstellung von ebenfalls 0,5mm)

Nebenbei brauch er bei jeder Motoransteuerung nur die Schritte - damit meine ich die tatsächlichen Schrittbefehle an den Motorcontroller - mitzuzählen (der Bauraum besteht aus einer absoluten Anzahl µSteps) und schon habe ich die Variable, die meine absolute physische Position enthält.

Und weil es einerseits problematisch ist, den Extruder der gerade so das Bett berührt in X/Y zu verfahren, zweitens es durch die Interpolation zwischen den HBS Scanpunkten eine Unschärfe gibt, und es letztlich keinen Sinn macht, den Extruder im Regelbetrieb überhaupt auf 0,00 zu positionieren, sollte es eine Sicherheitszone geben, die über den HBS Offset drübergelegt wird, dass der Drucker also tatsächlich zwar weiß, wieviele µSteps er hochfahren kann bis der Extruder das Bett berührt, dies aber letztlich an jeder Stelle nur bis zu einem Abstand von 0,05mm zulässt.

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.

Das ist alles kein Hexenwerk, das meißte davon macht der Drucker doch heute schon, halt nur nicht richtig.

Aber in einem Punkt gebe ich Dir uneingeschränkt recht, Ideen und Vorschläge werden zumeißt entweder an die Wand gebügelt oder schlichtweg totgeschwiegen (Ich denke nur an den mehrfach geäußerten Wunsch, bei einem deutschen Produkt für einen deutschen Markt in einer deutschen Community vielleicht das Changelog auch in Deutsch zu verfassen - Ignoriert) Und solange mir das CTC also nicht eine Bahnfahrkarte nebst Einladung auf einen Kaffee und eine Bratwurst zukommen lässt, um die Ideen vielleicht mal zusammen in deren Team, vielleicht an einem Flipchart zu erörtern, und man gemeinsam auf Fragen, Erklärungen, Ideen und Missverständnisse direkt eingehen kann (und nicht mit der Forengegebenen Verzögerung von Tagen bis Wochen) war dies mein endgültig letzter Post zu diesem Thema.

[AZ-3]

Ich will jetzt nicht eure Diskussion stören, aber ich habe vielleicht einen Bug entdeckt.
Eben wollte ich einen Druck starten und nachdem ich 3 mal die Taste für Bett runter drückte(bei bereits laufendem Druck) fuhr er
einfach 50 mm runter, wie wenn gerade kein Druck laufen würde.
Ist das ein Bug oder ein Feature das ich übersehen habe?

[mhier]

Siehst Du, genau das ist der Grund warum ich mich hierzu schon überhaupt nicht mehr äußern will.

Vielleicht drückst du dich unklar aus? Oder - viel wahrscheinlicher - ich bin einfach nur ein Dickopf?

Er müsste nun lediglich noch die Erkenntnis treffen, dass X2 folglich der tiefste Punkt im Bett ist, und diesen als Z=0 definieren,

Ich glaube, hier liegt das "Problem" oder vielleicht eher Missverständnis. Es macht technisch keinen Unterschied, als was der Drucker diesen (willkürlichen) Punkt definiert.

und die Differenz in µSteps zu den anderen Punkten als Offset anwenden. Somit weiß der Drucker fortan an jedem Scanpunkt, wieviele µSteps er den Tisch ab Auslösung des "Oberen Schalters" noch hochfahren darf, bis der Extruder gerade so das Bett berührt.

Das weiß er auch ohne die Zwischentransformation. Die bringt rein gar nichts, sondern macht es nur komplizierter und Fehleranfällig. Eben genau diese Denkweise (Z=0 ist mein Minimum, ich muss nur noch die Z-Kompensation addieren) führt zu dem aktuellen Fehlverhalten der Firmware. Das Minimum ist da, wo die Düse das Heizbett berührt. Den (internen) Z-Wert muss die Firmware für jedes X/Y neu ausrechnen. Ob diese internen Z-Werte am Ende alle negativ sind oder alles so umtransformiert wird, dass einer davon 0 und alle andere positiv sind, ändert nichts am Rechenaufwand an der Stelle (fügt höchstes woanders noch welchen hinzu).

Richtig wird die Rechnung erst dann, wenn (in der gegenwärtigen Koordinaten-Definiton mit Z=0 am Z-Schalter) das gleiche Ergebnis heraus kommt, egal wie groß die Z-Kompensationswerte werden. Das ist aktuell nicht der Fall und für micht ganz klar ein Bug.

Nebenbei brauch er bei jeder Motoransteuerung nur die Schritte - damit meine ich die tatsächlichen Schrittbefehle an den Motorcontroller - mitzuzählen (der Bauraum besteht aus einer absoluten Anzahl µSteps) und schon habe ich die Variable, die meine absolute physische Position enthält.

Nein! Wenn du dich in XY bewegst und den Z Motor stehen lässt, ändern sich deine Schritte in Z nicht, wohl aber der Abstand zwischen Düse und Heizbett! Die Variable, die du beschreibst, gibt es schon, aber sie hilft eben nicht. So oder so muss eben *vor* der Bewegung berechnet werden, ob der Sicherheitsabstand unterschritten wird. Das kann wunderbar - ohne Einführen von irgendwelchen neuen globalen Variablen (das ist eh ein grauenhafter Programmierstil) - abgefragt werden in dem Moment, wo die Z-Kompensation berechnet wird. Das ist ein Zweizeiler!

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!

Das ist alles kein Hexenwerk, das meißte davon macht der Drucker doch heute schon, halt nur nicht richtig.

Exakt

So, um noch mal aus der unübersichtlich gewordenen Diskussion das Wesentliche rauszuziehen:

Vor dem kommenden Master-Stand wird sich an dem grundsätzlichen Verhalten der Firmware nichts mehr ändern, wann genau welche weiteren Features umgesetzt werden wird intern noch geklärt, dazu kann ich noch nichts Verbindliches sagen.

Liebes Conrad-Team,

ich möchte hiermit einen offiziellen Bugreprt erstellen: Laut Produktbeschreibung understützt der RF1000 die "Automatische Vermessung der Druckplatte mit intelligenter Druckanpassung". Das suggeriert, dass neben eventuellen Unebenheiten in der Druckplatte auch gewissen Ungenauigkeiten in der Justage kompensiert werden. In der aktuellen Firmware wird dies durch falsche Annahmen und infolge dessen falsche Berechnungen unnötigerweise verhindert bzw. extrem eingeschränkt. Konkret sind folgende Punkte falsch umgesetzt:

• 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 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.

Ob eine Umsetzung korrekt ist, kann u.a. durch folgende Tests nachgewiesen werden:

1. Test: Extreme Dejustage von Z-Min

• Z-Min-Schalter durch Lichtschranke o.ä. ersetzen, so dass er sich zerstörungsfrei um mehrere Zentimeter überfahren lässt.
• Z-Min so justieren, dass er mehrere Zentimeter über dem Heizbett auslöst
• Firmware-Toleranzen für den Heizbettscan für die Dauer dieses Tests so festlegen, dass ein Scan trotzdem durchgeführt werden kann.
• Heizbettscan durchführen
• Ein Objekt drucken, welches höher als HEAT_BED_Z_COMPENSATION_MAX_STEPS ist.
• Das Objekt muss korrekt gedruckt werden, d.h. es muss die gleiche Form (insb. Höhe) haben, wenn die Datei mit einem normal justierten Z-Min gedruckt wird.

2. Test: Extreme Dejustage des Heizbetts

• Das Heizbett wird absichtlich schief angebracht, z.B. durch 5mm höhere Abstandshalter auf einer Seite.
• Z-Min so justieren, dass Z=0 an allen Stellen oberhalb des Heizbetts liegt, an der höchsten Stelle des Betts z.B. 1mm darüber (sollte nach dem letzten Test keine Rolle mehr spielen).
• Firmware-Toleranzen für den Heizbettscan für die Dauer dieses Tests so festlegen, dass ein Scan trotzdem durchgeführt werden kann.
• Heizbettscan durchführen, Z-Kompensation einschalten
• Verschiedene Positionen nahe dem Heizbett über das ganze Bett verteilt anfahren. Für kleine Z muss der Abstand zwischen Düse und Heizbett immer
  dem im G-Code angegebenen Z-Wert entsprechen. Größere Ungenauigkeiten als bei einem korrekt justieren Heizbett sind zwar zu erwarten, jedoch müssen sie immer noch vernachlässigbar gegenüber der De-Justage sein (also Abweichungen sehr viel kleiner als die o.g. 5mm). Für Z > HEAT_BED_Z_COMPENSATION_MAX_STEPS muss der Abstand jeweils zur mittleren Höhe des Heizbetts stimmen (also in der Mitte des Heizbetts). Das dürfte nicht ganz einfach exakt zu messen sein, wichtig ist aber zu unterscheiden, dass nicht der höchste oder tiefste Punkt auf dem Heizbett als Referenz genommen wird.
• Der Versuch, den Sicherheitsabstand zu unterschreiten, muss in allen Bereichen des Heitzbetts unterbunden werden und zu einem Fehlerzustand (Druckabbruch) führen. Da ggf. die Genauigkeit nicht mehr ausreichend ist, kann der Sicherheitsabstand für diesen Test erhöht werden, es muss dann aber mechanisch nachgemessen werden, dass der eingestellte Sicherheitsabstand korrekt eingehalten wird.
• Alle Tests, insbesondere die Prüfung des Sicherheitsabstand, müssen für alle Möglichkeiten durchgeführt werden, mit denen Bewegungen ausgeführt werden können (GCodes, Menü, direkte Z-Tasten, etc.).

Solange diese Tests nicht das beschriebene Ergebnis liefern, hat die Firmware Bugs und entspricht nicht den Spezifikationen. Ich erwarte jetzt zunächst mal vom Conrad-Team, dass dies so anerkannt wird. Die bisherige Aussage "wird sich an dem grundsätzlichen Verhalten der Firmware nichts mehr ändern" etc. ist für mich nicht akzeptabel, da es hier nicht um Features sondern Spezifikations-widriges Verhalten geht.

Bisher hat sich Conrad doch immer eigentlich recht kulant gezeigt, ich verstehe nicht, was hier jetzt das Problem ist. Nur weil unter Laborbedingungen der Drucker trotz der Bugs anständig druckt, ist er so einfach nicht marktreif. Alle Nase lang kommen doch Beschwerden, die wahrscheinlich auf diese Probleme zurückzuführen sind. Klar lässt sich das oft mit Basteln beheben, aber dafür hab ich nicht 2000 EUR ausgegeben!

Wenn ihr jetzt sagt, ihr überlegt neue Features einzuführen, die diese Probleme vielleicht auf andere Weise beseitigen (z.B. der öfters andiskutierte Abstands-Scan unmittelbar vor dem Druck), wäre das ja durchaus auch eine akzeptable Lösung (in dem Beispiel sogar eine sehr gute). Aber dann muss das doch mal klar gesagt werden. Wenn das richtig umgesetzt wird, würde die Firmware ja auch die o.g. Tests erfolgreich absolvieren.

PS: Solche Tests sind extrem wichtig, werden aber anscheinend nicht durchgeführt von Conrad. Nur so lässt sich nachweisen, dass die angepriesenen Features überhaupt eine Wirksamkeit haben! Vielleicht lässt sich der eine oder andere Test im Detail anders durchführen, grundsätzlich muss aber an extremen Fällen gezeigt werden, dass das ansonsten quasi unsichtbare Verhalten wirklich korrekt ist.

[RFrank]

Sehr geehrtes Conrad-Team

Dem Beitrag von mhier kann ich nur zustimmen.

Solange diese Tests nicht das beschriebene Ergebnis liefern, hat die Firmware Bugs und entspricht nicht den Spezifikationen. Ich erwarte jetzt zunächst mal vom Conrad-Team, dass dies so anerkannt wird. Die bisherige Aussage "wird sich an dem grundsätzlichen Verhalten der Firmware nichts mehr ändern" etc. ist für mich nicht akzeptabel, da es hier nicht um Features sondern Spezifikations-widriges Verhalten geht.

Bisher hat sich Conrad doch immer eigentlich recht kulant gezeigt, ich verstehe nicht, was hier jetzt das Problem ist. Nur weil unter Laborbedingungen der Drucker trotz der Bugs anständig druckt, ist er so einfach nicht marktreif. Alle Nase lang kommen doch Beschwerden, die wahrscheinlich auf diese Probleme zurückzuführen sind. Klar lässt sich das oft mit Basteln beheben, aber dafür hab ich nicht 2000 EUR ausgegeben!

Wenn ihr jetzt sagt, ihr überlegt neue Features einzuführen, die diese Probleme vielleicht auf andere Weise beseitigen (z.B. der öfters andiskutierte Abstands-Scan unmittelbar vor dem Druck), wäre das ja durchaus auch eine akzeptable Lösung (in dem Beispiel sogar eine sehr gute). Aber dann muss das doch mal klar gesagt werden. Wenn das richtig umgesetzt wird, würde die Firmware ja auch die o.g. Tests erfolgreich absolvieren.

PS: Solche Tests sind extrem wichtig, werden aber anscheinend nicht durchgeführt von Conrad. Nur so lässt sich nachweisen, dass die angepriesenen Features überhaupt eine Wirksamkeit haben! Vielleicht lässt sich der eine oder andere Test im Detail anders durchführen, grundsätzlich muss aber an extremen Fällen gezeigt werden, dass das ansonsten quasi unsichtbare Verhalten wirklich korrekt ist.

Werden diese Extremparameter erfolgreich umgesetzt ohne Crash, wird es wohl auch bei den normal eingestellten Druckern klappen.

Für diesen Test bitte den nicht zweiten Z-Schalter vergessen (Circuit; Warum konnte man hier keinen zweiten Eingang nutzen? Es war bekannt, dass Fräsen kommen sollte.), der für viele gedrehte Berechnungen sorgt, die bei mir zu vermeidbaren Crashes geführt haben.

Ich würde mit meinem Drucker auch vorbei kommen am Wochenende für einen Test/Workshop, wenn zu wenig Testgeräte zur Verfügung stehen .

Gruß Frank