Hallo RFx000 Gemeinde,

In einem kürzlich veröffentlichen Beitrag mhiers wurde bezüglich EEPROM_MODE folgendes geschrieben:

mhier hat geschrieben:Außerdem muss die Zahl immer dann geändert werden, wenn ein Firmware-Entwickler das "Dateiformat" im EEPROM verändert,
damit beim Update der EEPROM-Inhalt auf die Standard-Werte zurückgesetzt wird anstatt die vorhandenen Werte im neuen Format
umzuinterpretieren (und ggf. kompletten Unfug zu veranstalten).

Da ich beim Programmieren etwas unbedarft bin, hat mich das etwas verwirrt. Ich hatte eine (völlig?) andere Interpretation des
EEPROM_MODE-Werts.

Hier dazu die entsprechende Erklärungen/Beschreibungen aus der Firmware selbst (Conrad Version RF.01.47 (dev)):

I) (aus der Configuration.h):
For easy configuration, the default settings enable parameter storage in EEPROM.
This means, after the first upload many variables can only be changed using the special
M commands as described in the documentation. Changing these values in the configuration.h
file has no effect. Parameters overriden by EEPROM settings are calibartion values, extruder
values except thermistor tables and some other parameter likely to change during usage
like advance steps or ops mode.

To override EEPROM settings with config settings, set EEPROM_MODE 0 */

II) (ebenso aus der Configuration.h):
/** \brief EEPROM storage mode
Set the EEPROM_MODE to 0 if you always want to use the settings in this configuration file. If not,
set it to a value not stored in the first EEPROM-byte used. If you later want to overwrite your current
EEPROM settings with configuration defaults, just select an other value. On the first call to epr_init()
it will detect a mismatch of the first byte and copy default values into EEPROM. If the first byte
matches, the stored values are used to overwrite the settings.

IMPORTANT: With mode <>0 some changes in Configuration.h are not set any more, as they are
taken from the EEPROM. */

Hier nun meine Interpretation:

Meiner Meinung nach muss ich jedes Mal, wenn ich gewisse Werte ändern möchte, die im EEPROM gespeichert sind, den Wert des EEPROM_MODEs aufs neue ändern, wobei der Wert nicht auf 0 (Null) gesetzt werden soll. Der Beschreibung nach (meiner Interpretation nach) wird beim Flashen anfangs der EEPROM_MODE-Wert (aus der Configuration.h) mit dem ersten Byte im EEPROM verglichen. Unterscheiden sich diese, werden meine geänderten Werte aus der Configuration.h (z.B. Steps/mm oder PID-Werte) in das EEPROM geschrieben. Wird jedoch beim Flashen erkannt, dass der EEPROM_Mode-Wert in der Configuration.h gleich dem im EEPROM ist, werden eventuell geänderte Werte in der Configuration.h ignoriert. Der neue, geänderte EEPROM_MODE-Wert wird zum Schluss im EEPROM, im ersten Byte, gespeichert.

Steht in der Configuration.h beim EEPROM_MODE eine 0 (Null), werden alle (oder gewisse?) EEPROM-Werte auf "Fabriks-/Defaultwerte" zurückgesetzt.

Ist meine Interpretation falsch? Habe ich die dutzende Male, wo ich die FW neu geflasht habe, falsch gehandelt (obwohl das Ergebnis glücklicherweise das erwartete war)?

Oder hätte es gereicht, einmalig den EEPROM_MODE-Wert zu ändern?

(In der EEPROM.h findet sich eine Definition für EPR_MAGIC_BYTE mit dem Wert 0, womit vermutlich die Position gemeint ist.)

mjh11

Hm, wie so oft ist es die eine Frage, welchen Effekt ein Feature hat, und aber eine andere, welche Intention ursprünglich dahinter steckt.

Der Effekt ist m.M.n. klar beschrieben im Abschnitt "\brief EEPROM storage mode". EEPROM_MODE = 0 bedeutet, das EEPROM wird nicht genutzt. Es gibt keine Konfigurations-Parameter, die sich die Firmware merken kann. Beim Booten der Firmware werden also immer die Werte aus der Configuration.h etc. verwendet. Ist EEPROM_MODE != 0, dann wird beim Booten der Firmware aus EEPROM der Wert an Position EPR_MAGIC_BYTE aus dem EEPROM gelesen und mit EEPROM_MODE verglichen. Ist er identisch, werden die Werte aus dem EEPROM verwendet und nicht die aus den .h-Dateien. Ist er nicht identisch, wird effektiv ein Factory-Reset durchgeführt, d.h. das EEPROM wird mit den Werten aus den .h-Dateien überschrieben (einschließlich dem Wert an Position EPR_MAGIC_BYTE).

