dennis02121978 hat geschrieben:Wenn ich z.B auf FAN gehe und ausschalte hängt sich Klipper auf.

Du meinst im Menü, oder? Letzlich werden über das Menü auch nur G-Code-Befehle ausgeführt. Vermutlich ist das aus irgendwelchen Gründen in dem Moment unmöglich. Ich benutze um ehrlich zu sein das Menü fast gar nicht, und auch die Tasten nicht. Einzige Ausnahme: Filament einlegen (da helfen die Extruder-Tasten) und wenn ich wirklich verzweifelt bin dreh ich mal am Bett-Offset im ersten Layer über's Menü. Das liegt durchaus auch daran, dass das Menü in Klipper nicht besonders toll ist (naja, war's vorher auch nicht wirklich), aber auch, weil ohnehin ein Bildschirm+Maus mit Octoprint daneben steht, und das ist einfach 100 mal bequemer als jedes erdenkliche Menü auf dem dämlichen Display Kann ich nur jedem empfehlen...

Schau mal bitte nach, was da für eine Fehlermeldung auftaucht, entweder in der G-Code-Konsole, oder falls da nichts ist, im Klipper Logfile (/tmp/klipper.log wenn ich mich richtig erinnere). Das Klipper Logfile wird gerne sehr länglich, und meistens scrollt man von unten hoch bis zur letzten Fehlermeldung, die aber fast immer nur ein Folgefehler ist. Wenn du den richtigen Fehler nicht findest, poste mal bitte das gesamte Logfile als Dateianhang (vorher Logfile löschen, Klipper neu starten, dann Fehler möglichst schnell reproduzieren, damit das Logfile nicht zu groß wird).

Kannst du mal genauer beschreiben, was du in welcher Situation gemacht hast?

Eine gewisse Doku (sicher ausbaufähig) gibt es hier:
wiki/index.php/Klipper#Klipper_Befehle

dennis02121978 hat geschrieben:Das Leveling unter Klipper ist ja auch viel schneller als in der Originalen Firmware.

Da stimmt was nicht, das ist eher langsamer. Bist du der Anleitung gefolgt? Oder was genau hast du gemacht?

Kannst du mal den Output der Octoprint-Konsole posten, den du bekommst, während du das Leveling durchführst?

Der Gcode (Model mit Startcode) ist das gleiche wie beim Standard

Was ist der "Standard"? Die Repetier-basierte Firmware? Dann werden die Befehle nicht verstanden. Sollte aber für's Leveling nichts machen, denn bei Klipper muss man das nicht erst aktivieren.

Dumme Frage vom Laien. Dennis hat die DMS über einen HX711 und Arduino verbunden. Das er jetzt einen einfachen Ausgang ansteuert lasse ich mal weg. Das heisst wenn man den 2ten Arduino in Klipper einbindet, so würde der doch von Klipper verstanden werden und könnte ganz normal die Daten liefern. Diese Daten sind dann für die Korrekturen ja erreichbar.

Damit wäre die Digit Flow Compensation für alle Boards die mit Klipper laufen möglich (und HBS sowieso). Oder habe ich da was übersehen ?

dennis02121978 hat geschrieben:ich setze Octoprint nicht im Zusammenhang mit Klipper ein da dies zu Fehlern führen kann wie ich im anderen Thread gepostet hab (Link Marlin vs Klipper).

Irgendwas in der Art brauchst du aber ja. Es ist von Klipper her vorgesehen, dass es mit OctoPrint zusammen benutzt wird. Ich würde daher jedem empfehlen, das genau so aufzusetzen. Alles andere führt nicht nur zu Fehlern sondern macht auch das Debugging schwerer, denn die Dokumentation bezieht sich nun mal darauf.

Am Ende ist es aber egal was du benutzt. Poste bitte den Output an deiner G-Code-Konsole (welche auch immer du nutzt), wenn du das Leveling durchführst.

dennis02121978 hat geschrieben:HX711 bis jetzt nicht in Klipper und wird schwer laut Github wegen den schnellen Interrupts.

Was meinst du genau? Github ist groß, Link bitte

Man sollte es herunter Takten dann würde es gehen aber sehe dann keinen weiteren Erfolg was Abtast Geschwindigkeit betrifft.

Also so ein HX711 kann maximal 80 Hz. Das ist jetzt keine wahnsinnige Datenrate, damit wird der Microcontroller wohl schon fertig. Ist ja jedes mal nur eine 16 Bit Zahl. Selbst der AtMega von Original-Mainboard kann das. Für eine ARM-MCU ist das ein Kinderspiel, eines meiner Projekte hier auf der Arbeit mit einer ARM-MCU benutzt 100 kHz Interrupt-Frequenz und lässt damit einen vollen PI-Controller laufen. Das ist über 1000 mal so schnell.

