Bugs in Firmware RF.01.11 (RF1000)

[Zaldo]

Leider kann ich nicht beisteuern wie Repetier Host sich verhalten hat, Repetier Server (auf RPI) bricht den laufenden Job ab, sobald der Drucker (.59) resettet (Not-Aus)

[Zaldo]

Leider kann ich nicht beisteuern wie Repetier Host sich verhalten hat, Repetier Server (auf RPI) bricht den laufenden Job ab, sobald der Drucker (.59) resettet (Not-Aus)

[RF1000]

Hallo mhier,

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.

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? Passiert es z.B. von 10 Mal im Schnitt x Mal? Kann man dabei mittlerweile irgend ein Muster erkennen?
Im Grunde sollte sich am Z-Homing von der V 0.91.xx auf die RF.01.yy nicht wirklich etwas getan haben.

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.

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?

An deinen Punkten 4 und 5 sind wir dran. Punkt 1 wird durch andere Threads behandelt, korrekt?


Danke im Voraus,
RF1000

[mhier]

Hallo RF1000,

Hallo mhier,

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?
Im Grunde sollte sich am Z-Homing von der V 0.91.xx auf die RF.01.yy nicht wirklich etwas getan haben.

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.

Hallo mhier,

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.

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?

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!

An deinen Punkten 4 und 5 sind wir dran. Punkt 1 wird durch andere Threads behandelt, korrekt?

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!

Punkt 5 ist für mich gelöst, siehe mein Post #8 hier im Thread. Das könnt ihr gerne natürlich noch eleganter machen

Ü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... :-/

[RF1000]

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.

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?

Das passiert letztlich immer dann, wenn die Firmware kein gültiges Homing mehr hat aber einer der Endschalter gedrückt ist.

Kannst du beschreiben, wie du in diesen Zustand kommst?

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!

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.

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!

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.

Ü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...

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 verwendet
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.


mfG
RF1000

[RFrank]

Meine untere Lichtschranke hat es leider auch schon zerlegt, dann habe ich aus zwei defekten eine Ganze erstellt.
Solange kein Merker in Software gesetzt wird ob der Tisch oben oder unten ist, muss der untere frei gefahren werden.
Ich habe ans Ende des G-Codes einen G1 Z-1 F100 gesetzt (relative Koordinaten; damit er der Tisch 1 mm nach oben fährt). Die unterbrochene Lichtschranke bleibt bei mir dunkel, wenn die untere leuchtet ist alles okay für ein normales Arbeiten.
Durch eine dauerhaft eingebaute Alufräsplatte/Druckplatte fehlt mir etwas vom Z-Weg, eine Begrenzung auf Z 190 in der Parametern wird bei der Ausgabe nicht berücksichtigt.

Gruß Frank

[Zaldo]

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.

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...?

[mhier]

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?

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.

Das passiert letztlich immer dann, wenn die Firmware kein gültiges Homing mehr hat aber einer der Endschalter gedrückt ist.

Kannst du beschreiben, wie du in diesen Zustand kommst?

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.

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!

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.

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 bräuchte das Gegenteil von FEATURE_ALLOW_UNKNOWN_POSITIONS sozusagen. 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.

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!

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.

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...

Ü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...

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 verwendet
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.

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.

Mein Workflow ist ungefär folgender (Platinenfräsen):
1. Material ist eingespannt. Ich habe 4 G-Code Dateien (Oberseite, Unterseite, Löcher und Außenabmessungen). Unterseite und Löcher gehen in negative X-Richtung, da gespiegelt.
2. Nullpunkt wird irgendwo "rechts vorne" gewählt, so dass die Platine nach links hinten auf das Material passt. An den Nullpunkt fahre ich per Menü hin (-> Firmware untauglich, da keine genaue Positionierung möglich!)
3. Ich bohre ein Loch an den Nullpunkt, damit ich den jederzeit wieder einstellen kann (auch von der anderen Seite).
4. Ich setze Start und Stopp für den Workpart-Scan (-> geht nicht, bleibt bei 0) und starte diesen.
5. Ich fahre an den Nullpunkt (so dass der Bohrer ins Loch passt) und setze den XY-Origin (wird ignoriert).
6. Ich wechsele das Tool auf das Fräsbit, fahre in die Mitte der Platine und lasse den Z-Origin finden (er findet den, ignoriert aber den Z-Offset im Folgenden - außerdem zerstört das den XY-Origin)
7. Ich fräse die Unterseite
(Rest ist erstmal egal, das würde dann funktionieren, wenn ich bis hierhin gekommen bin)

