Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

[Nibbels]

Hmm..

vor einiger Zeit war ein kleiner Bug in der Firmware. Du hattest dann beliebige Sachen umkonfiguriert und zufällig ist der Bug auf was anderes durchgeschlagen und hat dann nicht weiter gestört.
Ich selbst kenne wie gesagt das stocken nicht. Evtl. muss ich mal wieder meinen Drucker nach Neuenstadt schleppen und du zeigst mir ob du den siehst. Dass du in irgendeiner Form M400 in den Gcode/LayerWechsel-Code einfügst kann nicht sein?

LG

[AtlonXP]

Hallo Nibbels,

der Gcode auf der SD Karte hat den M400 Befehl nur im endingGcode integriert.
Das wurde automatisch von S3D hinzugefügt.

Ich würde so sagen, mit der SD Karte war der Sekundenschlaf etwas Kürzer als wie mit der USB Verbindung.

Wenn ich was am Puffer in der FW ändere, gilt das dann nur für die USB Verbindung oder auch für das Lesen der SD Karte?
Das Problem fällt mir nur bei kurzen runden Bahnen auf!

[Nibbels]

Der Cache ist so groß, wie es der Ram zulässt. Man könnte da evtl. noch einen EIntrag dazuschummeln, aber ich weiß es nicht genau.
Irgendwo stand, man soll dem Prozess ca. 1kb (oder 900byte) Ram übrig lassen, aktuell sinds grob 1300byte ram. Ohne Milling-Mode geht evtl. noch etwas mehr, aber ich will dir nicht freiwillig raten, an sowas zu optimieren. Zumal die Geschwindigkeit bei leerer werdendem Puffer automatisch sinken müsste. Die Configurations-einträge dazu habe ich dir ja schon genannt gehabt.

Ich muss mir dein Gerät mal live anschauen, sodass ich verstehe was du meinst. Dazu die Logfiles.

Natürlich glaube ich euch wenn ihr sowas sagt, doch ich selbst habe das Problem glaube ich nicht. Doch auch ich hatte mal diesen einen Fehler den angeblich sonst niemand hatte. Darum verstehe ich dich. Am Ende wars doch ein Bug. Kann aber z.B. auch was anderes sein. (Ewig dauernder Retract, weil langsam etc.)

LG

[AtlonXP]

Nun habe ich die FW 1.38.33 aufgespielt.
Vorher war noch die FW 1.38.08 drauf.

Ich weis nicht was Nibbels da alles in dieser Version angestellt hat.
Ich hoffe, dass hierzu noch etwas Erklärung einfließt.

Zu meinem Problem Sekundenschlaf am RF1000.

Folgende zusätzliche Änderungen habe ich in die Configuration.h und RF1000.h eingepflegt.

RF1000.h:

RF1000.h: Z895 #define LOW_TICKS_PER_MOVE 4000000 von 2500000 auf 4000000
RF1000.h: Z890 #define MOVE_CACHE_LOW 14 von 10 auf 14
RF1000.h: Z884 #define MOVE_CACHE_SIZE 20 von 16 auf 20


Auto- Startmadenhoehe
RF1000.h: Z 978 #define AUTOADJUST_STARTMADEN_AUSSCHLUSS von 0.35f auf 0.28f

Bis jetzt macht das System einen stabilen Eindruck!

Drucken über SD Karte scheint nun ohne stehen bleiben zu funktionieren und das bei 150 % der seitherigen Druckgeschwindigkeit.


Drucken über USB Kabel, da blieb der Drucker wieder etwa 300 Millisekunden stehen.

Ich glaube, die Möglichkeiten sind nun ausgeschöpft und wenn es über SD Karte problemlos funzt, ist das ok.

Dieses Jahr wird sich am Drucker, EDV mäßig, noch etwas tun und ich hoffe damit das USB Problem gelöst zu haben.

Configuration.h:
Z616 #define UI_PRINT_AUTORETURN_TO_MENU_AFTER 240000 von 120000 auf 240000

Wenn ich diesen Wert auf Null setze, dann gibt es immer noch einen Kompilier Fehler.
Vielleicht kann Nibbels mal danach schauen, es ist mehr ein Kosmetik Fehler.

LG AtlonXP

[Nibbels]

Hi

