EEPROM Memory saved during firmware update?

[cassetti]

Question,

When uploading modified firmware (polygonhell's firmware), are the EEPROM settings saved, or will they be reset to defaults when firmware update is complete?

[cambo3d]

eeprom stays, ive tried this already. all eeprom settings stayed in eeprom for me anyway

[geneb]

cambo3d is correct. EEPROM values are not touched during the firmware upload process. It would be nice if the firmware had a way to "use default values" so if the wheels really come off the wagon, you've got a sane place to start again.

g.

[Polygonhell]

cambo3d is correct. EEPROM values are not touched during the firmware upload process. It would be nice if the firmware had a way to "use default values" so if the wheels really come off the wagon, you've got a sane place to start again.

g.

It does, the line where it enables EEPROM in configuration.h, just increase the number.
The EEPROM values are effectively versioned and that number changing forces the exiting values to be discarded.

[cassetti]

I thought so, thanks guys!

[geneb]

Polygonhell: Slick!

g.

[halley]

I don't know about the Polygonhell Repetier branch, or the Marlins that are used on the Rostock Max, but these firmwares should support command M500~M503 for EEPROM management. The Printrbot Marlin flavors do, and it's quite convenient to change most of these things without having to recompile/reflash all the time.

* M500: stores current parameters in EEPROM
* M501: reads parameters from EEPROM and displays them
* M502: reverts to the default "factory settings"
* M503: displays current parameters

Many of the delta-specific parameters should also be implemented to be a part of this parameter set: adjust delta radius, adjust max column height, etc.

I think the relatively easy reflash procedure of the Rostock board is both a strength and a weakness: it should be easy to do development work to improve the functionality, but it's also creating a complacency and dependency on reflashing. Everyone on the Rostock is expected to get the Arduino SDK and the source code, or at least the AVR tools to flash their boards. Very few people using a Printrboard want to reflash (or are capable of reflashing) so the firmware has been matured to a point that it's not necessary most of the time.

[geneb]

Is the parameter needed to tune the "delta radius" of the geometry available as an EEPROM setting? If it's there, there should be no reason to reload the firmware ever (unless for a bug fix). The boards coming from SeeMeCNC come pre-loaded with Repetier now.

g.

[Polygonhell]

Is the parameter needed to tune the "delta radius" of the geometry available as an EEPROM setting? If it's there, there should be no reason to reload the firmware ever (unless for a bug fix). The boards coming from SeeMeCNC come pre-loaded with Repetier now.

g.

No it's a #defined constant at the moment, that might change in the 0.9 release when he fixes the issue with steps/mm having to match in both the EEPROM and the Firmware.

[geneb]

That would be excellent. That way nobody has to fiddle with learning how to use the Arduino IDE.

g.