• Bugs in Firmware RF.01.11 (RF1000)

rf1k_mjh11 hat geschrieben:
ABER das ist gar nicht der springende Punkt. Ist der Motor einmal stromlos und bekommt wieder Strom, springt der Rotor zum nächstgelegenen Halb- oder Ganzschritt. Das macht dann bis zu 0.00625mm Höhenunterschied aus (0.0125 durch 2). Ist nicht die Welt, aber Theorie ist Theorie. Dieser Sprung kann in die eine oder andere Richtung stattfinden.

Wir reden davon, dass ein Sprung von 200mm stattfinden muss, dass dem Drucker nicht mehr klar ist, welcher der beiden Endstopps denn wohl aktiv ist. Also z.B. oberer Endstopp ist aktiv, Stepper werden deaktiviert und irgendwie wird das Bett nach ganz unten bewegt, so dass der untere Endstopp aktiv wird. Das ist das einzige Szenario, in dem der Drucker wirklich nicht mehr weiß, welcher der aktive Endstopp ist.

Zaldo hat geschrieben:Das könnte sie schon. Bei aktivierter Z-Kompensation und durchgeführten HBS ist der Abstand [an den Scanpunkten] zwischen Extruder und Bett sehr genau bekannt [dazwischen wird interpoliert]. Diesen Abstand müsste man nur zur Variable welche den Z Wert für die Displayausgabe enthält, dazuaddieren.

Das ist ganz exakt die gleiche Koordinate, wie sie im G-Code steht. Letzlich ist es nämlich umgekehrt, der Drucker wird auf eine gewisse z-Position gefahren, zu der unmittelbar vor Berechnung der zu fahrenden Schritte die z-Kompensation hinzuaddiert wird. Man muss eigentlich nur für die Anzeige eben den Wert vor Hinzuaddieren der z-Kompensation nehmen.

Zaldo hat geschrieben: Vielleicht kann mir ja auch jemand sagen, in welchem Modul die Displayausgabe erfolgt, zur not tu ich mir den Offset (der ja im wesentlichen vom mechanischen Abgleich abhängt und daher weitgehend konstant ist) hardcoden.

In der RF.01.11 wird der angezeigte Z-Wert in der Funktion Printer::currentZPosition() ermittelt. Diese beginnt in Zeile 1038 von Printer.h.

Die Bedeutung der von der Firmware für die Positionierung verwendeten Variablen ist in RF.h ab Zeile 182 beschrieben.

mfG
RF1000

Ich habe zwar weiterhin die .59 aber anhand dieser Infos werde ich es dort ebenfalls finden, Danke!

Ich habe gerade in meinem Fork-Repository (https://github.com/mhier/Repetier-Firmware) einen Fix für meine Probleme mit den nicht übernommenen Koordinaten von Menü veröffentlicht. Damit geht das Fräsen für mich jetzt wieder.

Interessanterweise habe ich seitdem auch nicht mehr den Effekt, dass die Motoren so laut werden. Ich verstehe aber nicht, wie das zusammenhängen könnte. Vielleicht war das auch Zufall?

Vermutlich war es das. Als ich die 01.10 (seinerzeit noch) mal getestet hatte, hatte ich an einem Tag das laute Motorengebrumme gefühlt nach jeder dritten Motorenbewegung. Andern tags wollte es es mir partout nicht gelingen es zu reproduzieren. Man mochte schon an Wunderheilung glauben als es nach Stunden dann plötzlich doch wieder einmal auftrat.

Schade nur, dass man sich seitens des CTC so bedeckt hält, was man da überhaupt geändert hat (im Vergleich zur .59)

Hallo mhier

mhier hat geschrieben: [*] 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.

Nachdem ich seit Tagen einen ABS-Druck in der Einhausung vollenden möchte und immer wieder nach ein paar Stunden Probleme habe (soll hier aber nicht Thema sein), wechselte ich gestern die Düse.
Damit mußte ich einen neuen Heatbed-Scan und vorher den neuen Nullpunkt am Z-Schalter ermitteln.
Ich ging als so vor wie immer. Home-All; alle Motoren ausschalten; Papier als Fühlerlehre unter die Düse; Höhenverstellung des Z-Schalters lösen

Und dann passierte folgendes: Beim Kontaktieren des Z-Schalters (Unterbrechung der Lichtschranke) fuhr der Drucker das Bett ca. 0,5mm in Richtung Düse (Möglicherweise auch ein Mini-Homeing) und der Motor der Z-Achse bleibt bestromt und lässt sich nicht mehr ausschalten.
Ich glaubte es nicht! Drucker wieder ausgeschaltet, eingeschaltet und einfach den Z-Schalter betätigt und erneut fährt der Drucker ohne Befehl.

Das passt zu deiner Beobachtung und das schlaue Konzept sind diese ca. 0,5mm Hub (funktioniert allerdings nur gut, wenn der Drucker im unteren Endschalter steht, um den RF1000 frei zufahren).

Meine Konfiguration: Endschalter auf Kreis/Circle (Notwendige Umrüstung fürs Fräsen)

Nach Umschaltung des Endschalter auf "Einfach" konnte ich meinen Z-Schalter wieder einstellen.

Wenn ein solcher Mini-Sicherheitshub gefahren werden soll, dann nur "EINMAL" am Anfang, innerhalb der Inititialisierungsroutine und nicht Minuten später, wenn man wie ich, den Schalter justiert.
Die Idee dieser Programmsequenz könnte sein:
1) Schutz des unteren Schalters vor Überfahren
2) Freifahren der Maschine beim Einschalten (Ist der Schalter nach 0,5mm immer noch gedrückt ist es der obere Schalter [Bett oben], ist der Z-Kontakt frei ist der untere Schalter und Bett ist unten)

