Bugs in Firmware RF.01.11 (RF1000)

[mhier]

Hallo,

ich finde immer noch Bugs in Firmware RF.01.11 beim RF1000, die sie für mich praktisch unbrauchbar machen. Leider sind die Bugs diesmal nicht so klar reproduzierbar, deswegen kann ich keine so eindeutige Beschreibung liefern. Ich beobachte folgende Probleme:

• Der Heatbett-Scan funktioniert zwar irgendwie, aber die Kompensation beim Druck nicht richtig. Obwohl im Display negative z-Werte angezeigt werden während des ersten Layers ist der Abstand konsequent zu groß. Im "Trocken-Test" habe ich beobachtet, dass nach Einschalten der z-Kompensation nur einmal der z-Referenzschalter überfahren werden kann (z.B. via G01 Z0.2), ab dann sind aber nur Bewegungen in positive Z-Richtung möglich. Es scheint aber trotzdem nicht zu helfen, die Z-Kompensation dann wieder einzuschalten, wenn man erneut auf die Höhe des ersten Layers möchte...
• Manchmal fährt die Firmware nach dem z-Homing wieder ein Stück in Richtung z > 0 (ca. 0.5 bis 1mm). Leider wird diese Position dann als z=0 festgelegt, wodurch die erste Layerhöhe wieder überhaupt nicht stimmt.
• Die Einstellung mit beiden z-Endschaltern (circuit) ist immernoch stark verbuggt und führt gelegentlich (eher häufig) dazu, dass der Drucker einen normalen Endschalter zerstören würde. Meiner hält das inzwischen zum Glück aus, gut ist das trotzdem nicht... Insbesondere wenn der Drucker bei z=0 mit gedrücktem Endschalter steht scheint er sich unter bestimmten Umständen für die falsche Endstellung zu entscheiden. Hier muss dringend ein schlaues Konzept her, wie der Drucker herausfindet, an welchem Ende er sich befindet.
• Manchmal werden die Motoren plötzlich extrem laut (auch im Halte-Zustand). Vielleicht ist irgend eine Ansteuerfrequenz zu niedrig, wodurch das übliche hohe Fiepen zu einem lauten Ton wird - jedenfalls ist die Frequenz, die man hört, viel tiefer als was die Motoren sonst so von sich geben. Dieser Zustand hält so lange an, bis die Motoren ausgeschaltet werden. Anfangen kann es jederzeit bei einer Bewegung, es ist aber eben nicht reproduzierbar (aber recht häufig).
• Wenn man im Menü oder per Hoch-/Runter-Tasten im Bedienfeld die Position (in allen Achsen) verändern möchte, während man gerade nicht druckt, passiert dies instantan mit sehr hoher Geschwindigkeit. Das ist nett, wenn man damit sein Objekt aus dem Drucker holen möchte, macht die Firmware aber unbrauchbar zum Fräsen etc., da man dann ja irgendwie sehr exakt den xy-Nullpunkt anfahren muss. Die alte Lösung war zwar nicht schön, aber wenigstens brauchbar. Besser wäre, so langsam wie früher anzufangen aber auf die neue hohe Geschwindigkeit nach einiger Zeit zu beschleunigen.

Alles in allem ist die einzige halbwegs brauchbare Firmware immer noch die 0.91.59, auch wenn da die Probleme mit den beiden Endschaltern auch schon vorhanden waren. Leider habt ihr im Sourcecode so viel umstrukturiert und die Verzeichnisstruktur so geändert, dass ich euch beim Debuggen nicht helfen kann - ich hab es ernsthaft versucht, aber ich steige durch die Änderungen nicht durch, weil git mit eurer neuen Verzeichnisstruktur nicht klar kommt.

[rf1k_mjh11]

mhier,

Da gibt es einiges zu sagen:

...

• Der Heatbett-Scan funktioniert zwar irgendwie, aber die Kompensation beim Druck nicht richtig. Obwohl im Display negative z-Werte angezeigt werden während des ersten Layers ist der Abstand konsequent zu groß. Im "Trocken-Test" habe ich beobachtet, dass nach Einschalten der z-Kompensation nur einmal der z-Referenzschalter überfahren werden kann (z.B. via G01 Z0.2), ab dann sind aber nur Bewegungen in positive Z-Richtung möglich. Es scheint aber trotzdem nicht zu helfen, die Z-Kompensation dann wieder einzuschalten, wenn man erneut auf die Höhe des ersten Layers möchte...
• Manchmal fährt die Firmware nach dem z-Homing wieder ein Stück in Richtung z > 0 (ca. 0.5 bis 1mm). Leider wird diese Position dann als z=0 festgelegt, wodurch die erste Layerhöhe wieder überhaupt nicht stimmt.

