Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

[Nibbels]

Danke für deine Rückmeldung!

Die offizielle 1.42 findest du auf der Produktseite in der Zip mit der "Software".
https://www.conrad.de/de/renkforce-rf20 ... 63098.html
Die Version sollte man auch auf den RFx000 einsetzen können, nicht nur am RF2000v2. Zumindest meine ich das.

Ich muss das Verhalten reproduzieren können, um es zu beheben.
Könntest du mir dein EEPROM-Settings-Log und den GCode zukommen lassen? Evtl. mit Hinweis, wann das passiert?

LG

[Nibbels]

Ich muss mich auch mal zu wort melden. Ich habe gestern von der offiziellen 1.37er FW auf die aktuelle 1.42er Community FW umgestellt. An den Einstellungen habe ich ansonsten nichts verändert, jeweils die defaultwerte.
Die Beschleunigungswerte in der Community-FW sind scheinbar sanfter eingestellt (ich habe die alten vergleichswerte nichtmehr). Aber ab und an - je nach Objekt alle 1-2 Layer - gibt es einen bewegungsschritt, wo der Drucker jegliche Beschleunigungswerte ignoriert und die Bewegung sehr "hart" fährt - man hört das in dem moment und der ganze Tisch, auf dem der Drucker (RF 1000 übrigens) steht, ruckt bei mir einmal relativ stark. Versatz tritt dennoch nicht auf, aber es kann ja durchaus sein dass der ein oder andere Stepper hier nicht mitkommt? Es klingt jedenfalls nicht sehr gut und materialschonend ist das ganze sicher auch nicht.

Die gleichen Gcode-dateien mit der alten FW zeigte dieses Verhalten nicht. Habt ihr eine Idee was ich tun kann?

Übrigens: wo finde ich die originale Conrad-1.42er-Firmware? Oder gibt es die für den RF1000 gar nicht mehr?

Hey

Es wäre echt absolut spitze, wenn du mich mit den Settings und evtl. deinem GCode versorgen könntest.
Unter Umständen sehe ich sofort den Fehler. Dann kann ich den Fehler suchen oder eine Autokorrektur für diese Settings bauen.
Ich nehme an, du hast die 1.42.22 oder 1.42.23 benutzt?

Ich versuche zwar, den Drucker von mir genau zu beobachten, habe das Problem aber bisher nicht bemerken können. (?)
Das könnten halt spezielle Slicer-Settings sein, die das auslösen. Schön ist es natürlich nicht, darum würde ich dem gerne auf den Grund gehen.

LG

[rivadynamite]

Sorry für die späte Rückmeldung. Ich habe die 1.42.22 benutzt, allerdings aktuell wieder die 1.38er Original-FW drauf, da ich einige Druckobjekte dringend brauche - die haben gerade priorität 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!

[Nibbels]

Noch ein Gedanke...

Es gab ne Version, da habe ich den theoretischen Max-Speed des Druckers durch ne Codeoptimierung aufgebohrt. Und bald drauf, die Standardsettings fürs Homing anpassen müssen, weil dann Geschwindigkeiten erreicht werden konnten, die vorher einfach nicht möglich waren.
(Bei sehr hohen Stepraten fällt auch das Motormoment ab und darum gabs bei AtlonXP auf einmal Steppverluste beim Z-Homing.)

Du schreibst aber explizit, dass die Beschleunigung falsch wäre. Ich halte das im Hinterkopf und achte verstärkt drauf.

Lg

[Nibbels]

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

[nikibalboa]

Hallo,

Ich hab jetzt endlich mal wieder Zeit gefunden um mich mit meinem Drucker zu befassen.

Ich hab die 1.43.11 am Rf1000 drauf und habe folgendes Problem festgestellt, wenn man nach einen abgebrochenen druck aus dem Druckermenü wieder eine Taste betätigt beim mir die Menü taste werden die x/y Achsen unwillkürlich angefahren bis sie am Anschlag treffen und der Stepper überdreht.

Gedruck wurde über repetier host.

Lg

Nikibalboa

[Nibbels]

Dann versteht der Repetier-Host den "Stop-Befehl" nicht und sendet weiter GCodes. Du hast zu dem Zeitpunkt kein Homing mehr. (Und es ist nicht klar, ob die Koordinaten relativ oder absolut sind ... Crash möglich)
Bricht man im Drucker ab, werden fortan alle Gcodes mit Bewegungen ignoriert, ausser man hat ein neues Homing durch G28 bekommen. Dann sind Bewegungen wieder erlaubt.
Drückst du am Drucker eine Taste, schaltest du die Achsen ebenfalls frei.

Kannst du damit was anfangen?
Welche Version von Repetier-Host? Mein Repetier-Server versteht die Kommandos.

LG

[AtlonXP]

Hallo zusammen,
dieses Problem hatte ich anfänglich auch und habe mir deshalb angewöhnt, den Druck mit dem Not Aus am Slicer abzubrechen.
Dann kommt es nicht mehr vor.

Wenn man das so macht, dann darf man sich auch über den Idiotenknopf aufregen,
weil der dann nicht mehr gebraucht wird.

LG AtlonXP

[nikibalboa]

Ich habe die 1.6.2 drauf da ich in neueren Versionen Probleme beim Fräsen hatte. Okay ich verstehe das Problem danke, kann man repetier host solche Befehle "beibringen"?
In Zukunft werde ich mit octoprint mein Glück versuchen aber leider funktioniert die sorglos image nicht am 3b+.
Ich vermute da kann es dann auch zu solchen Problemen kommen.

Lg nikibalboa

[Nibbels]

Wenn man einen Druck per USB am Drucker im Menü abbrechen will, muss der Host verstehen, dass er aufhören muss.
Das ist leider kein Standard.

Früher war es normal, dass man USB-Drucker auch am Rechner abbrechen musste.
Wir haben im Mod die Möglichkeit geschaffen, weil ich es praktisch fand. Das funktioniert mindestens bei Repetier-Server und Octorpint.
Repetier-Host habe ich nie ausprobiert.
Das zu wissen, ist daher ziemlich spannend.

Beispiele für die Upstream-Commands:
// action:cancel -> Octoprint Stop-Befehl
RequestStop: -> Repetier-Server Stop-Befehl

Früher gabs bei Octorprint nur "// action:disconnect", aber das hat gleich die USB-Verbindung ganz gekappt ^^. Man musste neu einstecken. Darum haben wir bei Gina Häußge / Octoprint mit der Begründung angefragt, dass man dann Funktionsgleiche Upstream-Befehle bei beiden Gcode-Sendern Octorprint <-> Repetier-Server hätte und sie hat uns das eingebaut
https://github.com/foosel/OctoPrint/issues/2367

(Würdest du dem Drucker nach dem Abbruch genügend Zeit lassen, bevor du wieder eine Taste drückst, dann müssten vom Repetier-Host alle G1 xx Gcodes durch die Leitung rasen, bis der Druck fertig ist. Man muss dann halt geduldig sein.)

LG