Oh man, so langsam glaube ich, der Type ist nur ein Troll. Ich geh da jetzt nicht mehr drauf ein, es ist alles zum Thema gesagt. Meine persönliche (!) Zusammenfassung behält ihr Gültigkeit in vollem Umfang. Ansonsten kann sich jeder seine eigene Meinung bilden.

@Digibike, wenn Bann, dann bitte alle Accounts

Tja Dennis, ich würde sagen, du hast hier im Forum endgültig verschissen…

Christian hatte dich nur auf meine Bitte hin, noch etwas gewähren lassen.
Dieser Dispense ist nun auch aufgebraucht.

Mach es gut und besser, als dein jetziger Auftritt hier und heute…

LG AtlonXP

So ist das halt, wir sind halt ein "verschwinde oder wir hauen alle drauf"-Forum... Diese "Verschobene Wahrnehmung" begegnet mir immer wieder, gefühlt in neuerer Zeit immer öfter: Alle sind Böse, nur ich nicht, ich bin der Engel...
Ich habe mal einen Sketch von Dieter Hallervorden gesehen, der mir da immer unweigerlich einfällt: Er fährt auf der Autobahn und hört eine Verkehrsfunkdurchsage: Achtung, auf der A... kommt Ihnen zwischen ... und ... ein Falschfahrer entgegen! Darauf ruft er: Einer??? Tausende!!!
Kommt halt immer auf die "Perspektive" an.
Seinen 2.ten Account habe ich gestern nicht mehr gesucht - war mir fast klar, daß sich das "von selbst" erledigt!
Multiaccounts sind so ein Thema. Aber, wenn ich Sie nicht gleich finde - spätestens, wenn der eigentliche Zweck dieses Multiaccounts zum tragen kommt, finde ich Ihn - verzögert halt nur etwas...
Eigentlich hatte ich Ihm eine Verwarnung bis zum Wochenende und keinen Bann ausgesprochen. Aber die Reaktion verheißt wenig Einsicht bezüglich dem, was ich Ihm geschrieben hatte. Gefangen in der "Opferrolle", würde ein Psychologe wohl sagen... Dabei hatte ich klipp und klar gesagt, bis zum Wochenende und damit bis dahin mal in Ruhe auseinander setzen, was es mit diesen "Wägemesszellen" so auf sich hat. Schließlich kann er das ja gar nicht von seinen anderen Druckern kennen, weil es bei erscheinen der RFx000-Klasse eine Patentgeschichte von Conrad war.
Leider den Wink nicht verstanden und schon gar nicht das geschriebene. Von daher, viel Glück wo auch immer.

Christian

Hallo Dennis,

dennis02121978 hat geschrieben:Mir ist es gelungenes das DMS ins Marlin zu Integrieren.

Das nährt ja die Hoffnung auf ein ewiges Leben für die RFx000-Klasse.

Enthält dann Marlin nur die Funktionalität der Bett-Abtastung, oder ist da auch schon die Z-Kompensation in vollem Umfang dabei?
Dass die erweiterten Kniffe der Community Version auch schon enthalten sind, ist vermutlich zuviel geträumt, oder?

dennis02121978 hat geschrieben:Momentan habe ich den Schwellenwert für den Kontakt zum auslösen des Endstops mit Nozzle as Probe fest vergeben aber werde das dann noch umschreiben damit man die Sensibilität per Gcode mitgeben kann.

Mit 'Schwellenwert' wirst du hoffentlich den Schwellenwert der Differenzkraft meinen, da jeder Drucker einen unterschiedlichen Ruhewert aufweist oder aufweisen wird.

Jedenfalls sieht es so aus, als ob hier einiges an Fortschritt gemeldet wird.

Weiter so.

Gesundheit allerseits!

mjh11

rf1k_mjh11 hat geschrieben:Das nährt ja die Hoffnung auf ein ewiges Leben für die RFx000-Klasse.

Enthält dann Marlin nur die Funktionalität der Bett-Abtastung, oder ist da auch schon die Z-Kompensation in vollem Umfang dabei?
Dass die erweiterten Kniffe der Community Version auch schon enthalten sind, ist vermutlich zuviel geträumt, oder?

