Mendelson hat geschrieben:FW 1.43.88

Ein Fehler ist in der .88 definitiv raus. Ich hatte die SD-Fat-Lib überschrieben und nicht bedacht, dass ich weitere "Seriell-Print-Funktionen" ersetzen muss.
Sobald also irgendwas von der SD-Lib eine Meldung ausgeben wollte, lief definitiv was schief.
Also bitte mindestens die 1.43.90 nutzen.

Wir treffen uns heute abend in Cleversulzbach und ich installiere extra meine Programmier-Umgebung auf einem Laptop, sodass wir da evtl. noch einige Details erörtern und reparieren können.
Ich bringe einen RF2000 dort hin und mindestens Wessix den RF1000.

Das Problem ist, dass Fehler die erst nach vielen Minuten oder Stunden auftreten schlecht identifizierbar sind. So Zufallsdinger kann ich eigentlich nur mit generellem Cleanup und Glück aufklären. Wenn aber wie bei der 1.43.88 statt einem Pointer ein Flag übergeben wird, kann sowas schon vorkommen. Zumal die SD-Fat dennoch normal nichts auf der seriellen Leitung ausgibt, ausser sie würde einen temporären Fehler/Recovery oder eine Notice ausgeben wollen.

LG

Ich hab heute wieder einen Druck gestartet, die paar 1.43.88 Bugs stören mich nicht so sehr. Werde upgraden wenn der Drucker Pause macht.

@Mendelson, du hast doch ein Metallhotend, oder? Falls du noch den Orginal drin hast, vergiss meinen Einwand, aber wenn ich mich richtig entsinne, hast du ein Metallhotend - und da solltest keinesfalls bei Druckende den Drucker gleich ausschalten...! Die Suppe im Hotend muß erst wieder auf unter 50 Grad kommen, bevor man den abschalten sollte/kann! Andernfalls kann das zu unerwarteten Nebenwirkungen kommen...
Nur als kleiner Hinweis - auch für die mitlesenden, die ebenfalls ein Metallhotend Upgegraded haben...

Gruß, Christian

@Digibike Keine Sorge, verwende das V2 Hotend. Muss mal meine Konfiguration in die Signatur schreiben ..

Guten Morgen

Wir haben heute einiges testen können, weil wir einen RF2000 und zwei RF1000 beim Stammtisch mit dabei hatten. Ich hatte die Programmierumgebung mit dabei.
Der Fehler von AtlonXP, dass der Drucker mit 1.43.88 und Repetier-Host nicht funktioniert hatte ist gelöst.
Grund war der schon bekannte Fehler im Gcode M20: Repetier-Host wollte die SD-File-Listings auslesen.

Nun stimmt auch beim Milling-Mode die Koordinatenachse nach dem Homing in Z. Die 2,1mm Freifahrweg nach dem Homing sind nun wegdefiniert.
Die Startcoordinate bei einem Homing im Millinmode ist für Z nun weiterhin 196, weils logisch einfach passt. Natürlich weiß man dann nicht wo der Fräser steht, aber es ist eigentlich korrekt, weil in dem Moment aus Hotend-/Fräser-Sicht das Tool eben 196mm über dem Nullpunkt steht. Zumindest muss das angenommen werden.

Leider ist uns das Y-Homing während dem Druck von einer SD-Karte an einem RF1000 aufgefallen. Und zwar mit einer 1.43.91. Der Bug ist also nicht behoben. Ich habe den SD-Support darum in der Firmware deaktiviert.
-> 1.43.92
Und es ist nun per Definition geregelt, dass sich der MOVE_CACHE automatisch erhöht, wenn der SD-Support raus ist.

Generell ist es so, dass ich meine Drucker ohne SD-Support compiliere. Weil ichs nicht brauche und sowieso über Raspberry-PI drucke. Und es funktioniert einfach gut. Es ist schade, dass der SD-Support nun temporär per default OFF ist, aber ich weiß mir aktuell nicht anders zu helfen. Das Drucken von SD ist einfach nicht stabil.

Und das ist auch in der aktuellen Mod-Stable mit 1.43.20 nicht stabil. Die erste Beschreibung des Bugs kam bei mir irgendwann ab 1.42.xx oder früher an. Ich kann also aktuell leider keine Tipps geben, zu welcher Version wir die Stable zurückrollen sollten.
Wenn jemand dazu eine Idee hat, höre ich gerne zu.

LG

Nibbels hat geschrieben:
Leider ist uns das Y-Homing während dem Druck von einer SD-Karte an einem RF1000 aufgefallen. Und zwar mit einer 1.43.91. Der Bug ist also nicht behoben. Ich habe den SD-Support darum in der Firmware deaktiviert.
-> 1.43.92
Und es ist nun per Definition geregelt, dass sich der MOVE_CACHE automatisch erhöht, wenn der SD-Support raus ist.


LG

Das ist schade, dass die SD Karten Unterstützung weg fällt.
Somit bin ich raus.

