Hallo RF,

wird die kommende Master das DDP-HBS Problem lösen? Also das der Extruder aufgeheizt wird, und erst dann das Bett berührt?
Ich würde die neue FW gerne verwenden, aber das hält mich im Moment noch davon ab.

LG Thomas

Hi!

Mal eine gaaanz andere Frage: weiß jemand, ob die USB-Verbindung des RF mit anderen Slicern außer Reptier stabiler geworden sind?
Ich habe ja die alte .48er, auf DGlass modifiziert, am laufen. Soweit auch alles Fein, aber mit der Astrobox geht da schon mal gar nix...
Mehr wie eine halbe bis 3/4 stunde ist keinesfalls drin, dann fangen die zicken an - dafür brauch ich keine Raspberry bassierte Cloud
Printing, so toll und praktisch und durchdacht Sie auch ist... Auch wenn Conrad Sie für den RF1000 beworben hat.
Das Teil ist Genial, wenn es funzt, aber so leider nur ein überzogenes teures Gimmick... Es graut mir zwar vor den anstehenden
modifiaktionen, aber das wäre noch was, um meinen inneren Schweinehund dazu zu überreden!
Aber wie gesagt, DDP muß unterstützt werden und es muß endlich auch mit anderen Slicern ein stabiler Connect zustande kommen,
damit ich auch Online das Teil steuern und überwachen kann. Wäre super, wenn da schon jemand Erfahrungen hätte...

Gruß, Christian

RF1000 hat geschrieben:

mhier hat geschrieben: Ich spreche von dem Sicherheits-Feature, dass Z-Min nur um maximal 0.5mm überfahren werden darf. Wenn ich das richtig verstehe, gibt es das Feature noch.

Natürlich ist dieses Feature (FEATURE_ENABLE_Z_SAFETY) noch vorhanden.

Hab ich nicht bestritten

mhier hat geschrieben: Das führt aber leider dazu, dass ein anderes Sicherheits-Feature ausgehebelt wird. Wenn nämlich eine zu große Kraft auf den Druckkopf gemessen wird, blockiert i.d.R. der Drucker alle Bewegungen.

RF1000 hat geschrieben:Du meinst vermutlich FEATURE_EMERGENCY_Z_STOP. Dessen Funktion wird von FEATURE_ENABLE_Z_SAFETY nicht beeinflusst.

Ich verwechsele die Namen gerne. Ich meine das Feature, das die Z-Bewegung stoppt aber nicht den Druck pausiert bzw. abbricht.

RF1000 hat geschrieben:FEATURE_EMERGENCY_Z_STOP ist eher weniger gut gegen Vollkontakt auf der Höhe der ersten Layer geeignet

Ich spreche von Vollkontakt in Folge eines Firmwarefehlers, wie wir es ein paar mal hatten... Idealerweise sollte genauso Bedienerfehler abgesichert sein, man kann immer mal die falsche Taste drücken...

RF1000 hat geschrieben:... weil es ausschließlich die Bewegung in Z-Richtung blockiert (d.h. Bewegungen in x und y-Richtung werden weiterhin ausgeführt - das war bisher immer so, es gibt aber intern bereits Überlegungen, alle Bewegungen zu blockieren ... da die Firmware jetzt ja Meldungen anzeigen kann könnte eine mögliche Verbesserung in etwa so aussehen, wie du es auch skizziert hast).

Stimmt, aber wenn die Bewegung in Z nicht zuende ausgeführt wird, weil z.B. ein Firmwarefehler das Bett gerne 200mm nach oben fahren würde, blockiert das Feature die Bewegung komplett.

Das ist mir das eine oder andere Mal passiert (i.d.R. aufgrund von Firmwarefehlern, die inzwischen vielleicht oder vielleicht auch nicht behoben sind - ich habe die Übersicht verloren). Als es mir nach dem Update auf RF.01.25 wieder passiert ist, hat aber eben leider offensichtlich das andere Sichereits-Feature, das verhindert dass der Z-Min zu weit überfahren wird, vorher gegriffen. Dadurch wurde dann die Düse abgeschliffen...

