Posts by fsc65

Hallo zusammen,

so, da mein Problem, nachdem ich alles, was mir hier empfohlen wurde (Netzteil mit 5,13V, Neuinstallation auf neuer SanDisc SD-Karte, alles upgedatet.....), ausprobiert habe, immer noch da war, hab ich es jetzt relativ pragmatisch gelöst:
Ich hab ja ein Macro, welches den Drucker, nachdem er abgekühlt ist, ausschaltet (per Relais an den GPIO). Dieses hab ich jetzt umgeschrieben, daß er statt den Drucker auszuschalten per shell command einfach den Raspi runterfährt und damit den Drucker automatisch ausschaltet. Den Raspi hab ich auf eine WLAN-Steckdose gehängt, die ich bei Bedarf einfach aus- und wieder einschalte und der Raspi dann wieder sauber bootet. Ich weiß, das ist jetzt nicht unbedingt eine saubere LÖSUNG des Problems, aber ein Workaround, der zumindest den Raspi davor bewahrt, immer unkontrolliert "die Füße weggezogen" zu bekommen und damit irgendwann die SD-Karte zu schrotten.

Gruß

Franz

Hallo quastra,

Ja, ich hatte auf Klipper einen Druckabbruch mit dem Kommentar, daß im Gcode ein "G1 F0" vorkommt, was anscheinend nicht verarbeitbar ist. Habe dann nach dem Fehler gegoogled und bin auf ein entsprechendes Issue bei Superslicer gestoßen, welches allerdings in/bei Superslicer schon im Dezember 2021 gefixt wurde. Mittlerweile mit dem aktuellen Orca 1.5.0 schreibt er kein(e) G1 F0 mehr in den Gcode, ist hier anscheinend auch gefixt.

Mein Drucker ist ein MKC MK2.1. Das ist ein Projekt aus dem anderen Forum. Es ist ein CoreXY mit einer Holzkiste als Grundgerüst und läuft mit Gleitlagern auf 8mm Rundstangen. Baugröße ist (bei mir) 270 x 260 x 320 mm. An Elektronik ist ein schlichtes RAMPS mit 2208 UART Treibern verbaut. Dieser Drucker lief bis vor Kurzem auf Marlin mit Octoprint und hatte seine Eigenheiten. Deshalb hab ich ihn als ersten meiner Drucker geklippert und bin damit sehr zufrieden.

Gruß

Franz

Hallo,

also bei mir sind die Softfever/Orca alle nur in einen Ordner entpackt und dann mittels .exe gestartet, also nix installiert. Ist - zumindest bei mir - bei Prusa Slicer und Superslicer genauso.

Gruß Franz

Hallo quastra,

sorry für die späte Rückmeldung, ich hatte keine Benachrichtigung, daß geantwortet wurde.
Anscheinend haben wir wirklich aneinander vorgeigeredet. Mein "Werdegang" mit den Slicern lief von 2013 mit slic3r -> Prusa -> Superslicer mit einem kleinen Intermezzo Cura 15.irgendwas.
Als dann der Softfever Fork erschien, dachte ich mir: Den probierst du aus. Diversen Aussagen im Netz zufolge soll BambuStudio ja von Superslicer geforkt worden sein (nicht verifiziert!). Ich hatte dann zwei meiner Drucker eingerichtet und war eigentlich ganz zufrieden mit den Ergebnissen, bis eben jener Fehler mit dem G1 F0 aufgetaucht ist. Deshalb eben meine Frage zu der Basis des Slicers. Rein aus Interesse, nicht aus zwingender Notwendigkeit.

Die Datenübertragung aus dem Slicer zu Octoprint und zu Klipper funktioniert bei mir auch, ohne Plugin, sowohl bei Prusaslicer, Superslicer und auch Softfever/Bambu, wobei der Klipperdrucker vorher auf Octo/Marlin lief und der Application Key schon vorhanden war und auch problemlos akeptiert wurde.

