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

N37N37
edited November 2016 in Questions & Answers
I have another problem with repetier.

This firmware has go it's own moods.

1 question

When i upload new firmware the printer ignores the current settings in new firmware.
I've set feedrate and max travel speeds , and they are ignored. The printer uses the settings manualy set.

So how the hell i can remove data from eeprom cince it stays there over firmware reflash ?


Is there a option to "DELETE/CLEAR EEPROM" in LCD menu ? or how to do that in other way ?


2 question

Is there a manual for configuration.h that describes exactly all the options ?

I'm looking for detailed info about every option and what it does, because hints on online configurator are not clear for me, maby i'm just too stupid.

But in other hand i do not have any problems with understanding comments in configuration.h of marlin firmware.

SO maby problem isthat configuration.h of repetier does not have them.... rotfl

Comments

  • 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.
  • N37N37
    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 :)


  • 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:-) 
  • @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
  • 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.
  • 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.
  • 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.

  • N37N37
    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.

  • 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.
  • Thanks, i'll look in to that next week, right now we have got more phisycal design stuff to handle.


Sign In or Register to comment.