RF1000 hat geschrieben:Der ursprüngliche Hintergedanken bei FEATURE_EMERGENCY_Z_STOP war zu erkennen, wenn jemand ein Z-Homing ausführt und vorher vergessen hat, das Objekt von der Druckplatte zu räumen.

Es hat aber eben auch bei manchen Firmware-Problemen geholfen...

mhier hat geschrieben: Das neue "Sicherheits-Feature" greift aber ggf. früher und verhindert, dass eine so große Kraft überhaupt gemessen wird.

RF1000 hat geschrieben:In dem Fall wäre zu überlegen, den Auslösepunkt von FEATURE_EMERGENCY_Z_STOP (also EMERGENCY_Z_STOP_DIGITS_MIN und EMERGENCY_Z_STOP_DIGITS_MAX) zu verändern. Sensiblere Grenzen können die Hardware besser schützen, können aber auch eher zu einem unerwünschten Druckabbruch führen.

Ich denke, generell sollte die Auslösung *jedes* Sichereits-Checks dazu führen, dass alle Achsenbewegungen angehalten werden, bis der Nutzer eine Bestätigung am Bedienfeld vornimmt. Andernfalls ist kein Sicherheitsgewinn gegeben, teilweise eben sogar im Gegenteil.

mhier hat geschrieben: Ich hab ja auch bereits mehrfach argumentiert, warum dieses Feature falsch ist. Es verhindert eben überhaupt nicht, dass die Düse aufs Heizbett kommt.

RF1000 hat geschrieben:FEATURE_ENABLE_Z_SAFETY sorgt dafür, dass der minimale Abstand während dem Druckvorgang nicht unter Z_OVERRIDE_MAX fällt (was per Default 0,5 mm sind). In deinem Fall hat die Firmware aber Z-Max erkannt und wollte Z-Max danach freifahren, was durch eine beherzte Bewegung nach oben passiert. Und über diese Bewegung hat FEATURE_ENABLE_Z_SAFETY keine Kontrolle (weil sie außerhalb vom normalen Druckvorgang (= der G-Code Queue) passiert), was letztlich zu dem zu geringen Abstand führt.

Ich kann nicht mehr genau nachvollziehen, was passiert ist. Deine Beschreibung hier passt aber nicht zu meinen Beobachtungen. Es hat eben nur eine sehr geringe Bewegung nach oben stattgefunden, mutmaßlich bis Z_OVERRIDE_MAX erreicht war. Dann haben dennoch weiterhin XY-Bewegungen stattgefunden.

RF1000 hat geschrieben: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.

Sorry, aber euer Z_OVERRIDE_MAX macht so einfach keinen Sinn! Es bringt schlicht keine Sicherheit. Fasst dies gerne als offizielle Beschwerde/Reklamation auf: Die Implementierung ist aktuell fehlerhaft, da wichtige Sicherheitsprüfungen inkorrekt ausgeführt sind. Z_OVERRIDE_MAX verhindert NICHT, dass die Düse in das Heizbett fährt! Es bewirkt nur, dass die Z-Kompensation nicht ordnungsgemäß funktioniert, wenn der Z-Anschlag nicht perfekt justiert ist (und das ganz ohne Not). Anscheinend kann es außerdem noch dazu führen, dass die Düse beschädigt wird, während sonst der Drucker stillstand (vielleicht habt ihr das ja noch durch etwas anderes "verhunzt", das kann ich nicht beurteilen). Ich hab das schon oft genug erklärt, nochmal tu ich es nicht. Wenn ihr das nicht versteht, lasst es bleiben, Firmware zu entwickeln (dann kriegt ihr allerdings ne dicke Rücksendung von mir).

mhier,

