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.
Kannst du dazu in der Zwischenzeit Genaueres sagen? Passiert es z.B. von 10 Mal im Schnitt x Mal? Kann man dabei mittlerweile irgend ein Muster erkennen?mhier hat geschrieben: 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.
Kannst du dazu in der Zwischenzeit Genaueres sagen? Reden wir z.B. ausschließlich über den Druckmodus (weil im Fräsmodus wird Z=0 vermutlich nicht erreicht)? Passiert es bei dir nur nach dem Einschalten der Firmware, nach einem Druck, nach einem sonstigen Muster?mhier hat geschrieben: 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.
Leider noch nicht viel genaueres, da im Moment mein Extruder bei Euch in Reparatur ist... Im Fräsbetrieb habe ich jetzt die Beobachtung gemacht, dass er nach dem Homen (zum unteren Ende dann eben) das analoge Verhalten zeigt und sich unreproduzierbar wieder vom Z-Schalter entfernt. Im Debug-Output zeigt er dann - wenn ich das gerade richtig erinnere - eine Meldung wie "driving free" - was irgendwie keinen Sinn macht? Ich werde mir das in den nächsten Tagen noch mal genauer ansehen.RF1000 hat geschrieben:Hallo mhier,Kannst du dazu in der Zwischenzeit Genaueres sagen? Passiert es z.B. von 10 Mal im Schnitt x Mal? Kann man dabei mittlerweile irgend ein Muster erkennen?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.
Im Grunde sollte sich am Z-Homing von der V 0.91.xx auf die RF.01.yy nicht wirklich etwas getan haben.
Das passiert letztlich immer dann, wenn die Firmware kein gültiges Homing mehr hat aber einer der Endschalter gedrückt ist. Im Prinzip ist einfach das Konzept falsch. Die Firmware braucht intern ein Flag, welcher der Endschalter denn gerade gedrückt ist. Das kann sie *immer* wissen, außer sie wird mit gedrücktem Endschalter gebootet. Auch wenn die Stepper abgeschaltet werden, während der Endschalter gedrückt ist, kann sich die Firmware doch merken, welcher das ist. Das Heizbett kann ja nicht plötzlich auf magische Weise um 200mm an den anderen Endschalter fahren (außer jemand dreht von Hand am Zahnriemen - dann ist er halt selbst schuld, ist eh gefährlich wenn der Strom an ist). Wenn die Firmware mit gedrücktem Endschalter bootet, gibt es genau eine richtige Reaktion: Alles verweigern, was die Z-Achse bewegt außer der manuellen Bewegung über das Bedienfeld. Homing darf unter keinen Umständen ausgeführt werden in dem Zustand. Der Benutzer muss erst manuell (also per Tastendruck) in die richtige Richtung fahren, bis kein Endschalter mehr gedrückt ist. Alles andere ist 50:50 Glücksspiel!RF1000 hat geschrieben:Hallo mhier,Kannst du dazu in der Zwischenzeit Genaueres sagen? Reden wir z.B. ausschließlich über den Druckmodus (weil im Fräsmodus wird Z=0 vermutlich nicht erreicht)? Passiert es bei dir nur nach dem Einschalten der Firmware, nach einem Druck, nach einem sonstigen Muster?mhier hat geschrieben: 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.
Punkt 1 wird m.E. nirgendwo zufriedenstellend behandelt, weil es schlicht ein Bug ist. Der "Endschalter" muss letzlich komplett ignoriert werden, nachdem das Homing mal stattgefunden hat. Stattdessen sollte die Firmware wenn dann softwareseitig sicherstellen, dass keine Z-Positionen angefahren werden, bei denen der Extruder in das Heizbett fahren würde. Welche das ist, hängt aber von der x/y-Position ab, der "Endschalter" gibt hier keine Auskunft!An deinen Punkten 4 und 5 sind wir dran. Punkt 1 wird durch andere Threads behandelt, korrekt?
Nun. Wenn beide Z-Endschalter in einem Kreis zusammen geschlossen sind dann soll der Z-Endschalter immer frei gefahren werden - eben damit es nicht passieren kann, dass die Z-Achse stehen bleibt wenn der Z-Endschalter noch gedrückt ist.mhier hat geschrieben: Im Fräsbetrieb habe ich jetzt die Beobachtung gemacht, dass er nach dem Homen (zum unteren Ende dann eben) das analoge Verhalten zeigt und sich unreproduzierbar wieder vom Z-Schalter entfernt. Im Debug-Output zeigt er dann - wenn ich das gerade richtig erinnere - eine Meldung wie "driving free" - was irgendwie keinen Sinn macht? Ich werde mir das in den nächsten Tagen noch mal genauer ansehen.
Kannst du beschreiben, wie du in diesen Zustand kommst?mhier hat geschrieben: Das passiert letztlich immer dann, wenn die Firmware kein gültiges Homing mehr hat aber einer der Endschalter gedrückt ist.
Nach unten zu fahren ist in dem Zustand OK, weil beim unteren Endschalter nichts kaputt werden kann. Man kann in der Configuration.h FEATURE_ALLOW_UNKNOWN_POSITIONS auf 0 setzen - dann lässt die Firmware bei unbekannten Positionen (= nach dem Starten der Firmware bzw. nach jedem Ausschalten der Stepper) keine Bewegung außer dem Homing zu.mhier hat geschrieben: Wenn die Firmware mit gedrücktem Endschalter bootet, gibt es genau eine richtige Reaktion: Alles verweigern, was die Z-Achse bewegt außer der manuellen Bewegung über das Bedienfeld. Homing darf unter keinen Umständen ausgeführt werden in dem Zustand. Der Benutzer muss erst manuell (also per Tastendruck) in die richtige Richtung fahren, bis kein Endschalter mehr gedrückt ist. Alles andere ist 50:50 Glücksspiel!
Well. Im Moment ist es so, dass G-Codes keine Endschalter überfahren können. Dieses Verhalten wurde in der Firmware noch nicht geändert, insofern wurde das Thema noch nicht in der Firmware behandelt. In den entsprechenden Threads gibt es aber diverse Anmerkungen dazu, was man tun kann um diese Anforderung (dass G-Codes überhaupt den Endschalter überfahren müssen) eigentlich gar nicht mehr notwendig zu haben.mhier hat geschrieben: Punkt 1 wird m.E. nirgendwo zufriedenstellend behandelt, weil es schlicht ein Bug ist. Der "Endschalter" muss letzlich komplett ignoriert werden, nachdem das Homing mal stattgefunden hat. Stattdessen sollte die Firmware wenn dann softwareseitig sicherstellen, dass keine Z-Positionen angefahren werden, bei denen der Extruder in das Heizbett fahren würde. Welche das ist, hängt aber von der x/y-Position ab, der "Endschalter" gibt hier keine Auskunft!
Da muss ich widersprechen. Das Fräsen funktioniert genau so, wie es beschrieben ist. Ich wage beinahe zu behaupten, dass wir signifikant mehr und öfters gefräst haben als der durchschnittliche Anwender, der den RF1000 zum Fräsen verwendetmhier hat geschrieben: Übrigens habe ich noch deutlich mehr Bugs im Bezug auf den Fräsmodus gefunden, die nutze ich gerade mal um mich ein bisschen in die Firmware einzuarbeiten und werde hoffentlich in den nächsten Tagen schon fixes auf meinem Fork veröffentlichen. Zum Fräsen taugt die Firmware aktuell gar nicht. Da frag ich mich dann irgendwie, ob eigentlich jemand bei Euch sowas mal testet? Ich mein, schwer reproduzierbare Bugs seh ich ja ein, wenn die Kunden die erst finden, aber wenn so grundlegende Dinge wie der Z-Nullpunkt einfach nicht korrekt gesetzt werden hat offensichtlich niemand versucht, mit der Version mal was zu fräsen...
Das die Meinung über die korrekte Funktionsweise eines Z Endschalters bzw. den Unterschied von einem End zu einem Indexschalter beim CTC nicht unbedingt der Auffassung der restlichen Welt entspricht ist hinreichend bekannt. Die Frage wäre, ob das CTC irgendwann einmal gedenkt, das so zu implementieren, wie der Rest der Welt (mit außnahme des CTC) dies auch erwarten würde, anstatt gebetsmühlenartig zu wiederholen, dass so wie man es gemacht hat doch toll sei...?RF1000 hat geschrieben: Well. Im Moment ist es so, dass G-Codes keine Endschalter überfahren können. Dieses Verhalten wurde in der Firmware noch nicht geändert, insofern wurde das Thema noch nicht in der Firmware behandelt. In den entsprechenden Threads gibt es aber diverse Anmerkungen dazu, was man tun kann um diese Anforderung (dass G-Codes überhaupt den Endschalter überfahren müssen) eigentlich gar nicht mehr notwendig zu haben.
Der obere Endschalter kann nicht freigefahren werden, wenn wir drucken wollen. In der Standard-Konfiguration ist außerdem das Output Objekt Script so eingestellt, dass er bis zum unteren Endschalter fährt und dann die Stepper disabled. Danach knallt es regelmäßig... Es kann außerdem immer etwas Unvorhergesehenes passieren, also darf keine Annahme gemacht werden wenn nicht eindeutig ist, wie der wahre Zustand ist. Ich habe ja ein mögliches Verfahren beschrieben.RF1000 hat geschrieben:Nun. Wenn beide Z-Endschalter in einem Kreis zusammen geschlossen sind dann soll der Z-Endschalter immer frei gefahren werden - eben damit es nicht passieren kann, dass die Z-Achse stehen bleibt wenn der Z-Endschalter noch gedrückt ist.
Kommt es denn (mit der RF.01.11) jemals vor, dass der Z-Endschalter nicht freigefahren wird?
Bin mir nicht ganz sicher, ich glaube, wenn die Stepper disabled werden, geht die Firmware davon aus, dass alle Positionen verschoben sein könnten und setzt intern das Homing als ungültig. So richtig verstanden habe ich das aber noch nicht.Kannst du beschreiben, wie du in diesen Zustand kommst?mhier hat geschrieben: Das passiert letztlich immer dann, wenn die Firmware kein gültiges Homing mehr hat aber einer der Endschalter gedrückt ist.
Per Default nach jedem Druck erstmal in den unteren Endschalter volle Möhre reinfahren zu müssen, finde ich irgendwie keine gute Idee. Es knattert jedenfalls für 2-3 Sekunden gewaltig, und das kleine Schalterchen macht das sicher nicht ewig mit.Nach unten zu fahren ist in dem Zustand OK, weil beim unteren Endschalter nichts kaputt werden kann. Man kann in der Configuration.h FEATURE_ALLOW_UNKNOWN_POSITIONS auf 0 setzen - dann lässt die Firmware bei unbekannten Positionen (= nach dem Starten der Firmware bzw. nach jedem Ausschalten der Stepper) keine Bewegung außer dem Homing zu.mhier hat geschrieben: Wenn die Firmware mit gedrücktem Endschalter bootet, gibt es genau eine richtige Reaktion: Alles verweigern, was die Z-Achse bewegt außer der manuellen Bewegung über das Bedienfeld. Homing darf unter keinen Umständen ausgeführt werden in dem Zustand. Der Benutzer muss erst manuell (also per Tastendruck) in die richtige Richtung fahren, bis kein Endschalter mehr gedrückt ist. Alles andere ist 50:50 Glücksspiel!
Außer man möchte z.B. mit dem Druckkopf vor dem Druck über ein kleines Bürstchen fahren um geooztes Filament loszuwerden und muss dazu nach dem Homing einmal nach oben. Ich hatte auch lange Zeit Start-Gcode in meiner slic3r Konfiguration (irgendwo her kopiert...), die als erstes nach dem Homing ein Stück das Bett nach unten fährt (wohl um nicht über die Kante des Betts zu schleifen, falls die hoch steht - eher sinnlos denk ich). Auch wenn das vielleicht unnötig ist, es ist unglaublich schwer zu verstehen für einen Neuling, warum plötzlich die Z-Kompensation nicht mehr funktioniert...Well. Im Moment ist es so, dass G-Codes keine Endschalter überfahren können. Dieses Verhalten wurde in der Firmware noch nicht geändert, insofern wurde das Thema noch nicht in der Firmware behandelt. In den entsprechenden Threads gibt es aber diverse Anmerkungen dazu, was man tun kann um diese Anforderung (dass G-Codes überhaupt den Endschalter überfahren müssen) eigentlich gar nicht mehr notwendig zu haben.mhier hat geschrieben: Punkt 1 wird m.E. nirgendwo zufriedenstellend behandelt, weil es schlicht ein Bug ist. Der "Endschalter" muss letzlich komplett ignoriert werden, nachdem das Homing mal stattgefunden hat. Stattdessen sollte die Firmware wenn dann softwareseitig sicherstellen, dass keine Z-Positionen angefahren werden, bei denen der Extruder in das Heizbett fahren würde. Welche das ist, hängt aber von der x/y-Position ab, der "Endschalter" gibt hier keine Auskunft!
Der Z-Nullpunkt wird bei mir einfach ignoriert. Genauso lässt sich Start- und End-Position des Werkstückscans nicht festlegen - das hab ich aber zumindest lokal bei mir gefixed. Ich kann jetzt nicht alle einzelheiten nennen, weil ich das gerade nicht vor mir habe und auch nicht ausschließen kann, dass mancher Bug sich vielleicht durch verkehrte Fixes anderer Bugs erst eingeschlichen haben. Irgendwie glaube ich aber nicht, dass RF.01.11 auf dem RF1000 wirklich zum Fräsen taugt - oder ihr habt einen sehr anderen Workflow als ich. Das macht es aber nicht besser, es sind v.a. Funktionen aus dem Menü, die bei mir nicht funktionieren. Mit der Original-Firmware komm ich nicht mal so weit, dass ich nur auf die Idee kommen könnte, den eigentlichen G-Code zum Fräsen auszuführen.Da muss ich widersprechen. Das Fräsen funktioniert genau so, wie es beschrieben ist. Ich wage beinahe zu behaupten, dass wir signifikant mehr und öfters gefräst haben als der durchschnittliche Anwender, der den RF1000 zum Fräsen verwendetmhier hat geschrieben: Übrigens habe ich noch deutlich mehr Bugs im Bezug auf den Fräsmodus gefunden, die nutze ich gerade mal um mich ein bisschen in die Firmware einzuarbeiten und werde hoffentlich in den nächsten Tagen schon fixes auf meinem Fork veröffentlichen. Zum Fräsen taugt die Firmware aktuell gar nicht. Da frag ich mich dann irgendwie, ob eigentlich jemand bei Euch sowas mal testet? Ich mein, schwer reproduzierbare Bugs seh ich ja ein, wenn die Kunden die erst finden, aber wenn so grundlegende Dinge wie der Z-Nullpunkt einfach nicht korrekt gesetzt werden hat offensichtlich niemand versucht, mit der Version mal was zu fräsen...
Was genau klappt bei dir nicht? Den Z-Nullpunkt auf die Werkstückoberfläche zu legen ist ja eine Grundvoraussetzung, die wir definitiv bei jedem Fräsvorgang auch verwenden.
Ja, sobald die Stepper ausgeschalten werden ist die Home-Position unbekannt. Wenn die Stepper ausgeschalten sind können sie bewegt werden, die Annahme, dass die Schrittposition vor dem Ausschalten identisch zur Schrittposition nach dem Einschalten wäre ist nicht (und in keiner Richtung) zulässig.mhier hat geschrieben: Bin mir nicht ganz sicher, ich glaube, wenn die Stepper disabled werden, geht die Firmware davon aus, dass alle Positionen verschoben sein könnten und setzt intern das Homing als ungültig.
Beim unteren Endschalter ist der Anschlag während dem Knattern nicht der Schalter, sondern die Schraubenköpfe der Schrauben, mit welchen der untere Z-Endschalter montiert ist. Und diese Schraubenköpfe halten das aus, genauso wie der knatternde Motor.mhier hat geschrieben: Per Default nach jedem Druck erstmal in den unteren Endschalter volle Möhre reinfahren zu müssen, finde ich irgendwie keine gute Idee. Es knattert jedenfalls für 2-3 Sekunden gewaltig, und das kleine Schalterchen macht das sicher nicht ewig mit.
Ich stimme dir bedingt zu. Ja, es gibt Anwender wie dich und mich, die das richtig verwenden könnten. Andere Anwender würden damit auch mal in die falsche Richtung fahren und erst recht alles zertrümmern. Diese Anwender würden dann nicht dich für diese Möglichkeit loben sondern uns dafür beschimpfenmhier hat geschrieben: Ich möchte nach dem Einschalten per Bedienfeld das Heizbett bedingungslos fahren können, egal ob die Firmware meint ich wäre an einer Endposition. Ich weiß es nämlich besser. Damit könnte man die Situation dann retten.
Warum kann man die Bürse nicht so anbringen, dass sie auf z.B. Z=1 oder Z=5 steht?mhier hat geschrieben: Außer man möchte z.B. mit dem Druckkopf vor dem Druck über ein kleines Bürstchen fahren um geooztes Filament loszuwerden und muss dazu nach dem Homing einmal nach oben.
Stimmt. Da werden die direkt ausgeführten Schritte wohl an einer Stelle der Firmware nicht korrekt übernommen, wir werden das natürlich korrigieren. Danke!mhier hat geschrieben: Kann das sein, dass Ihr die Positionierungen nicht über das Menü sondern über G-Codes (z.B. via RepetierServer) vornehmt? Genau da liegt nämlich das Problem, Printer::queuePositionLastSteps funktioniert nicht für direct moves. Ich habe es durch Printer::currentXPosition() ersetzt, das scheint soweit zu gehen.
Code: Alles auswählen
G91 ; use relative coordinates
M3115 ; set the x/y-origin to the current x/y-position
M3130 ; find z=0
M400 ; wait until we have found z=0
M3070 S1 ; pause in order to turn on the miller
M117 Enable Miller
M3071 ; wait until the printing has been continued
M3141 ; enable the z-compensation
G90 ; use absolute coordinates
G0 X5.1426 Y34.0
G0 Z1.0
G1 F1000.0 Z-0.25
...
Im Grunde gilt hier das Gleiche wie weiter oben - es gibt Anwender, die mit der von der gewünschten Änderungen umgehen könnten. Andere würden damit leichter Schaden anrichten. Weitere Anwender wollen deinen Vorschlag gar nicht umgesetzt haben (auch hier im Forum, mir ist daher nicht ganz klar für welche Welt du sprichstZaldo hat geschrieben: Das die Meinung über die korrekte Funktionsweise eines Z Endschalters bzw. den Unterschied von einem End zu einem Indexschalter beim CTC nicht unbedingt der Auffassung der restlichen Welt entspricht ist hinreichend bekannt. Die Frage wäre, ob das CTC irgendwann einmal gedenkt, das so zu implementieren, wie der Rest der Welt (mit außnahme des CTC) dies auch erwarten würde, anstatt gebetsmühlenartig zu wiederholen, dass so wie man es gemacht hat doch toll sei...?
). Ich werde hier anregen, dass wir auch diesen Vorschlag als FEATURE umsetzen, das aber in unserer Standardsoftware per Default aus ist. Anwender wie du könnten das dann auf eigene Verantwortung hin einschalten.