Kurz ein Kommentar zu deinen Einstellungen:
RF1000.h: Z895 #define LOW_TICKS_PER_MOVE 4000000 von 2500000 auf 4000000
RF1000.h: Z890 #define MOVE_CACHE_LOW 14 von 10 auf 14
sind vermutlich harmlos. Du hast bei den LOW_TICKS_PER_MOVE aber eine 0 zuviel??

Aber dazu mehr:
RF1000.h: Z884 #define MOVE_CACHE_SIZE 20 von 16 auf 20

Das mit dem freien Ram wird euch beim Compilieren im Arduino angezeigt. Das sagt aus, wieviel Ram übrig bleibt, falls während der Laufzeit zusätzliche Varialben usw. benötigt werden, die flüchtig sind.
Man muss also genügend Ram übrig lassen, der nicht von vornherein für irgendwas verplant ist, sodass zur Laufzeit immer genügend Ram bleibt.

Beim Compilieren erscheint diese oder eine ähnliche Meldung mit MOVE_CACHE_SIZE = 20 beim RF1000

Code: Alles auswählen

Der Sketch verwendet 230044 Bytes (90%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 7191 Bytes (87%) des dynamischen Speichers, 1001 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.

Wichtig ist hier, wieviel Ram übrig bleibt. "1001 Bytes für lokale Variablen verbleiben." Aber wieviel übrig bleiben muss, das weiß ich nicht. Und ich kann auch nicht genau sagen, was passiert, wenn nicht genügend Ram übrig bleibt. Irgendwas wird dann spinnen.

MOVE_CACHE_SIZE frisst pro Anzahl 122 Byte. (Zumindest in Version 1.38.33)

So kann der freie Ram beim RF1000 mit normalen MOVE_CACHE_SIZE = 16 aussehen:

Code: Alles auswählen

Der Sketch verwendet 230044 Bytes (90%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 6703 Bytes (81%) des dynamischen Speichers, 1489 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.

Und wenn ich den Milling-Mode mit normalen MOVE_CACHE_SIZE = 16 ausschalte/spare, dann das:

Code: Alles auswählen

Der Sketch verwendet 206790 Bytes (81%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 6620 Bytes (80%) des dynamischen Speichers, 1572 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.

Komplett auf Milling-Mode verzichten bringt also 83 Byte Ram.

Als RF2000, wegen 2 Extrudern etc. gibts mit Millingmode und MOVE_CACHE_SIZE = 16 diese Ausgabe:

Code: Alles auswählen

Der Sketch verwendet 241308 Bytes (95%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 6864 Bytes (83%) des dynamischen Speichers, 1328 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.

1489 - 1328 = 161 Byte Ram, den der RF2000 mehr benötigt.

PrintLine PrintLine::lines[MOVE_CACHE_SIZE]; // Cache for print moves.

-> Ein Printline Objekt pro Element des MOVE_CACHE_SIZE.

Wie kann man rausfinden, wieviel Ram übrig bleibt?
1) Es gibt einen Schalter der heißt DEBUG_FREE_MEMORY

Screenshot_4.png

2) Und es gibt einen GCode der heißt M3200 P1

Punkt 1 verursacht, dass überall im Programmcode diese DEBUG_MEMORY Funktion eingebunden wird:
#define DEBUG_MEMORY Commands::checkFreeMemory();
Die sind quer in den Funktionen zerstreut. Aber ich kann nicht sagen, ob es genügend davon gibt, um alle Verbrauchs-Spitzen abzudecken.
Der Drucker läuft also und sucht durch Commands::checkFreeMemory(); ständig nach dem niedrigsten gesehenen Wert des freien Rams zur Laufzeit.
Mit M3200 P1 kann man sich diesen niedrigsten Wert ausgeben lassen.
Wieviel Sicherheitspuffer man auf diesen Wert draufrechnen muss, weiß ich auch nicht

Darum habe ich daran nichts gemacht, zumal alle Repetier-Drucker mit Wert MOVE_CACHE_SIZE=16 zu laufen scheinen.
Ich meine, ein größerer MOVE_CACHE_SIZE-Wert ist schon erstrebenswert. Doch mir war das zu heiß. Wenn ich was umprogrammiere will ich Fehler/Fehlermeldungen sehen die Code-Fehler sind.

Nach meinem Gefühl brauchen wir minimum 600..700 Byte freiem Ram oder noch einiges mehr. Ich hab auch mal mit DEBUG_MEMORY / DEBUG_FREE_MEMORY gespielt und dann stand da "lowest free ram: 900" und vermutlich war die Anzahl der übrigen Bytes in Arduino irgendwo bei 1300 bis 1500.

Wenn jemand mehr darüber weiß oder eine Ahnung hat, wie wir den Wert optimieren können, gerne

LG

[AtlonXP]

Ja wohl, ich bestätige eine Null zu viel!
Na bei so vielen Nullen….

Ich bin froh das dass Ding jetzt so läuft.

[Nibbels]

Ok, ich hab meinen Drucker mit 926 Rest-Ram geflashed. Und mit DEBUG_FREE_MEMORY.
Ausserdem konnte ich noch 4 Byte pro Printline einsparen, weil ich eine unnötige Variable entfernt habe.
Dann schau ich mal, was der M3200 P1 so ausspuckt, wenn ich gedruckt habe. Nur drucken kann ich hetue nicht mehr.

Direkt nach dem Start: 19:06:27.663: Free RAM:812

EDIT: Eins ist klar: 916Bytes heißt, dass nach kurzer Zeit der wert des kleinsten Rams bei
lowest free RAM: 360 ist.
Und nach einem Z-Offset-Scan
lowest free RAM: 138
Zumindest hat der HBS der nun gerade läuft diesen Wert noch nicht unterboten.
(Ich habe dazu DEBUG_MEMORY in den Watchdog-Interrupt geschrieben, denn der drängelt sich willkürlich zwischen den sonstigen Code.)

--> in keinem alle Fälle sollten wir weniger als 800 Byte frei lassen! 900 könnte stabil sein, dafür müsste ich nun aber alles durchtesten, was der Drucker kann.

LG

[AtlonXP]

Hallo Nibbels,
danke für die Mühe.

Meine jetzt eingegebenen Werte habe ich großzügig Pi mal Fensterkreuz ermittelt!
Vielleicht lässt sich der Puffer wieder reduzieren.

Ich kann nur dazu sagen, dass die Aussetzer über SD Karte wesendlich kürzer waren, wie wenn ich über USB drucke.
Vielleicht reichen auch schon, nur deine vorgeschlagen Änderungen aus.

Ich habe deshalb so großzügig zugelangt, wegen den USB Aussetzer.
Das war leider Erfolglos!

Wenn es wirklich mit dem RAM kritisch sein sollte, da möchte ich auf mhiers Idee hinweisen.
Er meinte die SD Karte als Speicher mit einbinden.
Genauer, den Gcode über SD Karte Puffern.

Ich könnte mir da eine Auslagerungsdatei für manche Zwecke der FW vorstellen (wenn es Sinn hat), so wie es Windof macht.

Sollte meine Kiste anfangen zu spinnen, dann nehme ich wieder was vom Puffer zurück!

Soll ich hier eine Test STL zu Verfügung stellen?
Die ist aber auf eine Düse von nur 0,2 mm ausgelegt.

LG AtlonXP

[Nibbels]

Also mir ist gerade der Z-Offset-Scan mit "M3900 R1", was einem vielfachen Scan entspricht, einfach so stehen geblieben. ^^
Hab nun den Cache zurückgenommen.

Bin also mit 1152byte freiem Ram gestartet.
nach dem Scan waren 301 minimal freier ram drangestanden.

Also neuer Minimalwert der frei sein muss: 852 byte. Kann gut sein, dass du mit deinem 1kb freien Ram ganz gut liegen könntest. Teste du aber auch noch ne Zeit lang weiter.

LG

Edit: Minimal 870!

[AtlonXP]

Ich habe gerade nur den Kompilier bemüht:

Archiving built core (caching) in: C:\Users\Magnet\AppData\Local\Temp\arduino_cache_83850\core\core_arduino_avr_mega_cpu_atmega2560_0c812875ac70eb4a9b385d8fb077f54c.a
Der Sketch verwendet 226072 Bytes (89%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 7132 Bytes (87%) des dynamischen Speichers, 1060 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.
Wenig Arbeitsspeicher verfügbar, es können Stabilitätsprobleme auftreten.

Das hat er mir ausgespuckt.
Also wenn ich es richtig verstanden habe, sind es noch 1060 Bytes freier RAM.

LG AtlonXP