....

Zum ersten Punkt, das Anfahren eines geringen Z-Werts nachdem man einmal höher war:
Da gibt es einen ellenlangen Thread, hier und hier. Wahrscheinlich noch mehr, aber ich will sie nicht alle heraussuchen. Ich biete in einem der Beiträge irgendwo eine Lösung an.

Zum zweiten Punkt, dem skurrilen Z-Verhalten am Anfang eines Drucks kann ich nur sagen - das beobachte ich schon seit der v0.91.33 immer wieder (auch bis zur .51, weiter bin ich noch nicht). Ich habe schon öfters mit RF1000 per privater Nachricht über das Thema kommuniziert. Es gibt mehrere Tipps, um die Wahrscheinlichkeit des Phänomens zu reduzieren.
a) Nach dem Homing unbedingt ein M400 einbauen, damit garantiert alle Bewegungen fertig sind, bevor die Z-Kompensation eingeschalten wird (habe ich auch wo geschrieben, bekam den Tipp vom RF1000).
b) Als letztes kann man nach dem Homing noch dezidiert die Z-Koordinate als "Null" festlegen, mit "G92 Z0". (gibts auch irgendwo einen Beitrag von mir, auch ein Tipp von RF1000).

Der Punkt mit dem schnellen Verfahren in Z ist auch bekannt und wurde schon mehrfach bemängelt. Ebenso die Problematik mit der Erkennung der zwei Z-Endschalter.
Das laute Motorengeräusch scheint neu.

mjh11

[riu]

Bezüglich der lauten Motoren. Schalte mal in der Firmware die Stromabsenkung im Stillstand aus. Dann sollte das "Fiepen" leiser werden. Die Motoren haben mechanisch nur die Möglichkeit Halbschritte zu machen. Alles dazwischen wird mit getakteten impulsen realisiert, daher das pipen, was bis zu einem gewissen Grad normal ist.

Ich habe an meiner Fräse digitale 5A Leadshine Endstufen die 1/64 Schritte können und die Stepper 1,8º also 720 Vollschritte pro Umdrehung können. Da piept z.B. nichts.

Lieben Gruß,
Udo

[Zaldo]

Alles dazwischen wird mit getakteten impulsen realisiert, daher das pipen, was bis zu einem gewissen Grad normal ist.

Ja schon, aber die .48 (die ich längere Zeit benutzt hatte) und die .59 haben dieses "Problem" nicht. Daher hatte ich ja schonmal die Vermutung geäußert, dass an den Motoralgorithmen gedreht wurde. Da gabs aber leider nie eine Rückmeldung.

[rf1k_mjh11]

Udo,

Gehört nicht in diesen Thread, aber ...

....1/64 Schritte können und die Stepper 1,8º also 720 Vollschritte pro Umdrehung können.

Müssten 0.5° sein, für 720 Schritte. Die 1.8° haben 'unsere' Motoren schon ...

mjh11

[mhier]

Zum ersten Punkt, das Anfahren eines geringen Z-Werts nachdem man einmal höher war:
Da gibt es einen ellenlangen Thread, hier und hier. Wahrscheinlich noch mehr, aber ich will sie nicht alle heraussuchen. Ich biete in einem der Beiträge irgendwo eine Lösung an.

Achso, ich hatte das so verstanden, dass das Problem erst auftritt, wenn der Endschalter "losgelassen" wird. Bei mir tritt das sofort auf, auch wenn der Endschalter gedrückt bleibt.

Zum zweiten Punkt, dem skurrilen Z-Verhalten am Anfang eines Drucks kann ich nur sagen - das beobachte ich schon seit der v0.91.33 immer wieder (auch bis zur .51, weiter bin ich noch nicht). Ich habe schon öfters mit RF1000 per privater Nachricht über das Thema kommuniziert. Es gibt mehrere Tipps, um die Wahrscheinlichkeit des Phänomens zu reduzieren.

Also M400 habe ich seit eh und je drin. Die Beobachtung ist, dass mit den selben Slicer-Einstellungen es bei der neuen Firmware nicht geht, mit der alten schon. Hier liegt klar ein regression bug vor. Insbesondere funktioniert das Homing selbst schon dann nicht zuverlässig, wenn ich es von Menü aus starte. Das hat gar nichts mit G-Codes zu tun und es gibt auch keinen Work-Around dafür. Er fährt ganz einfach *manchmal* nach erfolgtem Homing noch direkt ein kleines Stück und interpretiert das anschließend als z=0. Da das rein zufällig passiert, kann man da nichts gegen machen.