Gruß

Franz

PS: Ich zieh mir dann mal die 1.5.0 (Orca Slicer) und probiers nochmal, einfach aus Experimentierfreude.

Nachtrag: Eben die selbe Datei nochmal mit Orca 1.5.0 gesliced, Er schreibt mir kein G1 F0 mehr in den Gcode.

Hallo,

ok, ich hab ein "normales" Steckernetzteil dran hängen, das Gleiche hab ich auch an weiteren drei Raspis, die allerdings mit Octoprint laufen und damit keine Probleme. Sollte es jetzt wieder zu diesem Fehler kommen, werd ich deinen Tip mit einer neuen Installation beherzigen. Frage dazu: spricht etwas dagegen, wieder den "weiten" Weg über Raspian, kiauh usw. zu gehen? Beim vorgefertigten Image aus dem Raspberry Imager bin ich bei der /dev/serial/by-id Abfrage gescheitert (no such file/folder) und bin deshalb den anderen Weg gegangen.

Gruß

Franz

Hallo,

es lief ja, auch die Meldungen im Log haben das bestätigt und irgendwann kam eben der Fehler. Nach einem Neustart des Pi läufts nun wieder. Ich häng das Log mal an. Das Debian und auch Klipper/Mainsail/Moonraker usw. sind auf dem aktuellen Stand. Ich probier im Zweifelsfall mal einen anderen Pi (3A+ anstatt Zero 2) oder nochmal ein anderes Netzteil. Installiert hatte ich nicht das fertige Image, sondern ein nacktes Raspbian 32bit und dann mittels Kiauh den Rest. Den Befehl wpa..... eingeben ist ein bischen schwierig, wenn ich nicht auf die Konsole komme.

Gruß

Franz

sonar.txt

Hallo top_gun_de und felixna,

sonar ist jetzt eineinhalb Tage gelaufen, heute nachmittag wieder keine Verbindung zum Drucker, also aus- und eingesteckt, läuft wieder. Im Log die Fehlermeldung:

ERROR: Error 255 occured on line 149

ERROR: Stopping sonar.

Das in diversen Zeitabständen seit gestern.
Ich hab gegoogelt und das Script durchgesehen (hat gar keine 149 Zeilen). Weiß jemand, wo ich sonst noch nachsehen könnte. Laut Google hat Error 255 was mit Java zu tun, was aber hier wohl nicht der Fehler sein kann.

Gruß

Franz

Hallo top_gun_de und felixna,

hab sonar jetzt mal installiert, drucke jetzt was und schau dann morgen nachmittag mal nach, ob der Drucker/Klipper noch erreichbar ist. Das mit dem Netzteil und dem deaktivieren der Powersave Funktion hat, wie oben schon geschrieben, bei mir auch nix gebracht. Danke für den Tip.

Hallo quastra,

den Prusa und Superslicer hab ich schon länger in Gebrauch, den Softfever hab ich mal probiert und dabei ist mir das eben aufgefallen. Deshalb rein aus Interesse die Frage nach der Codebasis des Bambu/Softfever. Einzig Cura hab ich seit Version 15.irgendwas nicht mehr in Betrieb, ist mir mittlerweile zu unübersichtlich/überladen. Einfach eine persönliche Abneigung dagegen, was nicht heißen soll, das er schlechter ist als andere Slicer.

Hallo zusammen,

ich hätt da gerne mal ein Problem mit Klipper:
Ich hab Klipper auf einem Raspi Zero 2 W installiert, die Druckerfirmware erstellt, aufgespielt, alles eingerichtet, auch das automatische abschalten des Druckers per GPIO vom Raspi aus. Dies alles funktioniert auch fehlerfrei und soweit gut. Mein Problem ist nun, daß der Raspi, der an einem externen, unabhängigen Netzteil betrieben wird, irgendwann nach 5 bis 12 Stunden nicht mehr im WLAN erreichbar ist, weder die Weboberfläche (Mainsail), noch mittels Ping. Ich hab auch schon die Power Save Funktion des WLAN abgeschaltet, hat aber auch nix gebracht. Nehm ich den Raspi dann vom Strom und steck ihn wieder ein, funktioniert alles, wie es soll.