Ich möchte nichts schlecht oder kaputt reden, aber ich muss hier dennoch einen Kommentar los werden: Es ist verflucht viel Zeit in die Entwicklung des Abtast-Algorithmus, des Kompensations-Algorithmus sowie der erweiterten Algorithmen geflossen. Das fing natürlich lange vor der Existenz dieses Forums mit der Entwicklung bei Conrad an. Das ist nicht mal so eben in nem halben Nachmittag in eine andere Firmware eingebaut. Das Ganze geht schon mal damit los, dass ein einfacher Schwellwert-Algorithmus am Ende einfach keine ausreichend genaue und reproduzierbare Ergebnisse liefert. Ich fürchte, da wird noch viel Frust auf dennis02121978 zukommen. Ich könnte dir, Dennis, jetzt im Detail erklären, wie es besser geht, aber aus meiner Sicht führt das in die falsche Richtung. Wenn wir der RFx000-Klasse zu einem "ewiges Leben" verhelfen wollen, dann sollten wir zum einen keine zersplitterte Community schaffen, und zum anderen einen ganz bestimmten Fehler nicht wiederholen (dazu gleich mehr).

Es gibt mit Klipper bereits eine Firmware, die auf anderen Boards lauffähig ist. Dort gibt es bereits einen gut getesteten Abtast-Algorithmus, und die Z-Kompensation ist von Haus aus deutlich fortschrittlicher als bei der Original-Firmware. Ebenso sind erste erweiterte Kniffe der Community-Version bereits vorhanden: der Z-Sense-Offset existiert bereits und kann genutzt werden, nikibalboa arbeitet bereits an der digit flow compensation (da gehen gerade ein paar PMs hin und her, ich denke, es gibt demnächst auch einen Thread zu dem Thema). Weitere Features dieser Art sind *viel* leichter implementierbar als bei Repetier oder Marlin, weil man Python Code auf einem PC-artigem System (Raspberry Pi oder gar echter PC) nun mal viel leichter schreibt als C++ Code für einen Microcontroller, den man dann auch für jeden Versuch erstmal neu flashen muss.

Wenn es nun eine dritte Firmware-Version gibt, die auf Marlin basiert, gehen erstmal relativ viele Ressourcen unserer Community in die Entwicklung der absoluten Basics auf Basis dieser neuen Firmware. Davon hat aber erstmal niemand so wirklich Vorteile. Mein Vorschlag wäre daher, lieber gemeinsame Sache zu machen und sich auf die bereits funktionierende Firmware zu konzentrieren, statt noch ein Fass ohne Boden aufzumachen. Wie gesagt: Das ist ein Vorschlag, ich möchte auch dich, dennis02121978, nicht vergraulen oder verjagen, sondern dich eher einladen, lieber mit mir zusammen zu arbeiten als dein eigenes Ding als "Konkurrenz-Projekt" aufzuziehen - denn was nützt uns hier Konkurrenz.

Und nun zu dem Fehler, den wir nicht wiederholen sollten (auch wenn die Community hier den gar nicht gemacht hat): Ein ganz großes Problem der Original-Firmware ist, dass sie ein Fork einer sehr alten Repetier-Firmware ist. Auch Repetier hat sich inzwischen massiv weiterentwickelt und wurde zwischenzeitlich quasi komplett neu geschrieben. Leider haben die Entwickler bei Conrad (wie das in der Industrie oft üblich ist) sich keinerlei Gedanken über die langfristige Software-Pflege gemacht. Sie haben einfach den Source-Code kopiert und nach belieben modifiziert. Jegliche Änderung vom "Upstream" (also am Original-Repetier-Projekt) wurde nicht übernommen und lässt sich jetzt auch nicht mehr übernehmen, denn es gäbe Konflikte an allen Ecken. Deshalb sollte jeder Versuch, eine zukunftsfähige Firmware für unseren Drucker zu schaffen, sich immer zum Ziel setzen, die nötigen Änderungen in den Upstream integriert zu bekommen, oder notfalls zumindest die eigenen Änderungen möglichst separat zu halten und regelmäßig die Neuerungen vom Upstream zu übernehmen. Unterlässt man das, stehen wir relativ schnell wieder da, wo wir jetzt mit der alten Firmware sind: aktuelle Hardware wird nicht unterstützt und jede kleine Änderung bringt ein riesen Kuddelmuddel mit sich.