Der Punkt mit dem schnellen Verfahren in Z ist auch bekannt und wurde schon mehrfach bemängelt. Ebenso die Problematik mit der Erkennung der zwei Z-Endschalter.

Ich weiß, ich wollte es trotzdem noch mal erwähnen. Bisher habe ich keine Reaktion von Conrad darauf gesehen. Ich wollte noch einmal deutlich sagen, dass die aktuelle Version der Firmware zumindest für viele unbrauchbar ist.

Das laute Motorengeräusch scheint neu.

Ich habe davon schon irgendwann mal hier im Forum gelesen, ich finde es aber gerade nicht wieder. Mir ist klar, dass ein piepen normal ist. Wie beschrieben, ist es aber mit der neuen Firmware manchmal ein piepen sondern ein sehr lautes brummen. Ich weiß nicht ob es den Motoren oder den Treibern schadet, aber es klingt auf jeden Fall nicht gut. Es ist definitiv ein neues Phänomen und tritt wieder einmal nicht reproduzierbar *irgendwann* auf. Deswegen glaube ich kaum, dass es sich um eine absichtliche Änderung in der Ansteuerung der Motoren handelt sondern ebenfalls um einen Bug. Vielleicht werden unter gewissen Umständen die PWM-Frequenzen falsch eingestellt?

mjh11[/quote]

[Zaldo]

Zum ersten Punkt, das Anfahren eines geringen Z-Werts nachdem man einmal höher war:
Da gibt es einen ellenlangen Thread, hier und hier. Wahrscheinlich noch mehr, aber ich will sie nicht alle heraussuchen. Ich biete in einem der Beiträge irgendwo eine Lösung an.

Achso, ich hatte das so verstanden, dass das Problem erst auftritt, wenn der Endschalter "losgelassen" wird. Bei mir tritt das sofort auf, auch wenn der Endschalter gedrückt bleibt.

Hatte ich schon mehrmals geschrieben dass das so ist, und dass RF1000 dieses Verhalten auch bestätigt hat.

Das laute Motorengeräusch scheint neu.

Ich habe davon schon irgendwann mal hier im Forum gelesen, ich finde es aber gerade nicht wieder. Mir ist klar, dass ein piepen normal ist. Wie beschrieben, ist es aber mit der neuen Firmware manchmal ein piepen sondern ein sehr lautes brummen. Ich weiß nicht ob es den Motoren oder den Treibern schadet, aber es klingt auf jeden Fall nicht gut. Es ist definitiv ein neues Phänomen und tritt wieder einmal nicht reproduzierbar *irgendwann* auf.

Hatten ich und andere ebenfalls schon mehrmals angemerkt.

Mich beschleicht das Gefühl, Conrad wollte mit diesem Release die Nabelschnur durchschneiden, und sich deutlich von der Repetier Firmware distanzieren. Es hat ja auch komplexere Codeumlagerungen von der einen in die andere Datei gegeben. Scheint so als wäre das in die Hose gegangen.

Ich werde wohl noch ziemlich lange bei der .59 bleiben.

[mhier]

So, den letzten meiner Punkte habe ich nun selbst gefixed, siehe mein Fork der Firmware:
https://github.com/mhier/Repetier-Firmware

Damit kann ich die RF.01.11-Version schon mal wieder zum Fräsen verwenden (was anderes geht bei mir im Moment ja eh nicht wegen dem defekten Hotend).

[RFrank]

Mir fiel noch folgendes auf:
1) Motorenabstimmung verschlechtert (bekannt)
2) Benutzung über USB (Repetier mit Slic3r)

Bei Unterbrechung zum Drucker (z. B.: Reset durch Not-Aus) werden nach Wiederfreigabe weitere Befehle von Repetier übertragen.

Das heißt der Drucker fährt unter Umständen undefiniert los.

Gruß Frank

[mhier]

Mit Motorenabstimmung meinst du die lauten Geräusche (4. Punkt in meinem Post)? Oder ist das noch etwas anderes?

Bzgl. dem Not-Aus, war das Problem bei der alten Firmware (.59 z.B.) nicht vorhanden? Falls es da nicht war, wie hat sich Repetier Host dann verhalten, hat er gemeldet dass die Verbindung unterbrochen ist und dann aufgegeben? Falls es doch auch in der alten Version vorhanden war, ist es vielleicht eher ein Problem mit dem Repetier Host. Der muss irgendwie mitkriegen, dass der Not-Aus-Kopf gedrückt wurde. Sonst denkt er nur, die Verbindung wäre kurz unterbrochen gewesen und sendet weiter Befehle. Dagegen kann die Firmware wenig machen...