Andere Geräte/NAS/Octoprint im selben Netz sind immer erreichbar, also schließe ich einen generellen Netzwerkfehler mal aus.

Hat vielleicht irgendjemand noch einen Tip für mich?

Gruß

Franz

Hallo zusammen,

weiß jemand zufällig, welcher (SuperSlicer) die Grundlage vom Bambu Studio und damit vom Softfever 1.4.5 Fork ist?

Hintergrund ist der, daß ich neulich ein Benchy damit gesliced habe und auf meinen Klipper-Drucker geschoben und gedruckt habe, bzw. drucken wollte. Bei ca. 19,5 mm Höhe hat Klipper mit der Fehlermeldung abgebrochen, daß ein G1 F0 im Gcode steht und das wohl nicht möglich ist.
Nach ein wenig Recherche hab ich bei Supermill im Github ein Issue diesbezüglich gefunden, welches allerdings schon seit Ende Dezember 2021 gefixt ist!
Kann das sein, das Bambu einen Slicer als Grundlage verwendet, der schon über ein Jahr alt ist, bzw. seitdem keine Updates mehr eingepflegt hat?
Meine Lösung war dann ganz pragmatisch auf den Superslicer umzusteigen, mit dem ich eh schon einige Zeit (schon vor dem Bambu-Slicer), genauso wie mit dem Prusaslicer, arbeite.

Gruß

Franz

Hallo,

also das Speichern der Babysteps funktioniert - zumindest in der aktuellen Marlin 2.1.2 und in der aktuellen Bugfix - weder über "Store Settings " aufm Display, noch mittels M500 im Terminal.
Und natürlich hab ich einen Kombinationsfehler und zwar funktioniert nur EINE Probemethode, entweder manual Leveling oder mittels einer wie auch immer gearteten Probe, nicht mit zwei, etwa manual Leveling und Nozzle als Probe. "#define BABYSTEP_ZPROBE_OFFSET" braucht aber zwingend eine Probe und kein manual Leveling. Deshalb bleibe ich für meine Zwecke lieber beim manuellen Leveling. Das soll allerdings keine Anweisung für eine allein selig machende Vorgehensweise sein, sondern nur meine Meinung und meine Feststellungen zu diesem Thema.

Gruß

Franz

Hallo,

der Vorteil (bei Druckern ohne Z-Probe) des Mesh Bed Leveling gegenüber dem manuellen bilinearen Leveling ist, daß er zwar das Mesh speichert und es auch mit M420 S1 im Startcode aktiviert, was aber fehlt, ist eine Möglichkeit, den Z-Offset einzustellen und vor allem zu speichern. Beim Druckstart mit Babysteps zu arbeiten funktioniert zwar, lässt sich aber nicht speichern, d. h. beim nächsten Druck ist die eingestellte Höhe verloren und man muß wieder mit Babysteps ausgleichen. Sowohl "#define BABYSTEP_ZPROBE_OFFSET" in der configuration_adv.h, als auch eine "Fake"-Probe wie Nozzle als Probe o. ä. gibt in Kombination mit manuellem Leveln einen Kompilierungsfehler (sowohl mit der Arduino IDE als auch mit VSC), fällt also auch aus. Das wollte ich nur mal zu bedenken geben.

Gruß

Franz

Gumoing,

