Firmware-Mod 1.43.88

[AtlonXP]

Hallo Wessix,
ne ne, da wird nix mehr gedruckt.

Ich muss hier noch nachgehen, ob der Fehler bei einem kompletten Rest, also Drucker aus / an auch vorkommt.
Und erst danach einen neuen Druck starten.
Hier könnte auch noch eine Fehlerquelle drin sein, da es nicht immer vorkommt.

LG AtlonXP

[Nibbels]

Der Bug kommt mir bekannt vor. Kann mangels Erinnerung grad nichts genaues sagen aber ich schätze das dürfte bei den neueren Versionen hinfällig sein.

Vermutlich morgen gibts zur .94 noch einen weiteren M3070 pausegcode patch. Also eine 1.43.95.

Lg

[AtlonXP]

Tu nor mol langsam, ich glaube da kommt von mir noch was nach.
Ich habe meinen Test noch nicht beendet.

LG

[AtlonXP]

Hallo Nibbels,
mein Test ist beendet.

Der Bug mit Ouput Object hat nichts mit dem Drucker reset zu tun.
Er kam trotzdem.
Es könnte sich hier um die 30 % Verfahr Geschwindigkeit handeln.
Ich habe dies nicht mehr weiterverfolgt.

Und nun zum Nächsten:
Ich hatte moniert, dass bei meiner Startmade Digit Flow schon greift, obwohl ich es nicht will und auch nicht eingeschaltet habe.
Mein Start Code ist dem entsprechend auch konfiguriert.

Wenn bei einem Druck Ende, der Drucker nicht Resetet wird, dann bleibt Digit Flow beim nächsten Druckstart bei der Startmade eingeschaltet!
Ich bin zwar kein Programmierer, aber sollte der Hauptspeicher nicht bei Druckbeginn komplett geleert sein?
Irgendwie muss das RAM bei Druck beginn völlig geleert (zurückgesetzt werden).

Wenn ich das von Hand tue, dann ist Digit Flow bei der Startmade auch nicht aktiv.
Ich könnte mir vorstelle, dass viele unsere Probleme hier versteckt sind.
Was denkst du darüber?

LG AtlonXP

[rf1k_mjh11]

Hallo Nibbel, AtlonXP,

Nachdem ich mir einbilde, dass viele der älteren Firmware Bugs (vor den Community Versionen Nibbels) ebenfalls von solchen 'Speicherleichen' wie sie AtlonXP beschreibt, stammen könnten, schlage ich vor, Nibbels erstellt einen GCode Befehl, der den gesamten Speicher aktiv löscht, um anschließend als letzten Akt ein Reset durchzuführen.
So ein GCode, ganz zu Anfang eines Druckauftrags, könnte solche unerklärliche Verhaltensweisen verhindern.

(Hinweis: ich bin kein Programmierer, daher weiß ich gar nicht, ob so was möglich wäre - mit meinem Vorschlag zieht sich das Programm mitten im Laufen praktisch selbst den Boden unter den Füßen weg .... Wer weiß, ob das Programm danach normal weiterlaufen kann.).

mjh11

[Nibbels]

Hallo

Ich muss evtl. mal verlinken/beschreiben was Digit Flow Compensation überhaupt ist.
http://www.rf1000.de/wiki/index.php/Dig ... mpensation
Man kann dem Drucker erklären, dass zwischen z.B. 5000 und 10000 digits während des Druckens die Druckgeschwindigkeit und evtl. der Flow automatisch zurückgenommen werden soll.
Dabei definiert man diese Min-Max-Grenzen und die Stärke des Effektes bei der Max-Grenze.

Beispiel:
Von 5000 bis 10000 digits soll der Drucker immer langsamer laufen.
Maximal soll F=-50% Geschwindigkeit gedrosselt werden.
Dann läuft der Drucker bei 5000 noch so schnell wie normal und bei 7500digits -25% so schnell. Und bei 10000digits noch -50% so schnell.

(Und stellt man die Emergency-Pause auf 12000 digits, pausiert der Drucker, wenn selbst bei der halben Geschwindigkeit wegen Düsenverstopfung noch digits von 12000 erreicht werden.)

Zu dem Problem: Man aktiviert mit dem GCode oder im Menü mit M3911 das Feature. Der Code hört noch auf S und P für Minimal und Maximaldruck. E-xx für Extrusions-Flow-Änderung und F-xx für Feedrate-Änderung.

Setzt man im Endcode M3911 E0 F0 ist das Feature aus. Oder wenn man den Drucker neu startet.

Bisher haben wir für die Aktivierung des Features noch keinen EEPROM-Support, also merkt sich der Drucker nicht, was zuletzt eingestellt war. Weder für die Grenzen S und P noch die Änderungswerte E und F.
Eigentlich bin ich inzwischen der Meinung, dass wir das Feature nicht so flüchtig haben müssen. Und schon garnicht automatisch löschen. Man muss das nur wissen. Das Feature ist dermaßen gut, dass es, wenn man es einigermaßen moderat einstellt, nie schadet - und meist hilft.