mhier hat geschrieben:.... Z_OVERRIDE_MAX verhindert NICHT, dass die Düse in das Heizbett fährt! Es bewirkt nur, dass die Z-Kompensation nicht ordnungsgemäß funktioniert, wenn der Z-Anschlag nicht perfekt justiert ist (und das ganz ohne Not). Anscheinend kann es außerdem noch dazu führen, dass die Düse beschädigt wird, während sonst der Drucker stillstand (vielleicht habt ihr das ja noch durch etwas anderes "verhunzt", das kann ich nicht beurteilen). Ich hab das schon oft genug erklärt, nochmal tu ich es nicht. Wenn ihr das nicht versteht, lasst es bleiben, Firmware zu entwickeln (dann kriegt ihr allerdings ne dicke Rücksendung von mir).

ABER ich bin der Meinung, dass nur durch das Überfahren des Z-Endschalters eine korrekte Funktion der Z-Kompensation möglich wird.
Beispiel:
Stellt man den Z-Endschalter so ein (='perfekt'?), dass es an der höchsten Stelle des Betts keinen Kontakt mit der Düse geben kann, hat man bei einem unebenen Bett Probleme mit dünnen Layern. Meine 'Barockfliese' die nicht völlig eben ist, hat einen Unterschied zwischen höchster und tiefster Stelle von ca. 0.3mm. Damit wären alle Layerhöhen unter 0.3mm problematisch oder unmöglich (zumindest an den tiefen Stellen). Sogar meine Ceranplatte-Eigenbau hat eine Gesamtunebenheit über 0.2mm, was hier die minimale Layerhöhe auf 0.2mm limitieren würde..

Das mit dem Überfahren des Endschalters mittels GCode befürworte ich - nur so sind sehr dünne Layer möglich (eingeschaltete Z-Kompensation vorausgesetzt, natürlich).
(Oder ich mache auf 'alte Schule' und mache als erstes immer einen Raft mit 0.5mm und spare mir die Z-Kompensation ganz.)

Vielleicht stehe ich mit dieser Meinung allein da ...?

mjh11

Hallo rf1k_mjh11,

das ist völlig richtig, ich habe aber nichts dagegen gesagt, dass der Z-Schalter überfahren werden muss.

Z_OVERRIDE_MAX ist ein Maximal-Wert, wie weit der Z-Min-Schalter überfahren werden darf, und ist standardmäßig fest eingestellt auf 0.5mm. Das wurde in einem kürzlichen Firmware-Release als zusätzliches Sicherheits-Feature eingeführt. Leider limitiert es den absoluten Weg, der in Z-Richtung noch gefahren werden darf, nachdem Z-Max ausgelöst hat, unabhängig davon, wie groß der jeweilige Abstand zwischen Düse und Heizbett ist. Damit dies wirklich das Heizbett schützt, muss Z-Min so eingestellt werden, dass ein Z-Wert von -0.5mm (bei ausgeschalteter Z-Kompensation) überall auf dem Heizbett (welches immer uneben und leicht schief ist!) noch oberhalb des Heizbetts aber auch innerhalb des 1. Layers liegt. Wird der Abstand zwischen Z-Min und Heizbett verringert, schützt Z_OVERRIDE_MAX Düse und Heizbett nicht vor einer Kollision. Fast noch schlimmer finde ich, dass wenn der Abstand vergrößert wird, die Z-Kompensation in ihrer Arbeit behindert wird. Das bekommt man nicht mal mit (höchstens wenn man ins Log vom Repetier-Host schaut).

Was mich extrem daran stört, ist, dass es sich relativ einfach richtig machen ließe. Die Z-Kompensation kennt natürlich jederzeit den Abstand zwischen Heizbett und Düse, folglich könnte einfach ein Limit von 0.1 oder 0.05mm als Mindestabstand zwischen Heizbett und Düse eingestellt werden. Dies würde auch bei Bedien- oder Programmierfehlern in vielen Fällen Schaden an Düse oder Heizbett verhindern. Nur während eines Heizbett-Scans muss das Limit natürlich deaktiviert werden, aber dann ist der Abstand ja auch nicht bekannt.

