• Klipper mit dem RF1000

nikibalboa hat geschrieben:Ich bin heute am z offset gescheitert, da weiß ich noch nicht genau wie och das Werkzeug auf null setze.

Ja ich bin auch noch am probieren. Definitiv sollte man das alte z_offset_scan Modul rauswerfen (wichtig: es darf auch nicht mehr in der SAVE_CONFIG Sektion der .cfg-Datei vorkommen!), das macht komische Dinge. Dann scheint folgendes wohl zu funktionieren:

1. Start/Ende des Workpart-Scans festlegen
2. Im Bereich des Scans in XY hinfahren, manuell knapp über das Workpart stellen und einmal PROBE ausführen
3. SET_KINEMATIC_POSITION Z=0
4. WORKPART_SCAN (durch SET_KINEMATIC_POSITION passiert der jetzt in der richtigen Höhe)
5. SAVE_CONFIG
6. Werkzeug wechseln (natürlich nur, wenn man wirklich fräsen will)
7. Neu homen, wieder in XY in den Bereich des Scans fahren, manuell knapp über das Workpart stellen und einmal PROBE ausführen
8. Jetzt G92 Z0 ausführen. SET_KINEMATIC_POSITION würde die kinematic position auf 0 stellen, dann haben wir die Größe des Meshes am Scanpunkt als Fehler.

Weiters sind die hohen Geschwindigkeiten ein Problem wenn man den Matrix scan startet, da muss man schon ziemlich nah am Werkstück sein.

Ich verstehe nicht genau, was du damit meinst. Der Scan ist ziemlich langsam (logisch), deshalb muss man sich nah ans Werkstück stellen, damit einem nicht die Zähne lang werden. Aber sonst?

Das Kanten antasten hat schon mal funktioniert nur hat sich nach dem Starten des g-codes scheinbar das z-offset verschoben.
Ich werde morgen weiter probieren.

Irgendwas passt mit dem workpart scan noch nicht, die Korrektur scheint mir nicht richtig zu sein... Das auch schon ohne Kanten Antasten.

Ohne gespeicherten matrix scans hab ich schon mal einen gcode mit einem Stift getestet, da war das kein Problem.

Ich verstehe nicht genau, was du damit meinst. Der Scan ist ziemlich langsam (logisch), deshalb muss man sich nah ans Werkstück stellen, damit einem nicht die Zähne lang werden. Aber sonst?

Wenn die z achse zb. ganz unten ist wird sie so sehr beschleunigt das sie "stecken bleibt" schrittverluste. Das ganze obwohl im config die Geschwindigkeit begrenzt ist.

Servus,

dank eurer super Vorarbeit konnte ich jetzt auch relativ Problemlos auf Klipper wechseln.

ein bisschen irritiert war ich noch bzgl. Z-Offset. Hatte das erst aus der printer.cfg gelöscht war dann aber nach dem HBS zu hoch ?
Dann doch wieder [z_offset_scan] eingetragen und danach hats gepasst:

#*# [z_offset_scan]
#*# z_offset = -0.424518567873
#*# mesh_offset = -0.456211911594

noch nicht ganz durchschaut habe ich das Display ?
wie bekomme ich denn die digits in das 20x4
download/file.php?mode=view&id=9654

Display_20x4 RF2000V2 dual.jpg

da ich im dual Betrieb arbeite (naja, arbeiten will) würde ich das gerne dort integrieren ?
Ich würde das gerne in die letzte Zeile vor das Ready setzen, also auf 3,0 und Ready auf 3,10 verschieben

Aber wenn ich das entsprechend integriere
[display_template _load_cell_digits]
text:
{ "F%5d" % (printer["load_cell_probe"].last_force) }

[display_data _default_20x4 load_cell_digits]
position: 3, 0
text: { render("_load_cell_digits") }

verschwindet das Ready (obwohl ich das auf 3,10 verschoben habe) aber keine Werte der load cell ?

bin für alle Hinweise dankbar