das hatte ich auch probiert sowohl nur Stealth Chop als auch nur Stall Guard, das gleiche: fährt ein paar cm und bleibt dann einfach stehen. Ich habs dann wie geschrieben aufgegeben, wollte mich da nicht weiter reinfuchsen, weil die Liste der möglichen Verdächtigen ziemlich lang ist: angefangen bei dem geklonten Klon eines Klones des Mega über das selbst auf 24V umgefriemelte Billigst-RAMPS über die NoName Schrittmotoren bis hin zu meiner Unfähigkeit, Marlin komplett zu verstehen.

Gruß

Franz

Hallo, ich noch mal,
Ich wollte auch noch von einer seltsamen "Krankheit" meines CoreXY mit RAMPS und Marlin berichten.

Das Ding hat eine TMC-Allergie / -Intoleranz, was auch immer.
Das äußert sich folgendermaßen: Beim Verfahren bzw. homen fährt er zwischen drei und acht Zentimetern in die richtige Richtung und bleibt dann völlig unmotiviert einfach stehen.
Probiert hab ich das mit TMC 2208 standalone, UART (Kommunikation ist möglich und ich kann den Status per M122? abfragen) und auch mit TMC 2209 von div. Herstellern (Watterott, MKS, BTT).
Mit anderen Treibern (A4988, DRV8825, LV8729) funktioniert das einwandfrei, vom Geräusch und, im Falle von per UART angebundenen TMC, auch der bequemen Einstellerei per Software, mal abgesehen.

Gruß

Franz

PS: auch dies kein Hilfeschrei, sondern eine Episode aus der Abteilung: Es gibt Dinge zwischen Himmel und Erde.....

Hallo zusammen,

ich wollte hier mal meine Erfahrungen mit o. g. Sachen zum Besten geben. Soll weder ein Hilferuf noch eine Beschwerde sein, sondern einfach nur ein Erlebnis-/Leidensbericht.

Ich hab hier u. a. einen Ender 5 mit dem alten 8-Bit Sanguino Board, auf dem ein Marlin 1.1.9 mit den Configs von Teaching Tech läuft und einen CorXY Eigenbau mit einem klassischen RAMPS auf Mega 2560. Beim Ender wollte ich einige Sachen in Marlin ändern, wie z. B. Unterstützung f. Kreise und beim CoreXY die neue Marlin 2.1.2 mit Input Shaper aufspielen, also frisch ans Werk.......
Configs erstellt bzw. abgeändert, ins vsCode mit Marlin Autobuild geladen, kompiliert (fehlerfrei!) und mit Octoprint aufs Board gebügelt, eingeschaltet, Display zeigt wirre Zeichen bzw. nur weiße Rechtecke.
Nochmal die configs durchgegangen, verglichen, nix auffälliges festegestellt, kompiliert, übertragen, eingeschaltet, Sch..... das Gleiche wieder.

Nochmal die configs......... usw. Das Ganze vier mal, immer mit dem gleichen Ergebnis, Frust und Enttäuschung macht sich breit, was tun?
Neuer Versuch mit der Arduino IDE und siehe da: Fehlermeldung, daß der Speicher auf dem Board nicht reicht, blöd gelaufen.
Also auf den Ender wieder die unveränderte 1.1.9 mit den Teaching Tech Configs aufgespielt, ham wer halt keine Kreise, kein M600...... aber läuft wieder.
Beim CoreXY auch zu wenig Speicher lt. Arduino, also kein Input shaping, dafür einen wieder funktionierenden Drucker mit lesbarem Display.
Und was lerne(n) wir (ich) draus?
Schöne neue Welt mit vielen Features in der Firmware, aber nicht für mich wegen zu wenig Platz im Speicher und vsCode sieht da generös drüber weg und sagt: alles in Ordnung, mach hin, du schaffst das!
Ich bleib dann mal bei meiner alten Firmware und sollte ich doch irgendwann wieder meinen, das geht ja sicher schneller, höher, weiter und viiiieeeeel toller, bau ich die Dinger um, entweder mit anderen Boards (Creality 4.2.7 für den Ender und ein SKR irrgendwas oder ei MKS Robin Nano oder TinyBee), oder ich versuch mich mal an Klipper, ist ja zumindest für das RAMPS super dokumentiert. Momentan fehlt mir aber die Motivation dazu, denn im Großen und Ganzen drucken die Dinger recht gut und auch zuverlässig.

