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
RF1000 (seit 2014) mit: Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
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.
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.
Testablauf
Ich nahm mein letztes Firmware-Update her und änderte bloß zwei Werte: 'Schritte/mm für X' und die Versionsbezeichnung (jene, die in der Anzeige des Druckers erscheint). Beim Wert für 'Schritte/mm' fügte ich einfach den Multiplikator '2' hinzu. Den Wert vom EEPROM_MODE änderte ich absichtlich NICHT. Der aktuelle Wert dafür war nicht 0 (Null), womit der EEPROM Modus aktiviert sein sollte.
Diese 'neue' Version wurde aufgespielt. Danach wurde Repetier-Host angeworfen und beim Verbinden mit dem Drucker auf die Anzeige geglotzt: Jawohl!, die 'neue' Version meldete sich wie erwartet. Daraufhin ging es in die manuelle Steuerung von Repetier-Host und die Bewegung in X wurde geprüft: Nix da, 50mm bleiben 50mm. Auch ein Blick in die EEPROM-Werte mittels Repetier-Host zeigte, dass sich der entsprechende Wert für Schritte/mm für X nicht geändert hatte.
Damit ging es in die nächste Runde.
Ich nahm die eben aufgespielte Firmware-Version und änderte wieder nur zwei Werte: Die Versionsbezeichnung und den Wert vom EEPROM_MODE. Den zuvor verdoppelten Wert für Schritte/mm in X ließ ich unverändert. Diese Version wurde ebenfalls aufgespielt. Danach, in Repetier-Host, waren die Bewegungen in X tatsächlich doppelt so lang wie gefordert. Die EEPROM-Werte, die Repetier-Host anzeigte, belegten die erfolgte Änderung ebenfalls.
Auf in die nächste Runde.
Die eben aufgespielte Version wurde wieder geändert, hier jedoch an drei Stellen: 1. Versionsbezeichnung, 2. EEPROM_MODE zu 0 (Null), 3. der Multiplikator für Schritte/mm in X wurde von 2 auf 0.5 reduziert. Und wieder aufgespielt. Die Anzeige bestätigte die erfolgte Versionsänderung und Repetier-Host zeigte in der manuellen Steuerung die erwartete Halbierung des Fahrwegs. Eine Überprüfung der EEPROM-Werte in Repetier-Host schlug mit der Fehlermeldung "Error:No EEPROM support compiled." fehl. Ebenso die zwei GCode-Befehle M205 und M206 (EEPROM-Werte ausgeben, bzw. EEPROM-Wert schreiben).
Die letzte Runde bestand aus dem Wiederherstellen des Ausgangszustands (vor der Testreihe und somit EEPROM_MODE <>0).
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.
Fall -a- Der EEPROM_MODE ist 0
Dann besteht kein EEPROM Support und die Werte, die beim letzten Hochladen der Firmware in der Firmware definiert waren, haben Gültigkeit (zumindest bis zum nächsten Flashen). Der Begriff EEPROM Support wird in einem Spoiler gegen Ende des Beitrags erklärt.
Ablauf: Beim Booten der Firmware (=beim Einschalten des Druckers oder nach jedem Reset) sieht die FW nach, ob an der ersten Stelle im EEPROM der Wert ‚0‘ steht. Ist dem so, wird der EEPROM Support deaktiviert bzw. bleibt deaktiviert. Steht im EEPROM noch nicht der Wert '0', wird dieser an der ersten Stelle hineingeschrieben (das geschieht nur beim allerersten Booten nach dem Flashen). Damit bleibt der EEPROM Support deaktiviert, zumindest bis die FW neu geflasht wird.
Fall -b- Der EEPROM_MODE ist ungleich 0 und zusätzlich ungleich dem -Magic Byte-
(Ich vermute, dass es eigentlich heißen sollte "das Byte ist >0", da ich nicht glaube, dass ein negativer Wert akzeptiert wird).
Damit ist zunächst einmal der EEPROM Support aktiviert, da das Byte nicht Null ist. Die Firmware verwendet damit im Betrieb immer die Werte, die im EEPROM gespeichert sind (egal ob diese Werte Sinn machen oder nicht). Die EEPROM Werte werden anstelle der Werte verwendet, die eventuell in den Firmware-Dateien angegeben wurden und in der Firmware hinterlegt sind. Der EEPROM Support erlaubt zusätzlich das Lesen und Speichern gewisser Werte im EEPROM (mittels GCode-Befehle, Host, oder auch übers Display/Menüsteuerung).
Ablauf: Beim Booten der FW (=beim Einschalten des Druckers oder nach jedem Reset) prüft die Firmware das Byte an der Stelle 0 im EEPROM. In diesem Fall findet die Firmware eine Ganzzahl ungleich Null und prüft weiter, ob das Byte gleich dem Byte in der kompilierten FW ist (dem EEPROM_MODE-Wert). Dabei ist es egal, ob der Wert hochgezählt wurde oder kleiner als vorhin war, hauptsächlich <>0 und anders als vorher. Da in diesem Fall die Firmware ein Byte findet, dass sich vom Magic-Byte unterscheidet, geht sie wie folgt vor:
Das neue Byte wird anstelle des Magic-Bytes ins EEPROM geschrieben, ebenso weitere Werte aus der kompilierten Firmware (aber scheinbar nicht alle).
Da beim erstmaligen Booten der neuen Firmware (mit dem eben geänderten Magic-Byte) der neue Wert des Magic-Bytes ins EEPROM geschrieben wird, sieht die Firmware immer nur einmal den abweichenden Wert im Magic-Byte. Zumindest bis die Firmware wieder (samt Magic-Byte) geändert und wieder aufgespielt wird. Das erstmalige Booten geschieht sogar unmittelbar nach dem Flashen (zumindest wenn über Arduino geflasht wird), da die Firmware nach dem Flashen automatisch resettet wird.
In anderen Worten, beim erstmaligen Booten nach einer Änderung des EEPROM_MODE-Werts werden viele Stellen des EEPROMs neu initialisiert (beschrieben). Ist hingegen das Magic-Byte gleich dem Wert in der kompilierten FW, bleibt das EEPROM unangetastet. Nach einer FW-Änderung ist das spätestens beim nächsten Booten der Fall.
Fall -c- EEPROM_MODE ist ungleich 0 und unverändert gegenüber der vorher verwendeten Firmwareversion
Der EEPROM Support bleibt weiterhin aktiviert da das Byte ungleich Null ist. Die Werte im EEPROM werden nicht automatisch überschrieben und werden im laufenden Betrieb verwendet (wie unter Fall ‚b)‘ ). Änderungen gewisser EEPROM Werte sind mittels GCode, Host, oder über das Display realisierbar. Ablauf: Im Prinzip wie unter ‚b)‘, nur bleiben die EEPROM-Werte unangetastet.
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 ).
Hier das Ergebnis
Das EEPROM war weiterhin lesbar und beschreibbar, aber die PID-Werte wurden auf die Werte für das V2 Hot End zurückgesetzt – Nachahmung ist also nicht mehr nötig!
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).
Noch offene Fragen
Einige Fragen bleiben jedoch noch offen, leider.
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).
Offensichtlich wird das EEPROM trotz nicht aktiviertem EEPROM Supports weiterhin beschrieben, z.B. um eine HBS Matrix zu speichern (sonst könnte es mit EEPROM_MODE = 0 die Funktionalität der Z-Kompensation nicht geben!).
Werden die PID-Werte mit M303, mit Parameter X0, ebenfalls ins EEPROM geschrieben (wenn EEPROM_MODE=0)?
Funktioniert der GCode-Befehl M3091 bei EEPROM_MODE = 0? Das traue ich mir nicht zu testen. Dann wären alle Matrizen weg, und wer weiß was sonst noch.
Ist das 256kB EEPROM zusätzlich zum 4kB EEPROM eingebaut, oder ersetzt das eine das andere?
Tauchen die zusätzlichen EEPROM-Werte der Community Version in der von M205 erzeugten Liste auf, bzw. sind diese mittels M206 erreichbar?
was bedeutet nun -- EEPROM Support --
EEPROM Support:
Der EEPROM Support wurde scheinbar recht früh in der Firmwareentwicklung integriert (es wird damals auch von der erhältlichen Hardware abhängig gewesen sein). Damit wurde dem User die Möglichkeit gegeben, gewisse wichtige Werte ändern zu können, ohne jedes Mal die Firmware neu flashen zu müssen, was auch das Editieren und Kompilieren der Firmware-Dateien mit sich zog.
Einige der Werte lassen sich (temporär) recht komfortable mittels GCode ändern, wobei diese Änderungen beim neuerlichen Booten verloren gehen. (Diese Funktionalität war sicherlich, bis zum Erscheinen des EEPROM Supports, dringend nötig!) Zusätzlich lässt sich, mit EEPROM Support, ein EEPROM Wert mittels GCode Befehl ändern, auch wenn es keinen eigenen komfortablen GCode Befehl gibt (siehe M206. Solche Änderungen überstehen ein neuerliches Booten der Firmware, denn es wird das EEPROM direkt beschrieben.
Da es seit jeher derartig viele Varianten der Drucker gibt, beinhaltet die Liste der im EEPROM hinterlegten Werte auf den ersten Blick scheinbar unsinnige Einträge (z.B. die Schritte/mm für X, Y und Z, die Maximalwerte der Achsen, die Anzahl der Extruder, usw.). Ich käme, mit meinem ‚RF1000 single‘, nie auf den Gedanken, einen der eben genannten Werte zu ändern. Wozu denn, das ist doch alles fix, oder?
ABER, hat ein User einen Drucker mit Dual oder auf Dual umgebaut, könnte es schon Sinn machen, mal schnell einige dieser Werte zu ändern, wenn der User einen Druckauftrag im Single-Modus ausführen möchte (denn da kann man den Maximalwert der X-Achse ausweiten um Bauraum zu gewinnen). Oder hat ein User ein schlaues Schnellwechselsystem für den Extruder, sind vielleicht die Schritte/mm des Extruders, samt PID-Werte der Heizung beim Tausch anzupassen.
Die Entwickler der frühen Firmwarevarianten haben sehr vorausschauend gehandelt und haben viele Möglichkeiten untergebracht. Der EEPROM Support steigert die Flexibilität der Firmware erheblich.
Side Bar
#define FEATURE_FULL_EEPROM_RESET 1 ; stellt sicher, dass bei einem geänderten EEPROM_MODE Wert das EEPROM gänzlich neu beschrieben wird
OK, wenn ja, wo holt sich dann die FW z.B. die abweichenden PID-Werte her (beim E3d v6, z.B.)?
#define FEATURE_CONFIGURABLE_HOTEND_TYPE 0 ; wenn nicht ‘0’, dann nimmt die Firmware an, es handelt sich um ein original Hot End (V1, V2 oder V3) und überschreibt möglicherweise die PID-Werte. Falls ein anderes Hot End verwendet wird, unbedingt auf ‚0‘ setzen.
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
RF1000 (seit 2014) mit: Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
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.
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).
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
RF1000 (seit 2014) mit: Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
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
RF1000 (seit 2014) mit: Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
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
RF1000 (seit 2014) mit: Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
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.
).
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.