Da in S3D (V4.0.0) das Drucken über USB auch nicht ordentlich funzt, wegen gelegentlichen USB Pausen, sind auch dort Umwege über Repetier Host nötig.
Das Problem liegt nicht an der EDV Hardware.
Ich habe einen potenten Ryzen 7 zum Testen verwendet und die USB Pausen waren trotzdem noch vorhanden.
Es soll eine neue S3D Version erschienen sein.
Ich habe immer noch die Hoffnung, dass die S3D Programmierer endlich versuchen die vielen
Bugs in ihrer Programmierung zu beheben.

Der Fehler mit den X und Y Achsen (Ausbruch zum Homing) konnte ich bei mir noch nicht feststellen.
Vielleicht ist aber mein Crash mit der Z Achse, auch mit diesem Problem verwand!
Es kann aber auch sein, da ich Z Lift (0,4 mm) aktiviert hatte, dass es damit zusammen hängt.
Darum empfehle ich, lasst Z Lift lieber aus.

Ihr kennt meine Empfehlung, die Masse vom Druckergehäuse aufzutrennen.
Nach meinem jetzigen Kenntnisstand bringt das aber nichts, da trotzdem noch eine Verbindung besteht.
Ich vermute, dass eine Verbindung über die Befestigung Netzteilgehäuse, zum Drucker besteht.
Dieser Sache werde ich bei Gelegenheit nachgehen.

Zum Thema Raspberry-PI:
Irgendwann werde ich auch noch so ein Ding verwenden.
Leider ist bis jetzt mit dem Raspberry-PI, keine ordentliche Slicer Vorschau (live) möglich, wie z.B. in S3D.
Ich bin immer noch am Lernen mit dem 3D Drucker und lege darum großen Wert darauf.


LG AtlonXP

AtlonXP hat geschrieben:

Nibbels hat geschrieben:
Leider ist uns das Y-Homing während dem Druck von einer SD-Karte an einem RF1000 aufgefallen. Und zwar mit einer 1.43.91. Der Bug ist also nicht behoben. Ich habe den SD-Support darum in der Firmware deaktiviert.
-> 1.43.92
Und es ist nun per Definition geregelt, dass sich der MOVE_CACHE automatisch erhöht, wenn der SD-Support raus ist.


LG

Das ist schade, dass die SD Karten Unterstützung weg fällt.
Somit bin ich raus.

Stop-stop-stop

Wenn du mit dem SD-Druck wie er jetzt funktioniert zufrieden bist und die Fehler bei dir nicht auftreten musst du in der FW nur in der Configuration.h
auf schalten. und die zwei folgenden Zeilen vor denen "if SDSUPPORT -> #error + Warnung" steht löschen. Dann ist alles wie bisher.
Ich will aber eben nicht, dass Personen die nicht genau wissen was sie tun einfach eine Firmware installieren, weil sie denken da funktioniert alles zuverlässig -> und dann von SD drucken.

Wegen Repetier-Server vs. Octopi auf einem RaspberryPI:

Bilder:
http://demo.repetier-server.com:4005/#!/dashboard
https://www.repetier-server.com/

https://octoprint.org/
https://plugins.octoprint.org/
https://www.google.com/search?q=octopri ... iZsWRT2HwM:



Warum reparier ichs nicht einfach? Weil mir die Zeit fehlt. Ausserdem weiß ich schon seit November von dem Fehler und wir konnten den bisher nur auf den Datenstrom von SD-Karte eingrenzen. Ich weiß aber nicht warum das passiert, weil ich selbst zu wenig drucke und zu wenig Zeit habe absichtlich von SD zu drucken, wenn ich was drucken muss.
Ich müsste nun hingehen und alles was an GCode von der SD-Karte geparsed wird über USB ausgeben. Dann die GCodes von der SD-Karte mit denen die aus der USB-Leitung purzeln vergleichen.
Fehlerspekulationen:
Es kann sein, dass beim SD-Lesen "nicht bereit" mit Zeilenende verwechselt wird. Es kann sein, dass ab und an Kommentare im Code nicht verstanden werden. Es kann sein, dass die Interrupt-Frequenz manchmal dem SD-Lesen in die Suppe spuckt. Es könnte sein, dass normal auftretende Fehler nicht korrekt behandelt werden. Oder es kann sein, dass zeitweise sehr viel Ram vom SD-Modul reserviert wird und irgendwo anders die Fehler passieren. Wir könnten auf den alten SD-Code zurückbauen, aber ich glaube eigentlich nicht, dass die moderne allgemein akzeptierte Arduino SDFat-Lib fehleranfälliger ist als der alte Code von 2013.
Und das ist hässlich. Ausgeschlossen hab ich wirklich schon viel.

Wenn du dich zurück erinnerst: Mit welcher älteren Firmware warst du völlig zufrieden? Dann könnten wir die einfach als Stable setzen, auch wenn ich selbst nie wieder in alte Versionen zurückwechseln werde. Da fehlen mir unter Umständen zu viele Features wie Decoupling-Schutz bei den Heizelementen usw.