Hinzu kommt, wenn das "Ausschleichen" der Z-Kompensation bei großen Z-Werten korrekt umgesetzt wäre, würde ein größerer Abstand zum Heizbett beim Auslösen von Z-Min überhaupt keine negativen Konsequenzen haben (sofern der Schalter das mechanisch mitmacht), sehr wohl aber große Vorteile mit sich bringen: Man müsste Z-Min im Prinzip gar nicht mehr exakt justieren. Auch wäre die Gefahr des Crashes geringer (lies: quasi ausgeschlossen), wenn z.B. nach Düsenwechsel oder Fräser-Umbau die Abstände sich leicht verändert hätten. Man müsste einfach nur einen HBS durchführen und alles würde einfach so funktionieren .M.E. steht sich Conrad hier massiv selbst im Wege. Die größte Fummelei am RF1000 wäre letztlich komplett gelöst, wenn man nur diese beiden Sachen richtig machen würde... :-/

Gruß
Martin

Martin/mhier,

Du könntest mit den meisten Aussagen Recht haben, ich habe mich schon länger nicht mehr in die Sache 'hinein gedacht'. Mein Kopf ist schon länger woanders. Eine Aussage muss man aber relativieren:

mhier hat geschrieben:.... Was mich extrem daran stört, ist, dass es sich relativ einfach richtig machen ließe. Die Z-Kompensation kennt natürlich jederzeit den Abstand zwischen Heizbett und Düse, folglich könnte einfach ein Limit von 0.1 oder 0.05mm als Mindestabstand zwischen Heizbett und Düse eingestellt werden. ....

Die Z-Kompensation kann das nur, wenn a) sie eingeschaltet ist, und b) wenn X, Y und Z bekannt sind. Bin ich in Z auf Home gefahren, aber in X und/oder Y nicht, führt ein manuelles 'herumfahren' über das Bett unter Umständen zum Düsenkontakt.

Wie machen wir es idiotensicher? Damit das Bett garantiert geschützt ist, könnte man erzwingen, dass nach dem Einschalten ein Homing immer durchgeführt werden muss (nach Bestätigung, natürlich, falls man das Druckobjekt vom Vortag noch nicht entfernt hat). Damit kann man die Z-Kompensation, im Prinzip, permanent aktiv haben. Wie läuft es aber bei den Fräsern und Lasergravierer ab? Da müsste man immer nach dem Einschalten/Resetten zwingend eine zusätzliche Abfrage durchführen, ob man im Druckmodus ist - nicht sehr user-friendly (welche Sprache verwendet man dann für diese Abfragen/Meldungen? (Diese Frage gilt für die Schmelzerkollegen aus DE, AT, CH, SLO, IT, NL, F, B, usw.)).
Auch kann/darf man die Motoren zwischendurch abschalten (der Drucker macht das sogar selbst, nach einiger Zeit) - dann ist plötzlich die Z-Kompensation auch futsch. Daher müsste die FW überwachen bzw. buchführen, ob inzwischen ein oder mehrere Motoren stromlos waren - es wird dann ein erneutes Homing notwendig, damit die Z-Kompensation stimmt. Automatisch darf das Homing aber nicht stattfinden, es liegt vielleicht immer noch was auf dem Bett ....

Leider verstehe ich vom Programmieren nur 5-15%, vielleicht erscheint es mir daher schon gar nicht als eine triviale Aufgabe, es perfekt hinzu bekommen. (Man lese dazu meinen zweiten Spruch.)

mjh11

rf1k_mjh11 hat geschrieben:Du könntest mit den meisten Aussagen Recht haben, ich habe mich schon länger nicht mehr in die Sache 'hinein gedacht'. Mein Kopf ist schon länger woanders. Eine Aussage muss man aber relativieren:

mhier hat geschrieben:.... Was mich extrem daran stört, ist, dass es sich relativ einfach richtig machen ließe. Die Z-Kompensation kennt natürlich jederzeit den Abstand zwischen Heizbett und Düse, folglich könnte einfach ein Limit von 0.1 oder 0.05mm als Mindestabstand zwischen Heizbett und Düse eingestellt werden. ....

