Auf Anraten von mhier habe ich diesen Thread eröffnet in der Hoffnung, dass sich eine einfache Methode findet, Klipper ohne Einsatz eines Raspberry Pis zum Laufen zu bringen.

mhier hat geschrieben:Mach mal bitte einen neuen Thread dafür auf. Das interessiert sicher viele und wird hier doch sehr unübersichtlich. Es gibt mehrere Lösungen, da findet sicher jeder seine passende

mhier hat geschrieben:Wie gesagt muss Klipper nicht zwingend auf einem Pi laufen, jedes PC-ähnliche System sollte gehen, wahrscheinlich sogar Windows.

Ich wäre bereit Klipper eine Chance zu geben (zumindest einen Testlauf), wenn ich nicht mit Raspberry, usw. arbeiten muss. Nötigenfalls kann ich mein Windows PC mittels bootbarem USB-Stick mit Linux hochfahren (falls nötig). Oder auch ein Laptop, zur Not.

Schön wäre ein vollständig vorkonfiguriertes Image, dass nur mehr gebootet werden muss um den Drucker, RFx000 oder was auch immer, unter Klipper betreiben zu können.

Man soll die Hoffnung nie aufgeben ....

mjh11

Ah Dennis war schneller, naja ich hab ja auch ne lange Anleitung geschrieben...

Also, ein vorkonfiguriertes Image scheint es mit MainsailOS mehr oder weniger zu geben (danke an dennis02121978 für den Hinweis), allerdings nur für den Raspberry Pi. Für PCs fürchte ich eher, dass sich so etwas nicht lohnt, weil das kaum jemand nutzen wird. Die Images müssen ja auch gepflegt und geupdated werden, das kostet dann schnell sehr viel mehr Zeit als es einspart.

Ich habe mal im Wiki eine Anleitung geschrieben, die muss aber noch getestet werden:

wiki/index.php/Klipper_auf_PC#Schritt_C ... stallieren

dennis02121978 hat geschrieben:Habe noch etwas altes gefunden wo man Raspberry Emulierten kann.

Hab ich kurz drüber nachgedacht, würde ich aber nicht empfehlen. Eine Emulation ist langsam, wir brauchen aber eine gewisse Echtzeitfähigkeit. Da ist schon eine normale Virtuelle Maschine evtl. nicht optimal, eine volle Emulation halte ich da für schwierig.

Mir kam eine Frage in den Sinn als ich den ersten (erfolglosen) Versuch startete, Klipper an PC (unter Ubuntu 20.08) zum Laufen zu bringen.
Diese Frage betrifft die Arbeitsweise von Klipper selbst.

Der Drucker hat ja einen Mikroprozessor eingebaut, mit eigener Firmware (die 'Systemplatine'). Diese Firmware ist imstande, eine GCode-Datei von einer SD Karte laden und ausführen (=drucken). Andererseits kann die Firmware ebenso GCode Befehle über die USB Schnittstelle empfangen (die als Serielle Schnittstelle gehandhabt wird) und die Befehle dann nach und nach ausführen (was in Summe dem Drucken entspricht).
Aus Erfahrung weiß ich, dass die Firmware falsch geschriebene oder nicht-existente GCodes einfach ignoriert, ebenso wie Text, das gar keinen GCode entsprechen muss.

Meine Frage daher:
Klipper, dass über die Serielle mit der Drucker-Firmware spricht, wandelt ja die GCode Befehle in 'Motorbefehle' um bevor diese über die Serielle an den Drucker weitergeleitet werden (richtig?). Damit möchte man ja die rechenintensiven Berechnungen der Systemplatine des Drucker ersparen. Folglich gelangen nur mehr 'Motorbefehle' an den Drucker gesendet, keine GCodes.

Also:
Wie schafft es Klipper, dass die Befehle, die keine GCodes entsprechen, von der Firmware nicht ignoriert werden?

Gesund bleiben!

mjh11

'Motorbefehle' wird hier symbolisch verwendet, wie diese genau bezeichnet werden, ist mir nicht bekannt.

Weil die Motorbefehle dem Protokoll entsprechen, das von der geänderten SOftware am MCU (=Systemplatine) erwartet werden.
Genaugenommen, wird mit dem Befehl auch ein Zeitstempel mitgesendet, mit dem der MCU weis, wann dieser Befehl gültig ist. Das zeitsystem wird immer wieder zwischen den System abgeglichen. Damit schafft es Klipper auch, mit notfalls mit mehreren MCU zu arbeiten.