Wie gesagt, vielleicht habe ich manche der späteren Bugs im Workflow selbst verursacht durch Fixes der ersten, aber eher nicht alle... Hier ist einiges im Argen! Ich komme Aktuell bis Schritt 6 - warum der mir den XY-Origin wieder kaputt macht verstehe ich nicht. Wenn ich das gelöst habe (hoffentlich im Verlauf der Woche), committe ich das in meinen Fork, dann könnt ihr euch das ja mal ansehen.

[mhier]

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. (Bis auf die noch unverstandenen XY-Origin-Probleme)

[RF1000]

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.

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.

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.

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.

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.

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 beschimpfen
Ich werde hier anregen, dass wir deinen 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.

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.

Warum kann man die Bürse nicht so anbringen, dass sie auf z.B. Z=1 oder Z=5 steht?

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.

Stimmt. Da werden die direkt ausgeführten Schritte wohl an einer Stelle der Firmware nicht korrekt übernommen, wir werden das natürlich korrigieren. Danke!

Unser typischer Workflow sieht ohne Z-Scan folgendermaßen aus, wobei wir die Homing/Fahrschritten typischerweise über den Repetier-Host ausführen. Den Z-Scan kann man ja unabhängig davon davor durchführen:

• - Lege ein Werkstück auf die Fräsplatte.

• - Stelle sicher, dass das gewählte Werkstück groß genug für die zu fräsende Datei ist.

• - Fixiere das Werkstück auf der Fräsplatte.

• - Stelle sicher, dass die Z-Position der Fräsplatte so ist dass sich der Fräser in X- und Y-Richtung frei bewegen kann ohne z.B. in den Anschlag zu fahren.

• - Fahre den Fräser auf die X-Home-Position.

• - Fahre den Fräser auf die Y-Home-Position.

• - Fahre den Fräser in X- und Y-Richtung sodass er dort steht, wo die linke untere Ecke des zu fräsenden Objekts platziert werden soll.

• - Öffne eine G-Code Datei im Repetier-Host (z.B. „Mill ASCII.gcode“).

• - Starte den Fräsvorgang über den Repetier-Host.

• • - Der Fräser fährt in die Ausgangsposition.
  • - Die X- und Y-Positionen bleiben unverändert, der Frästisch wird nur nach oben bewegt damit die Z-Position der Oberfläche des Werkstücks ermittelt werden kann.

• - Warte bis in der Anzeige die Aufforderung erscheint, den Fräser einzuschalten.

• - Schalte den Fräser ein.

• - Drücke den „Continue“ Knopf.

• - Warte bis der Fräsvorgang abgeschlossen ist.

• - Schalte den Fräser aus wenn in der Statuszeile „Idle“ steht.

Ein dazu passender beispielhafter G-Code Anfang wäre:

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
...

Das x/y-Homing und das Anfahren der gewünschten x/y-Startposition kann man natürlich auch noch in den G-Code integrieren, wenn man immer an der gleichen x/y-Position anfangen will.

Unser typischer Workflow für den Z-Scan sieht folgendermaßen aus (wobei alle Schritte in der Regel wiederum über den Repetier-Host ausgeführt werden):

• - Lege ein Werkstück auf die Fräsplatte.

• - Stelle sicher, dass das gewählte Werkstück groß genug für die zu fräsende Datei ist.

• - Fixiere das Werkstück auf der Fräsplatte.

• - Stelle sicher, dass die Z-Position der Fräsplatte so ist dass sich der Fräser in X- und Y-Richtung frei bewegen kann ohne z.B. in den Anschlag zu fahren.

• - Während den folgenden Schritten dürfen die Stepper zu keinem Zeitpunkt ausgeschalten werden.

• - Fahre den Fräser auf die X-Home-Position.

• - Fahre den Fräser auf die Y-Home-Position.

• - Bewege den Fräser an die X- und Y-Position links vorne am Werkstück, an welcher der Z-Scan später starten soll.

• - Wähle „Set XY Start“ und drücke OK.

• - Bewege den Fräser an die X- und Y-Position rechts hinten am Werkstück, an welcher der Z-Scan später enden soll.

• - Wähle „Set XY End“ und drücke OK.

• - Wähle „Scan Work Part“ und drücke „OK“.

• - Warte bis der Work Part Scan abgeschlossen ist.

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...?

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 sprichst ). 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.


mfG,
RF1000