Die Z-Kompensation kann das nur, wenn a) sie eingeschaltet ist, und b) wenn X, Y und Z bekannt sind. Bin ich in Z auf Home gefahren, aber in X und/oder Y nicht, führt ein manuelles 'herumfahren' über das Bett unter Umständen zum Düsenkontakt.

Ebenfalls völlig richtig. aber: ein statisches Z_OVERRIDE_MAX kann das eben auch nicht. Der von dir hier beschriebene Fall würde bedeuten, dass Z-Min falsch kalibriert ist, nämlich so, dass Z=0 teilweise schon im Bett liegt. Dagegen ist letzlich kein Kraut gewachsen. Die von mir vorgeschlagene Lösung würde aber eben dieses Risiko sogar noch minimieren, da ich nicht mehr so streng justieren muss und einen größeren Sicherheitspuffer einstellen kann.

rf1k_mjh11 hat geschrieben:Wie machen wir es idiotensicher? Damit das Bett garantiert geschützt ist, könnte man erzwingen, dass nach dem Einschalten ein Homing immer durchgeführt werden muss (nach Bestätigung, natürlich, falls man das Druckobjekt vom Vortag noch nicht entfernt hat). Damit kann man die Z-Kompensation, im Prinzip, permanent aktiv haben.

Am besten ist Überfahren nur erlaubt, wenn eben die Z-Kompensation eingeschaltet ist und X/Y/Z bekannt sind. (Wieder mit der Außnahme des HBS natürlich, der darf das trotzdem.) Ein automatisches Homing ist nicht nötig und nervt nur, wenn man z.B. erstmal überhaupt Z-Min Kalibrieren möchte (dazu muss man ohne Homing die Z-Achse verfahren können).

rf1k_mjh11 hat geschrieben:Wie läuft es aber bei den Fräsern und Lasergravierer ab?

Völlig anders. Wenn beim Einschalten nichts erzwungen wird, stellt man den Modus im Menü um. Diese ganzen Überlegungen spielen im Fräsmodus überhaupt keine Rolle mehr. Beim Lasergravieren dürfte die Z-Achse komplett unkritisch sein?

rf1k_mjh11 hat geschrieben:Auch kann/darf man die Motoren zwischendurch abschalten (der Drucker macht das sogar selbst, nach einiger Zeit) - dann ist plötzlich die Z-Kompensation auch futsch. Daher müsste die FW überwachen bzw. buchführen, ob inzwischen ein oder mehrere Motoren stromlos waren - es wird dann ein erneutes Homing notwendig, damit die Z-Kompensation stimmt. Automatisch darf das Homing aber nicht stattfinden, es liegt vielleicht immer noch was auf dem Bett ....

Die Buchführung gibt es schon. Sobald das Homing verloren ist, darf halt Z-Min nicht mehr überfahren werden bis zum nächsten Homing. Sollte man sich gerade bei z<0 befinden, gehen Bewegungen in XY erstmal gar nicht und in Z nur in positiver Richtung.

rf1k_mjh11 hat geschrieben:Leider verstehe ich vom Programmieren nur 5-15%, vielleicht erscheint es mir daher schon gar nicht als eine triviale Aufgabe, es perfekt hinzu bekommen. (Man lese dazu meinen zweiten Spruch.)

Für mich ist das mein täglich Brot...


PS @RF1000: Sorry wenn ich mich manchmal etwas rabiat ausdrücke... Ich meine das nicht so, wie es vielleicht klingt. Das Ende von meinem letzten langen Post kommt vielleicht etwas daneben rüber. Bitte lies das eher als Ausdruck meiner Überzeugung, dass ihr das sehr wohl versteht, was ich meine Ich glaube, wir reden einfach ein bisschen aneinander vorbei. Eigentlich dachte ich, wir wären uns einig, dass Z_OVERRIDE_MAX so in der aktuellen Form eigentlich falsch ist. Trotzdem lese ich immer wieder, dass es "erstmal" dabei bleiben soll, und das obwohl ich mir recht sicher bin, dass es bei mir den Düsen-Schaden mit-verursacht hat...