Meine Sicht auf diese Dinge mag etwas speziell sein, aber ich mache derartige Dinge beruflich. Wir betreiben Anlagen, die müssen 20-30 Jahre oder auch länger laufen, und müssen auch nach zig Jahren noch erhebliche funktionale Updates bekommen, die konzeptionell ursprünglich gar nicht vorgesehen waren. Wir sind mit dem klassischen Ansatz (Code kopieren und modifizieren), der wohl in der eher kurzlebigen Consumer-Elektronik-Industrie der Standard ist (und auch in der Forschung, wo ich ursprünglich her komme), einige Male komplett auf die Schnautze gefallen. Ich selbst musste schon bei zwei Projekten die Software deswegen komplett neu schreiben, weil die Code-Basis einfach nicht mehr wartbar war. Wenn man sich um eine saubere Code-Basis nicht kümmert, ist es garantiert, dass man früher oder später in diese Probleme rennt. Von Klipper weiß ich, dass dort eine sehr saubere Code-Basis verwendet wird, und auch regelmäßig aufgeräumt wird. Ich will nicht behaupten, Marlin wäre da schlechter, aber es bleibt das Mako des größeren Entwicklungsaufwands gerade für unsere fortgeschrittenen Algorithmen.

Ich verstehe noch immer nicht so richtig die Bedenken gegen Klipper. Der RFx000 ist prinzipiell kein Drucker, der für Leute geeignet ist, die gemäß Plug&Play einfach losdrucken wollen. So oder so ist es auch nicht ganz einfach, sich eine Marlin-Firmware oder die Community-Version zu flashen. Ich denke auch, dass es viele Möglichkeiten gibt, das Ganze noch deutlich zu vereinfachen. Wir könnten z.B. ein Raspberry-Pi-Image zur Verfügung stellen, das man sich nur auf die SD-Karte laden muss, und schon ist alles weitgehend einsatzbereit. Ja man braucht immer noch einen Raspberry-Pi, aber der kostet so viel wie ein oder vielleicht zwei Spulen Filament, und viele benutzen den ohnehin, weil er einfach viel Komfort bietet. Und wenn man es mal objektiv betrachtet, ist das Flashen der Firmware von einem Raspberry-Pi aus sehr viel einfacher als von einem Windows PC aus (das gilt auch für die Repetier-Firmware und sicher auch für Marlin), schon allein, weil Befehle viel leichter in ein Wiki geschrieben werden können als "Klick-hier-dann-da"-Anleitungen.

Ich kann so etwas nicht alles alleine machen. Da braucht es möglichst viele, die Dinge ausprobieren, Anleitungen im Wiki schreiben und/oder erweitern, Bugs finden, und vielleicht sogar Raspberry-Pi-Images erstellen. Wenn aber immer nur (m.M.n. ungerechtfertigte) Bedenken gestreut werden, weil angeblich alles so kompliziert sei, kommen wir da nicht weiter.

Im Moment gibt es einfach zu wenige Nutzer der Klipper-Firmware. Deshalb steht erstmal mein Hilfs-Angebot an jeden, der dort einsteigen möchte. Wenn eine gewisse kritische Masse erreicht ist (2-3 Klipper-Nutzer mit jedem Drucker-Typ) und ein paar Leute darunter sind, die auch mal die eine oder andere Idee aktive selbst umsetzen (wie z.B. nikibalboa aktuell, und af0815 ja schon in Vergangenheit, aber auch andere Ideen wie z.B. das R-Pi-Image), dann wird vieles plötzlich sehr viel einfacher.

Ich würde es vorziehen die Diskussion nicht im Thread von dennis zu führen.

Der Nano liefert ein einfaches On/Off Signal an Marlin, soweit ich das verstanden habe, keinen Wert (Bzw. per Bild gesehen habe). Wenn das so korrekt ist, ist es egal ob Marlin oder Klipper, die Anbindung des HX711 ist problematisch, auch aufgrund des Timings das einhalten werden muss.

Dennis, die Idee von dir ist mal das naheliegendenste, deswegen Bau munter weiter.

af0815 hat geschrieben:Ich würde es vorziehen die Diskussion nicht im Thread von Dennis zu führen.

