Beiträge von PeterK

    Wenn ein Filament-Sensor von der Firmware grundsätzlich unterstützt wird, dann sollte bei Marlin-Firmware auch Host-Action-CMDs und Host-Prompt unterstützt werden, damit das Ereignis an OctoPrint weitergeleitet wird. Ich habe an meinem auf Dual-Extruder zwei Filament-Sensoren nachgerüstet und in der Firmware unterstützt, ebenso die Host-Action-Unterstützung, und Octoprint reagiert dann sauber auf Filament-Runout

    Der Chip ist ein STM32f402 mit 48kibibyte bootloader! Klipper kennt nur den STM32f401 soll aber wohl egal sein weil die beiden baugleich sind. Alles herausgefunden geflashed etc.

    Ob die beiden wirklich baugleich sind ist noch fraglich. Es gibt kaum Infos zum 402, es scheint, dass dieser ein in China hergestellter Typ ist, und eine der Infos besagt, dass eventuell "minimale" Änderungen im Board-Design nötig sein "können". Und selbst dann gibt es bei den STM32 immer noch mehrere Untertypen, die Flash-Größe, RAM-Größe und Taktfrequenz betreffen können

    Es ist nicht sinnvoll, ein neues Mesh bei jedem Druck zu erstellen. Wenn ein Mesh vorhanden ist, dann macht es bei UBL mehr Sinn, ein Teil-Mesh zu prüfen und mit dem vorhandenem Mesh zu vergleichen und daraus eventuelle Abweichungen des Gesamt-Mesh zu errechnen. Dafür würde man G29 J benutzen, dann wird mit einem 3x3-Grid vergleichen. Bei G29 J5 zum Beispiel würde mit einem 5x5-Grid verglichen.

    Will man jedes Mal ein komplettes Mesh erstellen, müsste man bei UBL erst das vorhandene Mesh killen (mit G29 P0), und danach mit G29 ein neues Mesh erstellen. Wie gesagt, das wäre völlig unsinnig und dauert bei UBL relativ lange, gleichzeitig wirft man alle Vorteile eines UBL-Mesh weg. Wenn man jedes Mal neu erstellen möchte, ist ein Bilineares Mesh mit 5x5 oder 7x7 besser geeignet, schneller erstellt und auch genau. Allerdings müsste man für Bilinear eine neue Firmware erstellen. Ist zwar nicht unbedingt kompliziert, aber warum nicht einfach die vorhandenen Vorteile benutzen anstatt sie mit jedem Druck neu Leveln komplett wegzuwerfen?

    In manchen Fällen kann es vorkommen, dass nach einem G28 das Mesh deaktiviert ist (Firmware-abhängig). Deshalb setzt man den Befehl M420 S1 nach dem G28 ein, damit das Mesh "eingeschaltet" wird.

    In der Standard-Marlin Konfig WIRD es vorkommen, dort ist weder


    #define RESTORE_LEVELING_AFTER_G28

    noch

    #define ENABLE_LEVELING_AFTER_G28


    scharfgestellt. Letztere Einstellung entspricht einem M420 S1, das verwende ich auch.

    Da ich Bilineares Mesh verwende, kommt bei mir hinter G28 ein G29 O, dadurch wird ein vorhandenes Mesh benutzt, ohne neu zu leveln, wenn das Mesh ungültig / nicht vorhanden ist wird ein neues erstellt

    Die Eingabe von M420 T0 macht man eigentlich nur, wenn man ein neues Mesh erstellt hat (zur Kontrolle). M420 S1 bedeutet, Mesh einschalten, S0 heißt ausschalten.

    Mittels M420 Lx (x ist der Index des zu ladenden Mesh) wird ein Mesh geladen. Einfach M420 L lädt das zuletzt aktivierte Mesh.


    Bilinear Mesh bedeutet einfach eine andere Art das Mesh zu erstellen. UBL verteilt die Mesh-Punkte über die Fläche in einem Rhythmus, der weniger Fahrwege beeinhaltet, verlangt aber für ein besseres Mesh anschließende Nacharbeiten der Punkte (vor Allem der Punkte, die nicht direkt mit dem BLTouch angefahren werden können). Es können dafür aber auch mehrere Mesh erstellt werden (z.B. für verschiedene Druckbettauflagen).

    Bilinear fährt die Punkte (z.B. 5x5 Punkte, oder 7x7 oder 9x9) in geraden Linien auf X und Y ab. Normalerweise ist Marlin so konfiguriert, dass zwischen 2 Punkten virtuelle Punkte errechnet werden, da ein verbogenes Bett ja nicht plötzlich die Höhe ändert, sondern graduell. Ich verwende z.B. ein 7x7 Mesh, das aber intern auf 18x18 umgerechnet wird. Von der Genauigkeit her unterscheiden sich Bilinear und UBL nicht wirklich, da geht es um maximal wenige hundertstel mm, die beim Druck überhaupt keine Rolle spielen und schon in den Bereich der Wiederholgenauigkeit des BLTouch kommen können

    Das müsste man mit den Marlin Cracks hier dann auch erstmal klären wies es sich mit Marlin und Linear Advance verhält wenn die Stepper Treiber nicht per UART angesteuert werden (wovon ich mal ausgehe).

    Linear Avance ist entgegen landläufiger Meinung nicht von UART-Treibern abhängig und kann auch mit fest eingestellten Treibern benutzt werden. Welcher Wert benötigt wird hängt von den benutzten Beschleunigungen und Geschwindigkeiten ab und sollte für jeden Drucker gesondert ermittelt werden. Bei der neuesten Marlin-Version (bugfix-2.1.x aka 2.1.3) ist eine neuere Linear-Advance-Version eingebaut, die Teil des FT-Motion-Codes ist (FT-Motion ist insgesamt eine erweiterte Input-Shaping Variante, die über M493 anstatt M593 gesteuert wird)

    Das ist SEHR merkwürdig. Standardmäßig schreibt der Drucker selber NICHTS auf die SD-Karte, sondern liest nur davon, wenn das EEPROM in der Firmware eingeschaltet wurde (was beim V2 eigentlich der Fall sein sollte).


    Wenn möglich den Drucker mittels USB-Kabel am Rechner anschließen und eine Console aufmachen (selbst die einfache der Arduino-IDE funktioniert, wenn man die richtige Baud-Rate einstellt). Dann mit M115 die "Capabilities" abrufen, dann erfährt man in recht vielen Zeilen, was der Drucker kann und was nicht. EEPROM sollte dabei sein

    M420 T0 ist ein Code, um in einer Console mit dem Drucker zu kommunizieren. Danach gibt der Drucker auf der Console entweder einen Fehler aus (weil kein Mesh existiert), oder es wird das Mesh ausgegeben. Es ist NICHT zum Einbau in Start-Codes gedacht, sondern um zu erfahren, welche Bed-Offsets ermittelt wurden (und natürlich auch, um zu sehen dass G29 überhaupt zu brauchbaren Ergebnissen führte).

    Also M420 T0 NICHT in den Start-Code, sondern nur M420 S1. Damit wird ein (vorhandenes!!) Mesh aktiviert.

    Ich persönlich bevorzuge das Bilinear Mesh, da es bei einem nur leicht verzogenem Bett sehr schnell ein Mesh erstellt, das ausreichend genau ist. UBL ist zwar theoretisch "genauer", aber es ist sehr viel aufwändiger zu erstellen wenn man diese bessere Genauigkeit auch ausnutzen möchte. Ich habe UBL testhalber benutzt, aber sehr schnell davon Abstand genommen und die Firmware wieder auf Bilinear Mesh kompiliert

    Wenn UBL wirklich in der Firmware drin steht, dann müsste G29 ein Bed-Mesh erzeugen. wenn aber nichts passiert, dann stimmt etwas nicht mit der Firmware.


    Was sagt der Drucker denn zu M420 T0 ?

    Dann sollte ein Mesh in "Human readable" Form ausgegeben werden (z.B. in einer OctoPrint-Console).


    Ein M420 S1 sollte ein Mesh einschalten, vorausgesetzt es existiert überhaupt eins, Wenn nicht, käme in der Console eine Fehlermeldung,


    M420 S1 käme normalerweise an die Stelle, an der sich jetzt G29 befindet. Jedes Mal ein G29 zuz machen wäre kompletter Unsinn wenn wirklich ein fertiges Mesh existiert.

    Da wird wohl gar kein G29 in der Firmware aktiviert sein. Standardmäßig ist es jedenfalls nicht vorhanden. Da hilft nur eine Firmware mit Bed-Mesh zu besorgen oder selber zu kompilieren.


    Da hilft dann auch kein M420 mehr, das benötigt ein vorhandenes Mesh

    Dann hast du vermutlich ein Problem in der Verkabelung. Vielleicht Wackelkontakt.

    Das könnte auch der Grund sein, warum bei dir nichts funktioniert und der Z-Offset nicht passt.

    Auch zu grelles Licht könnte den CRTouch beeinflussen, da dieser mit einer Lichtschranke arbeitet.

    Aber das würde ich mal ausschließen.


    Der CR/BLTouch arbeitet mit Hall-Effekt, nicht optisch

    Wie kommst du auf dieses extrem schmale Brett, ich hätte nur eine "Vermutung"? Hast du schon mal davon gehört, dass man Source-Code lesen kann, um zu erfahren, was tatsächlich gemacht wird? Fast jede Docu zu aktueller Software ist im Zweifel nicht aktuell. Das gilt auch für Klipper, genauso für Marlin. Irgendjemand muss das Zeugs ja auch schreiben.

    Und ich HABE ja geschrieben, dass Bögen intern wieder zerlegt werden. Und auch warum. Natürlich zerlegt Klipper es auch wieder. Der Rechenaufwand für komplette Bögen kann gewaltig sein, und der Speicheraufwand erst recht.

    Klar kann Marlin das. Ich habe auch den P-Parameter eingeschaltet, der Drucker fährt da komplette Bögen ohne anzuhalten. Man kann sich ja auch den erzeugten GCode ansehen (Prusa-Slicer hat den ARC-Support eingebaut). Da sind keine Unmengen an "virtuellen" Bögen erzeugt. Intern werden je nach Konfig Bögen zerlegt in Einzelteile, um den Rechenaufwand (vor allem den benötigten Speicher für die Hinterlegung der Bewegungen) im Zaum zu halten. Wenn man genug Rechenpower und genug freien Speicher hat, kann man die Teil-Bögen größer machen. Aber diese Teile sind KEINE geraden Stücke, sondern Bogensegmente. Die gepostete Beschreibung ist uralt und missverständlich, überhaupt ist viel von der Marlin-Beschreibung abseits des Github-Codes nicht auf dem aktuellen Stand. Zum Beispiel ist die Option MM_PER_ARC_SEGMENT über 4 Jahre alt und abgelöst von Optionen mit MAX- und MIN-Werten

    Erst mal : Marlin 2.1.2.2 ist leider Murks, entweder auf 2.1.2.1 "downgraden" oder auf die bugfix-2.1.x upgraden (letzteres ist empfehlenswert, das ist praktisch die 2.1.3 Version). Bei 2.1.2.1 wurde versucht, einige Features der bugfix-Version mit einzubauen, ohne die geänderten Configuration(_adv).h richtig umzusetzen (2.1.2 hat noch einige ältere Einstellungen, die es so in bugfix gar nicht mehr gibt).

    Und diese Fehler kommen durch eine Fehlkonfig in Marlin, da stimmen einige Offsets nicht

    Ein Raspi 3 reicht locker für 2 Instanzen OctoPrint (es gibt Anleitungen, wie man weitere Instanzen aufsetzt). Ein Raspi2 kommt mit 2 Instanzen an seine Grenzen, da wären 2 Stück besser. Der Raspi Zero2 W wäre auch geeignet (für jeweils einen Drucker)


    Düse wird weiterhin nicht mittig gehomt und CR Touch fährt vorne über das Druckbett hinaus....
    Also alles wie vorher.... :(

    Beim Homen mit CRTouch / BLtouch wird NIE die Düse in die Mitte gefahren, sondern der Sensor.

    Der soll ja die Mitte ertasten, um diesen Punkt für die Nozzle zu fühlen