das auslesen über Klipper funktioniert, daran kann es also nicht liegen?
Send: READ_LOAD_CELL
Recv: // Uncompensated: -283.7 compensated: -283.7
Recv: ok

Die unterste Zeil ist mit den Statusmeldungen von Klipper belegt.

Grundlegend überlege ich bei mir die Anzeige der DMS zu kürzen, schon mal nur 3 Stellen. Betttemperatur und Fan lassen sich auch noch kürzen. Bei Fan reicht ja ein F.

Aber das optische ist mal nicht ganz so mein Problem.

So ich habe in meiner config jetzt einen Menü Punkt mit Z Offset set (SET_GCODE_OFFSET Z={printer.gcode_move.gcode_position.z}
).
Das funktioniert aber nur wenn auch ein Mesh gespeichert ist, ansonsten muss man das offset wieder auf null setzen wenn man diese neu setzen will, da es sich sonst um eine weitere gcode Bewegung verschiebt.

Weiters habe ich einen Befehl welcher das Offset wieder zurücksetzt (SET_GCODE_OFFSET Z=0).

Ich stehe halt gerne beim Fräsen am "Gerät" ;)
Zu meinen Pfeil Tasten für die Z-Achse hoch, da muss unbedingt diese Zeile rein {% if not printer.idle_timeout.state == "Printing" and printer.gcode_move.gcode_position.z >= 1 %}. Das Verhindert das bei einer Pause das Druckbett crasht! Die printer.idle_timeout.state ist in einer Pause wieder "idle".
Falls gewünscht lade ich die configs wieder hoch.

Kurz um das Fräsen in Klipper ist noch sehr mit Vorsicht zu genießen!

Ich werde jetzt mal zu Praxis übergehen und eine Print fräsen.

Ich habe jetzt mal nur einen Siebdruck getestet, sieht schon mal brauchbar aus

@hier, wird der matrix scan durch das edge_touch modul verschoben? Es sieht nämlich aus als hätte es keine Korrektur gegeben. Ich habe aber start end noch mit meinen modul erstellt.

DSC_4384.JPG

nikibalboa hat geschrieben: Wenn die z achse zb. ganz unten ist wird sie so sehr beschleunigt das sie "stecken bleibt" schrittverluste. Das ganze obwohl im config die Geschwindigkeit begrenzt ist.

Vielleicht ist deine Z-Achse etwas schwergängiger als meine. Ist sie noch gut geschmiert? Evtl. hilft es den Stepper-Strom für Z hochzustellen? Oder die Beschleunigung runter?

tarabas_73 hat geschrieben:ein bisschen irritiert war ich noch bzgl. Z-Offset. Hatte das erst aus der printer.cfg gelöscht war dann aber nach dem HBS zu hoch ?

Ja wenn du das rauswirfst, musst du entweder den HBS neu machen, oder anderweitig den Z-Offset justieren. Die "moderne" Lösung dafür ist (also anstelle des Z-Offset-Scans):

Code: Alles auswählen

PROBE
Z_ENDSTOP_SET_CALIBRATION Z=0
SAVE_CONFIG

Danach neu homen. Diese Befehls-Kombination ersetzt den Z_OFFSET_SCAN und hat diverse Probleme nicht. Ich werde demnächst das Z_OFFSET_SCAN löschen.

wie bekomme ich denn die digits in das 20x4

Bist du dir sicher, dass deine Konfiguration das 20x4 Template benutzt?

nikibalboa hat geschrieben:So ich habe in meiner config jetzt einen Menü Punkt mit Z Offset set (SET_GCODE_OFFSET Z={printer.gcode_move.gcode_position.z}
).

Was genau ist da der Unterschied zu G92 Z0?

Falls gewünscht lade ich die configs wieder hoch.

Ideal wäre ein Pull-Request auf github

Kurz um das Fräsen in Klipper ist noch sehr mit Vorsicht zu genießen!

Selbstverständlich, ich denke, insgesamt werden bisher noch sehr weniger Leute mit Klipper gefräst haben, selbst mit anderen Geräten.