Und selbst wenn wir nicht ganz 80 Hz schaffen sollten: In der Original-Firmware lesen wir die DMS mit 8 Hz aus! Ich habe das in der Klipper-Version auf 16 Hz aufgebohrt (dabei verliert man 1 Bit an Genauigkeit bei unserem ADC-Chip auf dem Original-Mainboard). Viel mehr ist ohnehin nicht wirklich hilfreich, weil die Round Trip Zeiten bei der Kommunikation zwischen Klipper Host und der MCU zu groß sind.

Wegen Octoprint und Klipper würde ich Mainsail eher bevorzugen da es keine Fehler gibt.

Ich versteh nicht was du mit "Fehlern" hier meinst, wieso sollte es mit Octoprint Fehler geben? Klipper ist ursprünglich für die Zusammenarbeit mit Octoprint gedacht. Ich benutze das und es funktioniert. Das soll jetzt kein Argument gegen irgendwas anderes sein, aber so pauschal würde ich erstmal empfehlen, mit Octoprint anzufangen, weil das eben das verbreitetste Setup ist.

Ich kann die Aussagen nicht wirklich nachvollziehen. Die sind esotherisch, ohne wirkliche Begründung in dem Artikel.

Ich habe mittlerweile OctoPront deaktiviert, das hat aber den Grund, weil ich einen gekauften Repetierserver laufen lasse. Was vielleicht sein kann, das man eventuell einen zu 'knappen' RasPi verwendet. Mein Raspi 4 mit 4 GB, ist da eher im Leerlauf, egal was ich ihn fordere.

Klar das ein Userinterface sehr wohl Resourcen verbraucht, wenn ich zu knapp kalkuliere, darf ich mich nicht wundern.

BTW: Ich habe für mein Ergometer einen kompletten Windows Micro-PC abgestellt (Nur für Video und Ansteuerung) . Also man sollte schon wissen für was man Resourcen einsetzt. Aber ich würde nicht irgendwelche unüberprüfbare Argumente ins Gewicht werfen.

dennis02121978 hat geschrieben:Deine Probleme die du oben beschreibst kommen rein von der Gcode interpretation von Octoprint.

Das kann ich mir zumindest vorstellen, da da der Code durch einige Prg.Teile von Octoprint durch muss. Das ist aber keine Problem von Klipper, sondern, laut der Beschreibung von dir, eine Schwäche von Octoprint.

Wobei Schwäche, wenn Octoprint etwas im GCOde stream elbst interprtieren muss, so kann das durchaus einen Sinn haben. Beim Repetierserver habe ich auch im GCode Stream Befehle für den Repetierserver, die von ihm interpretiert und ausgeführt werden. Ein Beispiel ist die Kameraansteuerung, die klarerweise nicht an den Drucker weitergegeben wird. Für den Drucker sind das Kommentare, für Reptierserver das Kommando ein Bild zu einem speziell Zeitpunkt aufzunehmen.

Sowas wird Octoprint auch haben. Nur wenn die Prozesse sauber entkoppelt sind und der Serverrechner (RasPi) nicht aus dem letzten Loch pfeift, macht das keine Probleme. Klar, desto Plugin desto Power, da ist dann nicht mit einem alten Raspi 1 oder 2. Deswegen habe ich RasPi 4 mit 4 GB Speicher.

Ist ja schön, dass irgendwelche Leute irgendwo etwas schreiben, aber schau doch mal die Installations-Anleitung von Klipper an, ich meine das Original auf klipper3d.org. Der allererste Satz lautet:

These instructions assume the software will run on a Raspberry Pi computer in conjunction with OctoPrint.

Das ist der Standard, der ist am besten unterstützt. Damit gibt es die geringsten Probleme. Ich benutze zwar keinen Raspberry Pi, aber ansonsten ein fast identisches Setup. Es gibt damit keine Probleme, wie die Leute sie da anscheinend beschreiben. Das bezieht sich vielleicht auf eine sehr alte Version, keine Ahnung. Muss dann älter sein als ein gutes Jahr, denn so lange habe ich diese Kombi inzwischen im Einsatz.