Die Idee dahinter ist, dem Layout des EEPROM quasi eine Versions-Nummer zu geben. In dem Moment, wo das Layout sich ändert, würde möglicherweise kompletter Unsinn aus dem EEPROM gelesen, weil sagen wir der Thermistor-Typ für den Extruder früher an der Position stand, wo jetzt die Steps/mm für den Extruder-Motor stehen. Dann nimmt die Firmware plötzlich nur noch 8 Steps/mm an, weil der Thermistor-Typ auf 8 konfiguriert war, usw. Deshalb soll der EEPROM_MODE immer dann hochgezählt werden, wenn sich das Layout verändert. Dadurch ist sichergestellt, dass egal in welcher Reihenfolge man sich Firmwares auf den Drucker spielt immer entweder die EEPROM-Werte korrekt interpretiert werden können, oder andernfalls eben ein Factory-Reset durchgeführt wird und zumindest kein Unsinn passiert (wenngleich dann auch alle Einstellungen weg sind).

Natürlich kann man das Feature auch missbrauchen, um bei veränderten Einstellungen in den .h-Dateien einen Factory-Reset nach dem Flashen der Firmware automatisch durchführen zu lassen. Das bringt aber Probleme mit sich: Wenn du anschließend eine andere Version der Firmware installierst, die wieder den originalen EEPROM_MODE drin hat, gibt es wieder ein Factory-Reset, auch wenn das Layout eigentlich kompatibel wäre. Damit sind deine Einstellungen wieder futsch. Oder aber du installierst eine andere Firmware, die zufällig den gleichen EEPROM_MODE hat, wie den, den du eingestellt hast um den Factory-Reset zu erzwingen. Diese andere Firmware hat aber ein inkompatibles EEPROM-Layout mit deiner Firmware, denn deshalb wurde der EEPROM_MODE dort ja geändert. In dem Fall bekommst du keinen Factory-Reset, obwohl einer nötig wäre, und dein Drucker wird möglicherweise total rumspinnen.

Die korrekte Lösung statt des Missbrauchen des EEPROM_MODE ist einfach per Menü ein Factory-Reset durchzuführen. Auch dann werden die Einstellungen aus den .h-Dateien in das EEPROM übernommen. Das ist lediglich ein kleiner Schritt mehr nach dem Update der Firmware.

Grundsätzlich halte ich es aber eigentlich für unnötig, Firmware-Updates nur deswegen durchzuführen, weil man in den .h-Dateien geänderte Einstellungen ins EEPROM schreiben will. AtlonXP hat ja in dem anderen Thread (viewtopic.php?f=7&t=3298#p35924) erläutert, wie man Werte ins EEPROM schreibt, ohne Firmware zu flashen, selbst wenn das Menü einem diese Einstellungen nicht anbietet. Wenn man RepetierHost nicht benutzt, geht das auch einfach per G-Code M206 (wiki/index.php/GCodes#M206_-_Schreibe_Wert_ins_EEPROM), RepetierHost macht auch nichts anderes.

Das wird wieder lang. Sorry.

Mir war nach mehrmaligem Lesen nicht alles aus mhiers Antwort völlig klar. Das lag vermutlich an mir. Ich konnte mir nicht anders helfen und musste nach der zen-haften Selbsterfahrung trachten.

Ich führte mehrere Versuche aus. Damit der Beitrag nicht unerträglich lang wird, ist der Testablauf im Spoiler untergebracht. Damit fasse ich zusammen (zumindest für mich):

Beim Flashen der Firmware kann ein gültiger EEPROM_MODE–Wert drei mögliche Zustände aufweisen:

a) 0
b) Eine positive Ganzzahl, die sich von der zuletzt gespeicherten Zahl unterscheidet
c) Eine positive Ganzzahl, die gleich der zuletzt gespeicherten Ganzzahl ist