LG

Nibbels hat geschrieben: Wenn du dich zurück erinnerst: Mit welcher älteren Firmware warst du völlig zufrieden?
Dann könnten wir die einfach als Stable setzen, auch wenn ich selbst nie wieder in alte Versionen zurückwechseln werde.
Da fehlen mir unter Umständen zu viele Features wie Decoupling-Schutz bei den Heizelementen usw.
LG

Wenn du mich so fragst, ist meine Antwort mit keiner.

Warum diese Antwort?
Das Z Lift Problem hatten wir schon immer, auch in der FW von Conrad.
Ab dem Zeitpunkt wo du etwas daran geändert hattest, fährt das Bett bei einem Fehler nun
anstatt einen Layer zu viel abwärts einen Layer zu weit hoch und druckt zwei Layer auf der gleichen Höhe.
Ab diesem Zeitpunkt sehe ich unsere FW als kritisch an.
Doch leider würde mein Drucker ohne Rückbau mit einer alten FW,
heute gar nicht mehr funktionieren.
Ich möchte auch nicht auf die Verbesserungen verzichten müssen.

Darum mein Vorschlag:
Belasse die FW 1.43.20 als Stable, mache einen Versions Hinweis auf das bekannte Problem.
Mir fehlt halt dort nur der Kickstart zum Kondensator laden.
Für mich stellt sich nun die Frage, ob ich meine Lüfter Elektronik nachbessere,
oder ich noch den Kickstarter in dieser alten Stable FW bekommen?

Von den Nachfolgenden FW´s bin ich nicht so begeistert, wir hatten uns gestern grob darüber unterhalten.
Ich befürchte immer noch, dass die mit dem Schutzleiter zusammengeführte Masse zu Problemen führen kann.
Das wird bald bei mir geändert, mit dem Einbau eines anderen Netzteils (Zeitprobleme).

Das mit dem Raspberry-PI ist natürlich nicht verdrängt.
Sollte es noch ein paarmal Rasseln in meiner Kiste, werde ich wohl so ein Ding einbauen müssen.
Mal schauen.

LG AtlonXP

Soweit ich mich erinnere habe ich damals gepostet was ich wegen dem Kickstarter geändert hatte
Wenn da im Thread tatsächlich ein Link zu einem "Commit" war kannst du dir das auch selbst so hin ändern. (Website öffnen, Dateien durchgehen, alles rote raus, alles grüne rein und fertig.)

Ich mach aber an alten Versionen nichts mehr. Meine Zeit ist beim verbessern der aktuellen Version besser aufgehoben.
- Auf Platz 1 meiner Liste steht aktuell, dass ich M3070 reparieren will.
- Wir können auch drüber nachdenken, dass man Zusatz-Extrusion (über die Knöpfe) während dem Drucken nicht über eine Unterbrechung des Druckens sondern über die temporäre überhöhung des Flows regelt. Dann stockt das nicht mehr wenn man den Knopf drückt. Wir könnten z.B. versuchen die FW so umzuschreiben, dass solange man den Knopf für Extrudieren während dem Drucken drückt der Flow auf 200% steht und nicht am Punkt des Klicks eine bestimmte Menge sofort extrudiert wird.

Dein http://www.rf1000.de/wiki/index.php/Dig ... mpensation hat übrigends gestern bei Marius nicht funktioniert weil SenseOffset nicht aktiv war. Zumindest ist das mein 96% Verdacht. Das hatten wir ihm erst später am Abend aktiviert.

Nibbels hat geschrieben:
- Wir können auch drüber nachdenken, dass man Zusatz-Extrusion (über die Knöpfe) während dem Drucken nicht über eine Unterbrechung des Druckens sondern über die temporäre überhöhung des Flows regelt. Dann stockt das nicht mehr wenn man den Knopf drückt. Wir könnten z.B. versuchen die FW so umzuschreiben, dass solange man den Knopf für Extrudieren während dem Drucken drückt der Flow auf 200% steht und nicht am Punkt des Klicks eine bestimmte Menge sofort extrudiert wird.

Manuell hatte ich es auch schon mit dem Hauptmultiplikator versucht (150 %).
Der Effekt war aber nicht der Gleiche, wie wenn ich von Hand drücke.
Meine Vermutung, es hängt auch mit der Startzeit der Exdrusion zusammen.
Man muss es testen.

Nibbels hat geschrieben: Dein http://www.rf1000.de/wiki/index.php/Dig ... mpensation hat übrigends gestern bei Marius nicht funktioniert weil SenseOffset nicht aktiv war. Zumindest ist das mein 96% Verdacht. Das hatten wir ihm erst später am Abend aktiviert.

He He, wenn ich wo hin lange, dann sind meine Finger gleich braun.

Nun gut, ich werde dann nach dem Link suchen müssen.

LG AtlonXP