Genau genommen entspricht dieser Einwand unserer Forumsregel.

Wenn ich jedoch Dennis wäre, dann würde ich für seinen speziellen Fachbeitrag,
doch lieber einen neuen Beitrag eröffnen.
Die Vorgeschichte in diesem Beitrag ist nicht gerade erbrickelnd.
Stimmst du mir da zu Dennis?

Darum halte ich diesen Beitrag gerade richtig, das Für und Wider auszudiskutieren.
Ich werde mich hier nicht auf irgendeine Seite stellen, sondern einfach ein paar Argumente liefern.

Zunächst zu unserer Community FW:
Nibbels hatte sich etwa ein ¾ Jahr fast in Vollzeit Mühegegen die Altlasten in der FW auszumerzen.
Meiner Meinung nach hat er auch gute Arbeit abgeliefert.
Natürlich gibt es leider noch ein paar Fehler die mich auch ärgern.
Jedoch lassen die meisten Fehler sich umschiffen.
Da ich den Fräsmodus in der Community FW abgeschaltet habe, wurde mehr Speicher frei.

Diesen Speicher habe ich für die USB Kommunikation weiter verwendet.
Es gibt für den USB Puffer 3 Zeilen in unseren Dateien.
Ich habe diese so konfiguriert, dass auch bei hoher Geschwindigkeit kein Stockeln vorkommen kann.
Insbesondere wenn der Drucker hoch aufgelöste Kreise aus meinem CAD druckt, wird bei zu hoher Kommunikationsmenge die Druckgeschwindigkeit bei Vollgas auf etwa 28 mm/s gesenkt.

Nur bei dem Umsetzen von der einen Layerbahn zur nächsten könnte man meinen, da stockelt was.
Ich würde jedoch behaupten, der Drucker muss kurz runter auf fast null Speed, zum Umsetzen.
Man muss jedoch klar sagen, unsere Motoren laufen etwas lauter und rau.
Von meinem TronXY zum RF1000 liegen da schon Welten.
Ich werde mich dem Thema annehmen, habe aber nicht viel Hoffnung auf eine wesentliche Besserung.

Als Otto normal Drucker, scheue ich mich ein wenig den Pi einzusetzen.
Im Moment ist der 4er Pi mit 4GB zu teuer, oder gar nicht zu bekommen!
Jedoch muss ich immer wieder feststellen, dass mit Klipper immer mehr entwickelt und erweitert wird.

Da ich nicht nur einen RF1000 im Keller habe, sondern meinen TronXY irgendwann auch in Betrieb gehen soll,
wäre es schon eine nette Sache, System übergreifend ohne viel Programmieraufwand die ganzen Möglichkeiten
über die DMS Funktionen auch in Marlin und damit im TronXY verwenden zu können.

Unsere ganzen Funktionen in eine FW zu integrieren würde sicherlich eine Menge Arbeit machen.
Man muss hier bedenken, die Digits und die daraus resultierend Funktionen, sollten fast in Echtzeit ablaufen!
In meinem TronXY ist ein Marlin Board GTR_V1 verbaut.
Egal was und wie entwickelt wird, modular zum Einfügen für jedes verfügbare oder auch zukünftige Board wäre hier nicht schlecht.

Es stellt sich hier die Frage, wie kann man das am besten Umsetzen.
Dann wäre nicht nur mein RF1000 Nutznießer, sondern auch mein TronXY.

LG AtlonXP

af0815 hat geschrieben:Ich würde es vorziehen die Diskussion nicht im Thread von dennis zu führen.

Naja, es handelt sich um eine Antwort auf Dennis' Idee mit Marlin. Das gehört m.M.n. also genua hier rein.

dennis02121978 hat geschrieben:Aber ich hatte mir Klipper mal angeschaut und mir fehlt einfach das Display mit den ganzen Features.

Gibt es, vielleicht hilft das hier weiter:
https://www.youtube.com/watch?v=gYP2j-dUrBY

Und wie auch schonmal gesagt auch die Funktionalität ohne Raspberry zu drucken.