Beim Booten der Firmware (=beim Einschalten des Druckers oder nach jedem Reset) sieht die FW nach, welcher Wert an der ersten Stelle im EEPROM steht. Das Byte an der ersten Stelle im EEPROM ist daher gelegentlich als das 'Magic-Byte' bekannt. Die Firmware wird einen der drei eben genannten Fälle begegnen.
Den Wert des EEPROM_MODEs kann man beim Flashen der Firmware übergeben. Den Wert kann man in der Datei „Configuration.h“ vorgeben.
Nicht unbedingt offensichtlich ist, dass Fall ‚b)‘ nur für den allerersten Bootvorgang nach einer Änderung der Firmware zum Tragen kommt, danach wird daraus automatisch Fall ‚c)‘. Somit sind der Fall ‚c)‘, und, falls es der User explizit wünscht, Fall ‚a)‘ die Regel.

---

Die Community FW speichert im Vergleich zur Conrad FW einige zusätzliche Werte im EEPROM (hier ist mein Wissensstand begrenzt und basiert auf Vermutungen, die auf die einstellbaren Features aufbauen):

• die Mikroschritte der Achsen
• die Motorströme
• Autostart On (von SenseOffset)
• Digit CMP On

Inwieweit ein regelmäßiges Ändern dieser Werte Sinn macht, kann ich mangels Erfahrung nicht beurteilen.

Einige der im EEPROM gespeicherten Werte können mittels M206 geändert werden, manche nicht. Dazu gehört das Magic-Byte, dass sich nicht mittels M206 ändern lässt (ja, das habe ich in fast suizider Absicht selbst getestet ). Im Falle der RFx000 Drucker werden sogar die HBS Matrizen im EEPROM gespeichert. Diese kann man löschen (M3011) oder indirekt neu beschreiben indem ein neuer HBS durchgeführt wird (M3010). Die EEPROM Speicherstellen dafür lassen sich aber mittels M206 nicht direkt beschreiben. Diese Werte werden auch nicht mittels M205 ausgegeben, dafür benötigt man M3013.
Welche Werte sonst im EEPROM gespeichert werden müsste jemand vom Fach aus den Quelldateien erarbeiten (Nibbels, zum Beispiel).

Obwohl die Systemplatine der RFx000 Drucker auf den Arduino Mega 2560 basiert, setzt die Systemplatine einen eigenen EEPROM ein (das EEPROM eines Original-Mega 2560 Boards hat 4kB, die RFx000 Systemplatine hat aber ein EEPROM mit 256kB!! Die HBS Matrizen fordern halt ihren Tribut!)

In der Arduino Dokumentation wird eine Lebensdauer von 100.000 Schreibzyklen für das EEPROM spezifiziert. Somit sollte man nicht unbedingt Variable dort speichern, die sehr oft geändert werden (müssen).
Ganz zum Schluss möchte ich nur festhalten, dass ich praktisch alle angepassten Werte (Schritte/mm, Thermistor-Typ, usw.), also alle Werte, die ich geändert haben möchte, auch in die entsprechenden Firmware-Dateien einarbeite, warte und mitziehe. Dadurch habe ich (beinahe) kein Problem mit dem Neu-Flashen, dem Downgrade-Flashen, oder die Durchführung sonstiger Firmware Experimente, da beim Flashen alle Werte immer die sind, die sie sein sollten (ich habe das Wort 'beinahe' eingefügt, denn die PID-Werte machen gelegentlich nicht mit - die notiere ich separat und stelle sie getrennt wieder her, falls nötig).

mjh11

Gute Zusammenfassung, danke! Ich kann vielleicht einige der noch offenen Fragen beantworten:

• Wo holt sich die Firmware die PID-Werte für das Hot End, wenn EEPROM_MODE = 0 ist, und was sind die Werte? In den Konfigurationsdateien sind nur PID-Werte für die V1, V2 und V3 Hot Ends definiert. Hat man ein anderes Hot End und verwendet EEPROM_MODE=0, muss man scheinbar im Start-GCode dann immer ‚seine‘ PID-Werte mittels M204 setzen, um die richtigen Werte beim Drucken zu haben (nach jedem Booten sind die wieder weg). Bei den PID-Werten für das Bett wird es ähnlich sein (falls man eine abweichende Heizung oder Thermistor einsetzt).