Einzig eine kleine Einstellung sollte man in OctoPrint ändern, weil es sonst nervt, zumindest wenn man Dinge ausprobiert: Standardmäßig bringt OctoPrint den Drucker (egal ob mit Klipper, Repetier oder Marlin) sicherheitshalber in einen Fehlerzustand, sobald eine Fehlermeldung vom Drucker erkannt wird, und trennt die Verbindung. Das bedeutet aber, dass jeder Tippfehler im G-Code-Befehl an der Konsole erst ein Wiederherstellen der Verbindung und dann einen Neustart der Drucker-Firmware erfordert. Ich weiß nicht, ob andere Firmware sich da genauso verhält, ich denke aber schon (das ist der Befehl M112 - Emergency Stop). Das hat also eigentlich nichts mit Klipper zu tun, OctoPrint ist da nur recht strikt. Dieses Verhalten lässt sich leicht abschalten (Schraubenschlüssel oben anklicken um in die Einstellungen zu kommen, "Serial Connection", "Behaviour", dann "What to do on a firmware error" entsprechend umkonfigurieren). Dies wird aber keinerlei Auswirkung auf den produktiven Betrieb haben, solange man korrekten G-Code an den Drucker schickt.

Versteht mich nicht falsch, Mainsail sieht schick aus. Wem das wichtig ist, für den mag das eine geeignete Wahl sein. Allerdings sollte man immer Zugang zu einer G-Code-Konsole haben, wo man direkt Befehle eintippen kann. Das gilt in meinen Augen für *jede* Firmware. Auch kann es wichtig sein, zumindest die Option zu haben, die Rückmeldungen des Druckers auf den G-Code vom Slicer sehen zu können. Wer das nicht kann, der wird es sehr schwer haben, gewisse Probleme zu debuggen. Nicht selten stehen dort nämlich ganz klare und eindeutige Fehlermeldungen, die nirgendswo anders sichtbar werden. Auch das gilt meines Wissens für *jede* Firmware. Schicke GUIs blenden gerne häßlich aussehende Fehlermeldungen aus und zeigen im besten Fall noch eine generische Fehlermeldung an. Das ist übrigens ein leider sehr verbreitetes Muster bei Comsumer-Software, die mich regelmäßig in den Wahnsinn treibt... Wenn jemand der Meinung ist, mit derartigen Fehlermeldungen sich nicht beschäftigen zu wollen, der sollte besser die Finger von einem Drucker wie dem RF1000 lassen (das gilt wieder für jede Firmware), vielleicht sogar von jedem 3D-Drucker überhaupt.

dennis02121978 hat geschrieben:Und die Plugins können schon den GCODE anfassen und verändern.

Klar. Sollen sie ja ggf. auch. Und? Was ist das für ein Argument? Installier halt kein Plugin, was irgendwelchen Unsinn mit dem G-Code anstellt, den du gar nicht willst. Die Plugins installieren sich ja nicht von alleine.

dennis02121978 hat geschrieben:In MainSail ist es eine Virtuelle SD wo Klipp direkt liest. Sehe zwar jetzt erstmal auch keine Handhabung aber es ist gut zu wissen das hier etwas vielleicht mit Octoprint zusammen hängen kann.

Das scheint nicht richtig zu funktionieren, siehe der Thread zu Klipper ohne Raspberry Pi. Ich seh den Sinn einer virtuellen SD-Karte auch nicht (außer man benutzt einen Raspberry Pi 1, der wirklich sehr hart an der Grenze ist, zu langsam zu sein).

Ich denke, die allgemeine Empfehlung sollte lauten, zunächst der allgemeinen Empfehlung der Macher von Klipper zu folgen. Die lautet, Klipper auf OctoPi zu installieren. OctoPi ist ein Raspberry Pi Image, auf dem bereits OctoPrint vorinstalliert ist. Dann hat man eigentlich alles vorbereitet, bis auf die Installation von Klipper selbst, und da muss man ja ohnehin unser Community-Repository verwenden und macht das daher besser selbst. Wenn man sich da dran hält und nicht gleich beim ersten Versuch irgendwas super-duper spezielles versuche muss, dann funktioniert's auch. Folge einfach beim Ersten mal der Anleitung (wofür haben wir die eigentlich im Wiki). Wenn das funktioniert, kann man immer noch was anderes probieren. Dann weiß man hinterher auch, ob Klipper wirklich blöd ist oder man es nicht vielleicht doch selbst vergurkt hat.

Also an alle Klipper-Anfänger: Bitte nehmt NICHT sofort Mainsail für's erste, sondern bleibt bei dem getesteten Installations-Weg im Wiki! Nur so kann ich bei Problemen helfen!