@hier, wird der matrix scan durch das edge_touch modul verschoben? Es sieht nämlich aus als hätte es keine Korrektur gegeben.

Schreib mal sowas hier in deine Config:

Code: Alles auswählen

[bed_mesh]
fade_start: 200.0
fade_end: 210.0

Sonst ist man bei zu großen Z-Koordinaten und die Korrektur ist de-facto nicht aktiv. Relevant ist nicht die G-Code-Koordinate sondern die kinematic position.

Ich habe aber start end noch mit meinen modul erstellt.

Das sollte nichts machen, dein Modul ist lediglich etwas umständlicher zu bedienen als meine Macros, weil du dir damit den Neustart sparen kannst.

Ich habe gerade einen Alu-Block absichtlich extrem schief in allen Richtungen eingespannt. Dann habe ich zuerst den Mesh-Scan gemacht und anschließend die Kanten angetastet. Wenn ich dann im Bereich des Mesh-Scans rumfahre, fährt er schön im konstanten Abstand zur Oberfläche und parallel zu den Kanten - jedenfalls soweit ich das per Auge beurteilen kann. Bei der extremen Verkippung wäre aber eine fehlende Korrektur sofort sichtbar (fällt direkt auf, wenn ich den Bereich des Meshes verlasse). Soweit würde ich also sagen, das funktioniert prinzipiell. Wie genau das jetzt ist, ist eine andere Frage...

mhier hat geschrieben:Die "moderne" Lösung dafür ist (also anstelle des Z-Offset-Scans):
Code: Alles auswählen
PROBE
Z_ENDSTOP_SET_CALIBRATION Z=0
SAVE_CONFIG
Danach neu homen. Diese Befehls-Kombination ersetzt den Z_OFFSET_SCAN und hat diverse Probleme nicht. Ich werde demnächst das Z_OFFSET_SCAN löschen.

Ich würde es nicht rauslöschen, da du damit sofort existierende Konfiguration zerstörst. Warum nicht den Z_OFFSET_SCAN auf die Kombination umleiten und dazu auf de Konsole "deprecated command" ausgeben. Dann hat man die Möglichkeit umzustellen, wenn man das sieht.

af0815 hat geschrieben: Ich würde es nicht rauslöschen, da du damit sofort existierende Konfiguration zerstörst. Warum nicht den Z_OFFSET_SCAN auf die Kombination umleiten und dazu auf de Konsole "deprecated command" ausgeben. Dann hat man die Möglichkeit umzustellen, wenn man das sieht.

Das Verhalten dieser Kombination ist nicht exakt identisch. Deshalb ist es besser, wenn der Befehl einfach gar nicht mehr geht, als wenn er plötzlich in manchen Lebenslagen sich subtil anders verhält. Manchmal muss man diesen Schritt eben gehen.

Aktuell gibt es aber noch das Problem mit o.G. Kombination, dass eine Einstellung in printer-rf1000.cfg überschrieben werden muss (position_endstop). Das funktioniert nicht, wenn man die Datei in seiner printer.cfg included. Ich hoffe, ich kann die Klipper-Entwickler überzeugen, das zu ändern...

Vielleicht ist deine Z-Achse etwas schwergängiger als meine. Ist sie noch gut geschmiert? Evtl. hilft es den Stepper-Strom für Z hochzustellen? Oder die Beschleunigung runter?

Ich werde da mal ein Video machen, wie gesagt die Z-Achse wird auf eine zu hohe Geschwindigkeit beschleunigt die die maximal eingestellte Geschwindigkeit übersteigt.

Was genau ist da der Unterschied zu G92 Z0?

Ich muss gestehen ich bin mit den verschiedenen Koordinaten noch nicht ganz vertraut und diese Lösung funktioniert. Aber jetzt ist es mir eh logisch das es aufs gleiche kommt.

Ich bin dann schon auf die zweite Seite gespannt ob sich die zwei Seiten gut decken, da erkennt man dann mögliche Ungenauigkeit auch.

Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000

Re: Klipper mit dem RF1000