Zum Ausprobieren Drucker in mittlere Position fahren, Schalter auf Kreis/Circle [Menü: Konfiguration/Allgemein/Z Typ] und den Z-Schalter betätigen.
Der Drucker fährt ein Stück (ca. 0,5 mm) und hält diese Z-Position. Der einzige Befehl scheint dann der Home-All, der dann noch funktioniert.
Alles ohne Gewähr und Garantie und eigene Gefahr!!!

Gruß an die Gleichgesinnten
Frank

Zaldo hat geschrieben: Vermutlich war es das. Als ich die 01.10 (seinerzeit noch) mal getestet hatte, hatte ich an einem Tag das laute Motorengebrumme gefühlt nach jeder dritten Motorenbewegung. Andern tags wollte es es mir partout nicht gelingen es zu reproduzieren. Man mochte schon an Wunderheilung glauben als es nach Stunden dann plötzlich doch wieder einmal auftrat.

Schade nur, dass man sich seitens des CTC so bedeckt hält, was man da überhaupt geändert hat (im Vergleich zur .59)

An den Motoreinstellungen hat sich nichts geändert. Stattdessen hat sich in Zeile 1926 von motion.cpp ein Fehler eingeschlichen. Dort steht:

Code: Alles auswählen

else if( Printer::directPositionCurrentSteps[X_AXIS] > Printer::directPositionTargetSteps[E_AXIS] )

Dort sollte aber stehen:

Code: Alles auswählen

else if( Printer::directPositionCurrentSteps[X_AXIS] > Printer::directPositionTargetSteps[X_AXIS] )

Das hat dazu geführt, dass die Firmware manchmal 4 Schritte in x-Richtung gefahren ist, wenn man eigentlich über das Menü bzw. die Hardwaretaster in y- oder z-Richtung fahren wollte. Gebrummt hat immer der x-Motor, weil diese 4 Schritte nicht geplant und korrekt gefahren worden sind. Man konnte diese Minibewegung auch bei der x-Positionsangabe sehen, wenn man eine Bewegung in y- oder z-Richtung durchgeführt hat.
Wir werden das in der kommenden Version der Firmware natürlich mit korrigieren, wenn jemand möchte kann er das aber bei seiner Firmware schon einmal vorab ausbessern.

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

Die "komplexen Codeumlagerungen" haben den Zweck, dass die selbe Firmware sowohl für den RF1000 als auch für den RF2000 verwendet werden kann. Wie kannst du aus dem bisherigen Motorbrummen schließen, dass die gesamte neue Firmware "in die Hose gegangen" ist?

Es steht natürlich jedem frei ob er bei unserer V 0.91.xx bleiben oder zur RF.01.yy hochrüsten will. Weiterentwickelt wird aber natürlich nur die RF.01.yy, und wenn sich jemand tatsächlich die Mühe macht die Sourcen der V 0.91.xx mit jenen der RF.01.yy zu vergleichen dann denke ich, dass dabei herauskommt, dass die RF.01.yy für die Anwender von RF1000 und RF2000 Geräten ein signifikanter Schritt in die richtige Richtung ist.

mfG
RF1000

RF1000 hat geschrieben:Wie kannst du aus dem bisherigen Motorbrummen schließen

Da waren noch ein paar mehr Ungereimtheiten aufgezählt, als nur das Motorbrummen

Hallo

Hat jemand einen Heatbed-Scan mit einer eingeschalteter Heizung erfolgreich absolviert bekommen?
Zur Zeit ist nur ein ein Scan mit abgeschalteter Heizung (Bett und Extruder) machbar.

Änderungen in der Software (Längeres Timing, mehr Zyklen) brachten keinen Erfolg.

Es ist als ob der Wert einfriert, die Sensoren geben keine brauchbaren Werte und dann erfolgt der Abruch.

Grüße Frank

Frank/RFrank,

Meinst du mit einem RF1000 und der neuen Firmware?

Wenn es sehr wichtig ist (d.h. keiner sonst meldet sich), kann ich meinen kurzfristig umflashen (habe noch die 0.91.51 drauf).

mjh11

Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)

Re: Bugs in Firmware RF.01.11 (RF1000)