Ich denke, genau so wird es sein. EEPROM_MODE = 0 hat nicht unbedingt eine vernünftige Unterstützung, weil es einfach (inzwischen) normal ist, ein EEPROM zu haben und zu nutzen (zur Anfangszeit, als Repetier entwickelt wurde, hatte das vielleicht noch nicht jeder Drucker). Wie du ja festgestellt hast, hält sich die RFx000-Firmware gar nicht unbedingt daran, denn sie greift weiterhin auf das EEPROM für die HBS-Matrizen zu. EEPROM_MODE = 0 ist für Druckermodelle gedacht, die kein EEPROM haben, da Conrad aber ein EEPROM in den Drucker eingebaut hat (sogar extra ein größeres, siehe unten), sind sie wohl nicht davon ausgegangen, dass jemand die Firmware mit EEPROM_MODE = 0 betreiben würde. Ich empfehle, das nicht zu benutzen.

• Ist das 256kB EEPROM zusätzlich zum 4kB EEPROM eingebaut, oder ersetzt das eine das andere?

Das 4kB EEPROM ist im ATMega 2560 Chip integriert, jedes Board mit dem ATMega 2560 hat also dieses EEPROM. Das 256kB EEPROM ist ein externer Chip, den Conrad zusätzlich auf das Mainboard designed hat, weil 4kB nicht ausreichend sind. Ich denke aber, die Repetier-Firmware kann ursprünglich nur mit einem EEPROM umgehen, und zwar mit dem Internen 4kB, d.h. alle Repetier-eigenen Werte werden ausschließlich im 4kB EEPROM abgelegt. Das Externe EEPROM (256kB) wird ausschließlich für die HBS-Matrizen verwendet.

Hier der Source-Code zum Lesen der HBS-Matrix:
https://github.com/RF1000community/Repe ... .cpp#L5326

Dort wird die Funktion readByte24C256 benutzt, um über den I2C-Bus auf das externe EEPROM zuzugreifen.

In Eeprom.cpp wird jedoch die Funktion HAL::eprGetByte() etc verwendet:
https://github.com/RF1000community/Repe ... HAL.h#L515

Diese greift über die Arduino-Funktionen auf das interne EEPROM zu.

Frag mich bitte nicht, warum Conrad das so gelöst hat. Es wäre leicht gewesen, die HAL-Funktionen auf das externe EEPROM "umzubiegen" (HAL = Hardware Abstraction Layer, also genau dafür da) und die HBS-Matrizen dort wie alle anderen Werte ganz normal einzubinden. Das sind diese vielen Kleinigkeiten in der Firmware, die einfach nicht sauber gelöst sind. Deswegen nutze ich sie ja nicht mehr Wem der aktuelle Entwicklungsstand ausreicht, der muss sich mit solchen Details ja nicht auseinandersetzen. Einfach den EEPROM_MODE so lassen, wie er ist, und möglichst alle Werte immer über G-Codes anpassen und nicht im Source-Code.

Wer mehr will und neues Funktionalität entwickeln möchte, dem empfehle ich den Wechsel zu Klipper. Da braucht man gar kein EEPROM sondern hat stattdessen eine strukturierte Textdatei zur Konfiguration (mit entsprechender Möglichkeit, Werte dynamisch zu überschreiben und in der Datei abzuspeichern).

Hallo mhier/Martin,

Eine Frage von vorhin bleibt weiter unbeantwortet, die wird aber jemand beantworten müssen, der nicht Klipper im Einsatz hat, sondern die Community Version:

• Tauchen die zusätzlichen EEPROM-Werte der Community Version in der von M205 erzeugten Liste auf, bzw. sind diese mittels M206 erreichbar?

Dazu fällt mir eine zusätzliche, verwandte Frage ein: Falls man ein Dual-System hat, tauchen dann die zusätzlichen EEPROM-Werte auch in der (von, z.B., Repetier-Host erstellten oder durch M205 angeforderten) EEPROM-Liste auf? Dazu gehören unter anderem die PID-Werte oder der Sensor Type des zweiten Extruders.

Besonders interessant ist, wo Nibbels die zusätzlichen nötigen Werte der Community Version untergebracht hat, im 4k EEPROM oder im größeren?

mjh11

Kannst du mir nen Beispiel für einen neuen EEPROM-Wert nennen? Dann kann ich das vielleicht im Source-Code finden.

