› ›

autohome motor issue

bpetrusbpetrus
in Motor Control
Dear  experts!

My DIY 3D printer is "Cartesian". The Repetier firmware work good, but if I start to "autohome" or "home X" or "home Y" or "home Z", then the motors go 8 - 10 mm, after only buzz (vibrate).
Why?

Thank you: Peter

Comments

  • RepetierRepetier
    Vibrate is loosing steps especially with some sounds. So check if it gets some friction. Alternatively check steps per mm, acceleration a x jerk and max. speed. Wrong values here can cause faster moves then you think that also cause motors to stall.
  • bpetrusbpetrus
    Well, I'm hurried: If I reduced the max feedrate, then the motors are good....
  • RepetierRepetier
    Great. Just make sure distance moved is also correct e.g. when moving from x=0 to x=100 it should be 100mm or your steps per mm is wrong and reducing speed is just required because real speed is higher due to wrong value there.
  • bpetrusbpetrus
    Thank you for warning! :-)

    But.
    Now, the problem is that the set value is not remembered by the problem. If I turn off, or reset the arduino, then 
    resets to the original 200 value. 
    Even though I write the firmware, it stays at 200.  :-(

    I set the in the Configuration.h:

    #define MAX_FEEDRATE_X 300
    #define MAX_FEEDRATE_Y 300
    #define MAX_FEEDRATE_Z 30
    #define HOMING_FEEDRATE_X 50
    #define HOMING_FEEDRATE_Y 50
    #define HOMING_FEEDRATE_Z 20

    Nonetheless, if I turn on the system, all values again 200

    I wonder why?

    Thanks: Peter
  • RepetierRepetier
    Does firmware have eeprom support enabled? If not it looses all settings on reset/power off and oyu need to set correct values in firmware config and recompile and upload firmware.

    Also you show values not for steps per mm but for speeds.
  • bpetrusbpetrus
    Well, this code:

    // ################# Misc. settings ##################

    #define BAUDRATE 115200
    #define ENABLE_POWER_ON_STARTUP 1
    #define POWER_INVERTING 0
    #define AUTOMATIC_POWERUP 0
    #define KILL_METHOD 1
    #define ACK_WITH_LINENUMBER 1
    #define KEEP_ALIVE_INTERVAL 2000
    #define WAITING_IDENTIFIER "wait"
    #define ECHO_ON_EXECUTE 1
    #define EEPROM_MODE 1

    Is it appropriate?

    Thanks: Peter
  • RepetierRepetier
    #define EEPROM_MODE 1
    enables eeprom, so you should have eeprom support. This also means values normally do not change when you change them in configuration.h only if you send the gcode to reload them from config settings.

    Axis resolution is defined by these settings initially:
    #define XAXIS_STEPS_PER_MM 610
    #define YAXIS_STEPS_PER_MM 610
    #define ZAXIS_STEPS_PER_MM 6400
  • RAyWBRAyWB
    @Repetier : Isn´t there still the EEProm Trap when reconfiguring and Uploading Firmware?

    I still change #define EEPROM_MODE 1 to #define EEPROM_MODE 2 when reuploading with new values.
    and the next time uploading back to #define EEPROM_MODE 1 so EEProm gets updated during upload.





  • RepetierRepetier
    That is no trap it is intentional:-) That is why I said it would not change settings after upload.
    M502
    M500

    would do the same as switching EEPROM_MODE.

  • RAyWBRAyWB
    i know it´s intentional , i mentioned it as "trap" as some users expect eeprom being updated by upload as i guess ;-)
  • bpetrusbpetrus
    Oh, wanderful!
    I uploaded with " #define EEPROM_MODE 2", now works! 
    Is it worth rewriting for " #define EEPROM_MODE 1"?

    Thanks!
  • RepetierRepetier
    No need to switch to 1 back. As said you could also just have run
    M502
    M500

    to get same effect.
Sign In or Register to comment.