Dadurch kann der MCU sich auf seine eigentliche Arbeit fokussieren, die Achsen zu steuern. Die Nebensachen, wie Display werden 'nebenläufig' bedient.

Das ist auch der Grund, warum man immer die passende MCU Software zu r Klipperversion haben muss. Wobei die MCU Software relativ lange stabil bleibt, weil die Änderungen meistens nur in Klipper sind. Ausser es wird weitere Hardware dazu gebracht, wie beim RFx000 die Auswertung für die DMS.

Deswegen interpretiert die MCU generell keinen GCode, sondern nur die MCU Befehle.

Das Programm am MCU(=RFx0000) ist nicht Klipper, sondern nur der Contollerteil. Das ist aus guten Grunde so gewählt, damit die Leistung dort verwendet wird, wo sie am besten aufgehoben ist. Und das ist nicht auf einen Arduino.
Klassisch läuft Klipper selbst auf einem RasPi der auch den Repetierserver beinhaltet. Damit ist das Gespann RFx000 mit RasPi komplett autark zu sehen. So gesehen ist das per Design, das ein leistungsfähigere Rechner Klipper laufen lässt.

Ich würde niemals einen Windows (Linux) PC als Druckserver verwenden, wenn darauf auch noch gearbeitet wird. Alleine das Windows Updateservice (oder auch die Dell Updates bei mir) können dir schon mal kurz den Port blockieren. Nein, ich bin da ein gebranntes Kind aus der Vergangenheit (nicht mit 3D Drucker, sondern andere Devices). Für Tests ist es ok, aber nicht das man das dauernd mit dem Drucker laufen lässt und wenn, dann nicht jammern. BTW. bein Win10 kann man mittlerweile das Updateservice nicht mehr ganz ausschalten/deaktivieren.

So ein 10 W Pi hat gegen einen 250 W Büro PC zumindest auf´s Jahr gerechnet Vorteile.
Ich würde auf so ein Ding nicht mehr verzichten wollen - allein die Umstöpsellei der SD-Karte war mir schon zu Beginn lästig.
Passt hier nicht ganz zum Klipper aber bei mir läuft noch ganz old school ein Repetier Server Image, bequem über ssh gewartet.
Ein Rechner der zu dem auch noch den Verwaltungsaufwand virtuellen Systems leisten muss wäre für mich genauso indiskutabel.

Gute Nacht, zero K

rf1k_mjh11 hat geschrieben: Wie schafft es Klipper, dass die Befehle, die keine GCodes entsprechen, von der Firmware nicht ignoriert werden?

Ich glaube da gibt es ein kleines Missverständnis

Beim Wechsel auf Klipper wird auf den Microcontroller im Drucker eine andere Firmware geladen. Diese andere Firmware ist ein fester Bestandteil von Klipper und interpretiert eben jene Motorbefehle. Es gibt ein spezielles Protokoll für die Kommunikation zwischen dem Microcontroller-Teil und dem Host-Computer-Teil der Klipper-Firmware, das so ausgeklügelt ist, dass das Timing am Ende stimmt.


Und noch mal der Hinweis: Die Lösung mit einer Virtuellen Maschine soll hauptsächlich zum Testen dienen, falls jemand keinen Raspberry Pi zur Hand hat und erstmal herausfinden möchte, ob Klipper überhaupt das richtige ist. Ich würde dennoch immer empfehlen, einen Raspberry Pi zu kaufen, denn auch mit der Original-Firmware bietet ein eigenständiger Druckserver große Vorteile. Auf einem Raspberry Pi dürfte die Installation am Ende sogar deutlich einfach sein, weshalb das also sogar Zeit spart.

Ich glaube dieser Thread propagiert eher eine Kreuzfahrt mit vielen Zwischenstops über die sieben Weltmeere als den möglichst direkten Weg einer Anweisung zwischen Sender und Empfänger.

Das ist wie einen Kassettenrekorder neben ein Radio zu stellen um Musik aufzunehmen.
Kennt das hier noch einer? Heute, wo die Laufmusik drahtlos von der Sportuhr in die Earbuds fließt?

Gruß, zero K

Hallo zero K,

zero K hat geschrieben:So ein 10 W Pi hat gegen einen 250 W Büro PC zumindest auf´s Jahr gerechnet Vorteile.

Wenn bei mir dann zu den 250W, die beinahe immer dann laufen, wenn ich Zuhause bin, die 10W dazu kommen, sind die aber auch unnötig, oder?
Und mit die Watt verglichen, die der Drucker beim Drucken verbrät, machen die 10W das Kraut auch nicht fett.

mjh11