Hallo mhier,

Im Beitrag #3 liste ich vermutete Werte auf, die meines Wissens über EEPROM gespeichert werden müssten:

die Mikroschritte der Achsen
die Motorströme
Autostart On (von SenseOffset)
Digit CMP On

Das sind Werte, die über das Display eingestellt/verändert werden können, die aber scheinbar einen Ein-/Aus-Zyklus überdauern (müssten). Es gibt vielleicht noch mehr solcher Werte.
Welche Namen Nibbels oder sonstige Programmierer im Quellcode verwendet haben, entzieht sich meiner Kenntnis. Die Suche in den Quelldateien gelingt vielleicht, wenn man von den definierten Bezeichnungen ausgeht, die im Display verwendet werden. Das sind die Bezeichnungen ja bekannt.
Dass diese Werte Bestand haben müssten und daher im EEPROM gespeichert werden, entnehme ich den fehlenden Ansagen im Forum, dass man diese oder jene Funktionen 'unbedingt per Start-GCode' oder übers Display aktivieren muss. Auch weil einige Werte gar nicht über GCodes konfigurierbar sind (z.B. Mikroschritte und Motorströme). Weiters steht im Wiki, unter Motorströme, dass zumindest der eine Wert im EEPROM gespeichert wird.

Die Frage, ob sich diese Werte mittels Repetier-Host einsehen lassen, bzw. sich mit M205 ausgeben, oder per M206 ändern lassen, könnte jemand mit der Community FW in weniger als einer Minute beantworten.
Die Frage, ob die Werte für das zweite Hotend in Repetier-Host einsehen, bzw. auf M205 & M206 reagieren, könnte auch jemand ohne Community FW beantworten, vorausgesetzt, die haben ein Dual-System konfiguriert.

Wo die Werte gespeichert sind, könnte deshalb interessant sein, weil vermutlich der Zugriff über Repetier-Host, M205 und M206 nur für das 4kB EEPROM funktioniert. Ich kann auch nicht sagen, geschweige denn abschätzen, wieviel % des 4kB-EEPROMs belegt sind (im Dual-System), bzw. wieviel Platz noch übrig wäre.

mjh11

Hallo,

Dank an zero k, der die Ausgabe des Befehls M205 an mich gesendet hat. Darin kann man finden:

Die PID-Werte und den Thermistortyp des zweiten Extruders (gilt nur für Dual-Systeme)

Und die Community Firmware speichert eine Menge zusätzlicher Werte:

Die Motorströme der 3 Achsen sowie von beiden Extrudern
Diverse Werte für SenseOffset und Digit Compensation
Werte für (das Anlaufen?) des Bauteillüfters
Digit-Werte für Z-NotHalt
Schrittweite der Z-Hoch und Z-Nieder Tasten am Drucker

Sowie einige andere. Der Vergleich ist recht mühselig, da die Positionen zum Teil verschoben wurden (auch die Beschreibungen haben sich teilweise geändert). In der Conrad-FW, ist zum Beispiel der Thermistor-Typ vom Extruder 1 bei der Position 256 gespeichert, in der Community bei Pos. 294. Solche Verschiebungen kommen mehrfach vor.

Jedenfalls scheinen viele, wenn nicht die meisten Community-spezifischen Werte im 4kB EEPROM gespeichert.

Mikroschritte der Motoren fand ich jedoch nicht, die sind vielleicht tatsächlich im größeren EEPROM gespeichert.
Auch "AutoStart ON" für SenseOffset war nicht zu finden, für den Wert gilt dasselbe wie vorhin.

Ich vermute, dass auch der Befehl M206 für alle mittels M205 gelisteten EEPROM-Werte klappen wird.

mjh11

Hallo,
der Befehl M205 und die Ausgabe über Repetier Host ist dasselbe.
Von der Ausgabe sollte auch alles gleich sein.
Ebenso ist über Repetier Host alles Änderbar wo angezeigt wird wie auch über M206.

In unserer Community FW hat Nibbels einiges zusätzlich in dieser Tabelle eingepflegt.
Auf jeden Fall sind einige Parameter dazu gekommen.

Hier ist mein letzter Auszug, gemacht über Repetier Host.
viewtopic.php?p=34036#p34036

LG AtlonXP