Wozu? Ich bin da pragmatisch. Wir hatten übrigens zweitweise den SD-Card-Support in der Community-Firmware deaktiviert, weil es Probleme gab. Da ging also auch nur Drucken von irgend einem Host-System aus. Wie gesagt muss Klipper nicht zwingend auf einem Pi laufen, jedes PC-ähnliche System sollte gehen, wahrscheinlich sogar Windows. Wobei ich das nicht empfehlen würde, schlicht der Einfachheit wegen.

Wenn das Originale Board defekt ist funktioniert Klipper mit DMS auch nicht mehr.

Wie kommst du da drauf? Klipper läuft selbstverständlich mit allen aktuellen Boards. Ein HX711 kriegt man an jedes Board angeschlossen, das irgendwie SPI kann (irgendwie: 3 freie und zugängliche GPIO-Pins genügen notfalls für Soft-SPI). Genau deswegen schreibe ich das hier doch die ganze Zeit. In diesem Thread geht es doch darum, das Mainboard auszutauschen.

Vielleicht sollte man das Nano als Blackbox eher weiter aufbohren um somit egal welche Firmware das DMS genutzt werden kann.

So langsam verstehe ich, was du da mit dem Nano machst. Du wirst damit aller Voraussicht nach keine zufriedenstellenden Ergebnisse hinbekommen, sorry. Damit ist etwas anderes als ein quasi-statischer Schwellwert ja nicht machbar. Schon der ganz ursprüngliche Algorithmus der Original-Conrad-Firmware war da weiter. Erst recht sind alle fortgeschrittenen Features (sense offset, digit flow compensation, etc.) komplett unmöglich, denn dazu muss ein Algorithmus in Abhängigkeit der gemessenen Kraft (ggf. einschließlich vergangener Messwerte) in den Bewegungsablauf eingreifen können. Das bekommst du so nicht realisiert. Vom Grundprinzip wird das immer ein reines ON/OFF bleiben, es sei denn du schließt den HX711 direkt am Mainboard an (ohne Nano) und veränderst direkt die Marlin-Firmware. (Den Zwischenschritt über den Nano kannst du dir sparen, der kostet nur wertvolle Zeit/Latenz...)

AtlonXP hat geschrieben: Zunächst zu unserer Community FW:
Nibbels hatte sich etwa ein ¾ Jahr fast in Vollzeit Mühegegen die Altlasten in der FW auszumerzen.
Meiner Meinung nach hat er auch gute Arbeit abgeliefert.

Hat er unbestritten, nur hätte er diese Arbeit noch für mindestens ein Jahrzehnt fortsetzen müssen, damit die Firmware wirklich gut wird

Nur bei dem Umsetzen von der einen Layerbahn zur nächsten könnte man meinen, da stockelt was.
Ich würde jedoch behaupten, der Drucker muss kurz runter auf fast null Speed, zum Umsetzen.

Bist du auf der Development Version oder auf der neuesten Stable? Da war ein Bug, den ich in der Development behoben hatte. Bei eingeschalteter Z-Kompensation wartet er unnötig in bestimmten Situationen auf irgendwas an der falschen Stelle und stoppt daher komplett. Das könnte dein Problem verursachen. Oder halt ein ähnlicher Bug dieser Art, den ich nicht gefunden habe, denn die FW dürfte voll davon sein.

Im Moment ist der 4er Pi mit 4GB zu teuer, oder gar nicht zu bekommen!

Der ist ja nicht nötig, kleinere/ältere tun es auch (ab Raspberry Pi 2). Ebenso Alternativen der Konkurrenz (Banana Pi oder was auch immer), solange sie nicht extrem viel langsamer sind oder weniger als 1GB RAM haben. Auch ein alter PC kann hier sehr gut ein zweites Leben finden... Quasi jeder noch existierende PC, der nicht aus einem Museum entwendet wurde, dürfte ausreichend Leistung haben - die Pis sind nämlich nicht wirklich schnell. Als Anschluss braucht man nur USB.

In meinem TronXY ist ein Marlin Board GTR_V1 verbaut.

Das Board wird ja von Klipper problemlos unterstützt... Wie wahrscheinlich quasi alle handelsüblichen Boards.

Noch bin ich bei der 1.45.00 Version.
Es wird sich bald ändern.

Ich glaube jedoch nicht, dass da ein Fehler vor liegt!

LG AtlonXP