Kleines Update zum Stand.
Wir reden hier schon von der 1.43.11, die zur Zeit nur auf meinem privaten Github liegt. (https://github.com/Nibbels/Repetier-Firmware)
Ich hatte immer wieder Meldungen und Verdachtsfälle, dass irgendwas nicht ganz sauber funktioniert.
- Microruckler (Dazu gibts diverse Ursachen, die man nicht alle in einen Topf werfen kann.)
- Reset beim Homing
- Einer Person ist manchmal das Hotend vom Teil weggefahren und wieder zum Teil hin.
(- Z-Lift-Problematik?)
Doch ich selbst hatte aber bisher keinen Fall, bei dem ich diese Probleme wirklich nachvollziehen konnte.
Einzig: Wenn ich die Interrupt-Speed-Timings wieder richtig mies einstelle - annähernd so wie früher - dann konnte ich diese Resets beim Homing nachstellen.
Die Systematik, wie dieser Reset zustande kommt, ist mir klar. Warum manche Drucker sensibler sein könnten auch: Toleranzen im Watchdog-Chip(?). Das Datenblatt unseres Watchdog schließt sowas zumindest nicht aus.
-> Wir müssen also diese Interrupt-Maximal-Rate so begrenzen, dass immer genügend Rechenzeit zwischen den Interrupts frei bleibt, um andere Berechnungen auszuführen. Das gibt uns eine Step-Raten-Grenze vor. Diese allein würde uns in der Druckgeschwindigkeit (oder die maximalen Microsteps) limitieren.
Doch es gibt diesen Tick mit Double-Quad-Octa-Stepping.
Genau dieses Feature hatte ich in den letzten Tagen so umgebaut, dass nicht mehr nur 1,2,4,8 Steps in einem Interrupt erledigt werden, sondern genau so viele, wie benötigt werden um den minimalen Interrupt-Abstand einzuhalten. (1,2,3,4,5,6,...)
(In den Druckermenüs sieht man nicht mehr Sgl->Dbl->Qud->Oct, sondern 1ST, 2ST, ...)
Mir gefällts, der Drucker druckt.
Man stellt nun nicht mehr die Maximale Steprate ein, sondern quasi ihren Kehrwert, den minimalen Zwischen-Interval. Standardwert in Menü->Configuration->Stepper->ShiftIntrvl ist 2900
Macht man den Wert größer, haben Hintergrundberechnungen "mehr Luft". Je höher der Wert, desto schneller lässt sich z.B. das Menü bedienen, während der Drucker stepintensive/schnelle Bewegungen ausführt.
Ausserdem haben wir die maximalen Geschwindigkeiten für Z sauberer eingestellt.
Was der Großteil dieser Meldungen gemeinsam hatte, ist, dass von SD-Karte gedruckt wurde.
Darum gewöhne ich mich gerade wieder etwas daran, von SD zu drucken. Trotzdem: Bei mir funktionierts!
Ein Verdacht drängt sich mir aber auf, nachdem ich einige Fehlerbilder gesehen habe. Es könnte sein, dass die Datenübertragung zwischen dem Drucker und manchen SD-Karten ein Problem haben könnte.
Darum habe ich mich weiter eingelesen und einen CRC-Check für die Datenübertragung von und zur SD aktiviert.
Das war auch kein Hexenwerk, man muss das nur wissen: SdFatConfig.h in Zeile 113
#define USE_SD_CRC 0 -> #define USE_SD_CRC 2
Nun sollte, falls irgendwas die Übertragung auf dem Board stört "SD Read Error" im Logfile auftauchen. Anschließend dann "SD error did not recover!" oder "SD Error fixed". Ich bin mir zu 95% sicher, dass der Drucker normal weiterdruckt als wäre nichts gewesen, wenn man dort "SD Error fixed" lesen würde. Verfälschte Daten dürften es nun nicht mehr bis in den GCode-Parser schaffen.
Das sind nun zwei spannende Änderungen, doch was die einzelnen Ursachen der verstreuten Fehlermeldungen sind, die bei mir eingetrudelt sind, kann ich weiter nicht genau einordnen.
Ich hoffe aber, dass wir nun ein paar mögliche Ursachen eliminieren konnten.
LG
Werde aber bei nächster Gelegenheit nochmal die Mod-FW installieren und Dir dann (wenn ich die Auffälligkeit dann nochmal rekonstruieren kann) die geforderten Daten liefern!