Gruß

Franz

PS: wie oben schon geschrieben, kein Hilferuf o. ä. sondern nur ein launiger Bericht über meine Firmware-Odyssee

PPS: Ich hab das mal hier unter "Marlin" erstellt, sollte es eher OffTopic sein, bitte dorthin verschieben.

Hallo,

Eine vielleicht dumme Frage, aber du hast in der Konfiguration schon die richtige Druckerkinematik angegeben (corexy/cartesian)?

Gruß

Franz

Servus,

danke für die Tips, dann werd ich hier mal einen fliegenden Aufbau mit meinen Ersatzteilen machen und Versuche starten, bevor ich auf den Drucker an sich losgehe.

Sollte ich dann noch Fragen haben, rühr ich mich wieder.

Gruß

Franz

Hallo zusammen,

ich hab da mal ne Frage......
Mein CoreXY läuft aktuell mit Marlin 2.1 an einem Raspi mit Octoprint. Nach dem Druck und dem Abkühlen des Hotends auf unter 50 Grad wird der Drucker mittels Octoprint-Plugin ausgeschaltet (Relaismodul an GPIO) und der Raspi läuft weiter (eigenes Netzteil).

Kriege ich diese Funktion auch über Klipper/Moonraker/Mainsail bzw. Fluidd implementiert?

Ich habe dazu nur vage Andeutungen gefunden bzw. den Tip, wie ich mittels Tasmota den Raspi runterfahren kann.

Die Ausstattung des Druckers an sich ist 08/15, d. h. RAMPS auf Mega 2560 und klassische Steppertreiber ohne UART, SPI oder so.

Von daher sehe ich keine größeren Probleme, das Ganze zum Laufen zu bringen, nur eben das mit der Abschaltung ist mir noch komplett unklar.

Gruß und Dank

Franz

Hallo zusammen,

heute mal eine Episode aus der Geschichte Franzl und der Halot One. Was hab ich heute gelernt?
1. Auch wenn der erste Resindruck deines Lebens fehlerfrei funktioniert hat, heißt das nicht, daß der zweite, dritte...... auch funktioniert!
2. FEP Folien sind Verschleißteile und sollten in ausreichender Menge vorhanden sein.
3. Pinsel sind immer zuwenig und vor allem dort, wo man sie NICHT braucht.
4. Für Küchentücher gilt das Selbe.
5. Der Platz ist grundsätzlich zu wenig / zu klein und dort wo er am dringendsten benötigt wird, einfach nicht vorhanden.
Vielleicht sollte ich mal aufräumen und alles - wie bei einer OP - bereitlegen, wobei ich mir sicher bin daß ich Punkt 3, 4 und 5 nicht entkommen werde
Jetzt auch noch eine Frage:
Wie genau - im Sinne von exakt - muß das leveln erfolgen und kann ich anstatt der nicht mitgelieferten Calibration Card auch mit montiertem Tank direkt auf der FEP Folie leveln?
Ich hab nämlich festgestellt, daß bei den Folien verschiedene Dicken angegeben werden von 0,1 über 0,15 bis 0,2 mm.
Meinem Verständnis nach sollte doch die Buildplate auf der FEP aufliegen, nicht darüber stehen und auch nicht das Ding in das Display drücken. Deshalb meine Vorstellung: Ich montiere den - sauberen - Tank und mach das Leveling direkt auf der FEP, oder besteht die Gefahr, die Folie zu verkratzen?
Außerdem hab ich mir für die Elegoo Mercury Plus einen Halter für die Halot One Buildplate gezeichnet und gedruckt, wenn Interesse besteht kann ich ihn gerne hier hochladen.

Gruß
Franz