Ich will da eigentlich auch nicht zu viel drauf rumreiten, Conrad hat sich ja sehr kulat gezeigt (ich habe gleich drei frische 0.3mm-Düsen unkl. Dichtungen bekommen!). Ich habe einfach nur die Sorge, dass anderen das gleiche passiert...

mhier hat geschrieben:Z_OVERRIDE_MAX ist ein Maximal-Wert, wie weit der Z-Min-Schalter überfahren werden darf, und ist standardmäßig fest eingestellt auf 0.5mm. Das wurde in einem kürzlichen Firmware-Release als zusätzliches Sicherheits-Feature eingeführt.

Das ist halt genau das Problem. Sie haben es genau andersherum programmiert, als ich es vorgeschlagen habe, weil Sie partout nicht von diesem Z-Min-Ref-Wieauchimmer-Schalter als Maß aller Dinge ablassen wollen! Und genau das ist das Problem und wird bei dieser Firmwarephilosophie immer das Problem bleiben, egal wieviel Code sie um diesen Quatsch drumrum schreiben.

mhier hat geschrieben: Was mich extrem daran stört, ist, dass es sich relativ einfach richtig machen ließe. Die Z-Kompensation kennt natürlich jederzeit den Abstand zwischen Heizbett und Düse

Ich habe es aufgegeben dies zu wiederholen.

Letztlich führt kein Weg daran vorbei, dass der Drucker intern den genauen, aktuellen Abstand zwischen Düse und Bett kennt, und diesen jederzeit aus einer Variable abrufen kann. Unmittelbar bevor der Motor dann einen Schritt in Z-Minus-Richtung ausführt hat er zu prüfen, ob diese Variable >0,0 (plus die beschriebene Sicherheitszone) ist, und wenn nicht, den Schritt nicht auszuführen.

Aber eher fällt in Holland ne Windmühle um.

Zaldo hat geschrieben:Und genau das ist das Problem und wird bei dieser Firmwarephilosophie immer das Problem bleiben

Für mich hat das wenig mit Philosphie zu tun. Das ist schlicht mathematisch beweisbar falsch.

Zaldo hat geschrieben:Letztlich führt kein Weg daran vorbei, dass der Drucker intern den genauen, aktuellen Abstand zwischen Düse und Bett kennt, und diesen jederzeit aus einer Variable abrufen kann. Unmittelbar bevor der Motor dann einen Schritt in Z-Minus-Richtung ausführt hat er zu prüfen, ob diese Variable >0,0 (plus die beschriebene Sicherheitszone) ist, und wenn nicht, den Schritt nicht auszuführen.

Das ist doch sogar noch viel einfacher. Der Abstand zwischen Düse und Bett ist eben genau der Z-Wert, bevor die Z-Kompensation addiert wird. Da muss man gar nicht mit Steps rumhantieren oder getrennt Buch führen, sondern kann doch einfach z.B. an der Stelle im Code, wo die Z-Kompensation addiert wird (also unmittelbar davor), prüfen, ob der Z-Wert >= dem Sicherheitsabstand ist.

Wenn Conrad das GitHub-Repository richtig verwenden würde (und nicht bloß als Code-Verteilungsplattform missbrauchen würde), könnte man sich ja selbst dransetzen und es richtig machen. Aber so müsste ich komplett forken und könnte nur mit riesigem Aufwand noch Updates von Conrad mergen... :-/

mhier hat geschrieben: Das ist doch sogar noch viel einfacher. Der Abstand zwischen Düse und Bett ist eben genau der Z-Wert, bevor die Z-Kompensation addiert wird. Da muss man gar nicht mit Steps rumhantieren oder getrennt Buch führen, sondern kann doch einfach z.B. an der Stelle im Code, wo die Z-Kompensation addiert wird (also unmittelbar davor), prüfen, ob der Z-Wert >= dem Sicherheitsabstand ist.

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.

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.