How to clear EEPROM 1 or EEPROM2 to defaults from configuration.h ?

Comments

• Repetier

  November 2016

  1. That is intentional, as it makes no sense to store in eeprom if you overwrite it every update. Change EEPROM_MODE to overwrite on next upload or do it by software

  M502

  M500

  
  

  2. On github you have a configuration.h with lots of comments if that is what you prefer. Maybe I'm too much into the stuff that I find the config tool easier to read/understand. On our homepage are also some informations on how things work which helps understanding the options.
• N37

  November 2016 edited November 2016

  Thanx, I like to know what code I use, as you can see i'm a kind of person that wants to help and put some effort and work in finding bugs/testing/getting solution for the problem and sharing.

  
  

  Many people just asks a question and waits for gold solution.

  
  

  Every project has got it's own logic, and since i'm not a pro c++ programmer sometimes my conclusions are not so brilliant as i would like to i know that, so please forgive me.

  
  

  My question about EEPROM reset/clear from the LCD menu has got a reason.

  My goal is to build a printer that is independent from connecting to the PC.

  
  

  So having a mechanism that could reverse the "user mess" to manufacturer "Fail Safe Config" would be a really handy.

  It could be locked by PIN or something with Splash info that User will loose all manually set parameters by confirming... etc.

  
  

  I will try to program that function by my self in future if there are no plans for such a functionality and I will push it to github if you want.

  
  

  I see that Your company is also going in to that direction (online slicing and so on) 

  
  

  We will keep in touch as soon as i will finish with testing, because till the end of this year I want to start production of new printer lines, and this what i do now is testing the firmware on simple prototype and than pushing it to the "big brother" if everything will work as i expect.

  
  

  Ones again thank You

  
  

  And i'm thinking about visiting Repetier next time when i'll be on my way to my home in Saarbrucken for Christmas

  
  

  
  
• Repetier

  November 2016

  I'm working on menu structure soon. So I think i will add a factory default button. Since it is just calling 2 existing functions it is simple to implement and would make sense.

  
  

  No plan to make a EEPROM lock from our side, but if it is a feature which can be enabled/disabled we would merge it if someone submits it:-) 
• Roko

  November 2016

  @N37 - for what it.s worth, along with changing the EEPROM MODE in configuration_h, (it's line 427 for my configuration_h) before I flash the EEPROM i run the sketch under File-Examples-EEPROM called eeprom_clear. Then I do the upload
• N37

  November 2016

  Thanx Roko, that's a good idea.

  
  

  
  

  Roko said:

  @N37 - for what it.s worth, along with changing the EEPROM MODE in configuration_h, (it's line 427 for my configuration_h) before I flash the EEPROM i run the sketch under File-Examples-EEPROM called eeprom_clear. Then I do the upload

  
  

  Repetier said:

  I'm working on menu structure soon. So I think i will add a factory default button. Since it is just calling 2 existing functions it is simple to implement and would make sense.

  
  

  No plan to make a EEPROM lock from our side, but if it is a feature which can be enabled/disabled we would merge it if someone submits it:-) 

  
  

  When i finish with mechanical design and start thinking about additional functions in firmware i will try to add that functionality and after testing i will share the code so if You like you can merge that to the main branch.

  
  

  Also i'm working on autoleveling function that will eliminate the need of manual precalibration.

  In theory it uses the sensor in extruder (tensionmeter) and moves the servos attached to the bed. That's nothing "briliant" but there is no firmware with that feature so i will share the code too. right now it works but there are some mechanical questions in design i want to implement so needs time for testing.

  
  

  Last is adding the option for using free stepper driver on RAMPS (if you have only 1 extruder you can have free stepper driver socket) to merge the 3D scanning controll in to the printer firmware. Scanner plate can be build in to the body of printer without additional arduino module, that feature is also in testing stage. I'm planning to add the SCAN option in menu to switch the firmware to snaner mode,home the build plate in specyfic place (in my case 3/4 UP) activate servos to take the plate from the side of printing chamber and start scanner firmware.

  
  

  I will share the code when it will be usable.

  
  

  Cheers mates.

  
  

  THX for info on adding the "Factory Reset" option in menu in future, that's good news and quite useful.
• Repetier

  November 2016

  Please note that hardware bed leveling is already supported. But it assumes you have 3 z motors controlled individually or alternative 2 motors controlling probe point 2 and 3 (like with felix pro 1). I think your solution is similar just with servos instead of stepper drivers.
• N37

  November 2016

  hmmm, i didn't know that. 

  So if I design the bed drive for Z axis that has 3 leedscrew pillars with 3 independent steppers for each pillar, and and CoreXY two steppers for X and Y axis . Than the printer will be totaly automatic in terms of autoleveling.

  
  

  So as RAMPS 1.4 has got only 5 steppers than I do not have any stepper drivers for extruder/extruders.

  
  

  So I need external stepper for extruders, or the mainboard that has got minimum 6 stepper drivers if we consider full automation of autolevelling and one extruder. 

  
  

  That complicates the desing, so i thought about using servo sockets (we have 3 on RAMPS) and 5 stepper sockets gives us 3 axis plus dualextrusian in max config.

  
  

  I wonder if the functionality already iplemented could be redirected with little changes to use servos insted of triple steppers per Z axis....

  
  

  I must check the code.

  
  

  I just love to work with you.

  
  
• N37

  November 2016 edited November 2016

  hmmm, i didn't know that. 

  So if I design the bed drive for Z axis that has 3 leedscrew pillars with 3 independent steppers for each pillar, and and CoreXY two steppers for X and Y axis . Than the printer will be totaly automatic in terms of autoleveling.

  
  

  So as RAMPS 1.4 has got only 5 steppers than I do not have any stepper drivers for extruder/extruders.

  
  

  So I need external stepper for extruders, or the mainboard that has got minimum 6 stepper drivers if we consider full automation of autolevelling and one extruder. 

  
  

  That complicates the desing, so i thought about using servo sockets (we have 3 on RAMPS) and 5 stepper sockets gives us 3 axis conroll and  dual extrusian in maximum configuration without designing new mainboard, just with RAMPS 1.4

  But the feature with 3 steppers for Z is  briliannt and solid. and it is more stright forward in implementation in hardware design. Just needs not a mainsteram shield.

  
  

  I wonder if the functionality already iplemented could be redirected with little changes to use servos insted of triple steppers per Z axis....that culd give the possibility of addin/selling auto leveling as "hardware module upgrade(changing the standard plate wit servo driven)" in zlready sold designs.and to implement that function in new designs that are using RAMPS shield/clones that are cheap and easy acessable on the market rather than dedicated mainboard desing.

  
  

  I must check the code if it could be possible.

  
  

  I just love to work with you.

  
  
• Repetier

  November 2016

  Check sparkcube autoleveling for an example. They made a great video on youtube demonstrating it.

  
  

  For autoleveling we add 2 motor driver (see Driver.h) to change height for 2 of the 3 fixiing points. The driver system is expandable, so you can implement them with servo support instead. That should also do the trick and just needs a different driver class implementation, which is possible by design anyway.
• N37

  November 2016

  Thanks, i'll look in to that next week, right now we have got more phisycal design stuff to handle.