Die automatische Startmade M3912 nutzt z.B. auch das Feature.
Sie merkt sich was vorher eingestellt war, legt mit eigenen Settings die Startmade ab und stellt die Werte zurück auf die Vorwerte.

Will man einen ganz unverstellten unveränderten Drucker, ist M112 am besten. Das muss man halt gesondert ausführen, denn dann ist der Gcode normalerweise abgebrochen.
Ein GCode der alles so macht wie man es sich wünscht werde ich nicht bauen können. Denn eigentlich gibts schon für alles eigene GCodes und es müsste sich nur jeder sein eigenes Sauber-Script erstellen oder eben schlicht im Startcode alles richtig machen.

LG

[AtlonXP]

Hallo Nibbels,
ich denke du hast mich nicht richtig verstanden.
Mir geht es nicht um Digit Flow, ebenso könnte ich mich an dem Hauptmulti für Geschwindigkeit oder auch Materialmenge aufgeilen.
Ich wollte damit sagen, dass wir bei druckbeginn noch Reste im RAM haben wo uns unterwegs aufstoßen können.
Sollte man den RAM (nicht den ROM) bei / vor Druckbeginn reinigen?
Wir schleifen sonst Altlasten mit uns rum, wo uns in die Suppe spucken können und auch den RAM unnötig belegen.

Wie bin ich da darauf gekommen?
Es wurde ein kleines Druckteil gedruckt mit einer Druckdauer von 0,5 Stunden.
Nach Auftrag, einfach das Teil gepflügt und einfach wieder Druckstart.
Folglich sind alle Einstellungen noch im RAM vorhanden.

Ich empfehle in Zukunft, den Drucker immer nach oder auch vor dem Druckstart zu reseten, damit der RAM wieder leer ist.
Man kann auch als letztes im End G Code M112 setzen, das werde ich testen.

LG AtlonXP

[Nibbels]

Hmm, so funktioniert das eigentlich nicht.

Es gibt schon Funktionen, die sich ein Stücklein Ram reservieren und irgendwas schreiben.
Wird der Ram dann nicht wieder freigegeben ist das schlicht ein Bug.
Die meisten Variablen werden aber innerhalb einer Funktion deklariert, dann u.U. vom Compiler wegrationalisiert oder eben nicht und diese sind eigentlich nach dem Ende der Funktion wieder weg.
(Auf den Druckern läuft nicht Windows mit Filecache und Registry, sondern alles ist so minimalistischs gehalten wie nur möglich.)

Was du vermutlich im Endeffekt meinst, ist, dass Einstellungen nicht automatisch zurückgesetzt werden.
Das ist aber eigentlich die Aufgabe von Start und Endcode, denn generell weiß der Drucker eigentlich nicht was Druck-Start und Druck-Ende ist. Er befolgt nur eine Abfolge von Befehlen und dass genau so wie es der Meister will.
USB: Der Drucker kann Druckstart und Druckende nur mit Tricks erraten oder darauf schließen, wenn länger keine Befehle mehr ankamen oder bestimmte Befehle abgesetzt werden wie z.B. M3079. Meist trägt man die Aktionen für Vorher und Nachher im USB-Host als Events ein. Denn nur der Host weiß wirklich genau wann der Druck startet oder endet - nicht die Firmware.
SD: Man könnte Druckstart und Druckende mit Funktionen belegen. Start ist klar und Ende ist wenn die Datei endet oder ein Abbruchbefehl verwendet wird.

Im Idealfall gibts deine "Ram-Reste" also nicht! Wir reden hier quasi wirklich nur von vordefinierten Excel-Kästchen diverser Länge die eindeutige Plätze+Funktion haben und in manchen Fällen umgeschrieben werden wollen.
M112 ist natürlich die Schrotflite auf alles.
Man sollte trotzdem lieber rausfinden was einen nervt und dann einzeln die Befehle anpassen, ergänzen oder in den Startcode/Endcode einpflegen.

LG

[zero K]

Guten Abend

Den M112 in eine Codesequenz zu plazieren sollte eigentlich nicht nur den gewünschten Effekt bringen.

Denn wenn die Codesequenz "Endcode" zur Ausführung geladen wird, ist es völlig egal wie weit hinten der M112 steht.
Ich weiß nicht wie und wodurch, aber er hat eine herausragende Ausführungspriorität - er wird dann vor allen anderen Anweisungen ausgeführt, ein Herausreichen des Modells wird nicht mehr ausgeführt.

Gruß zero K

[AtlonXP]

zero K, du könntest Recht haben.
Der Test ist beendet und du hast nicht Recht.

Der Ablauf ist so wie ich es mir vorgestellt habe.
Mit dem Hauptmulti bin ich hochgegangen (60%) bei den letzten paar Layern
und die Bug Meldung ist auch nicht erschienen.

LG AtlonXP