› ›

Motor after homing in Z going down

Comments

  • RepetierRepetier
    #define ENDSTOP_Z_BACK_ON_HOME 0.5

  • GarremmashGarremmash
    #define ENDSTOP_Z_BACK_ON_HOME 0.5

    change it or what?
  • RepetierRepetier
    Yes, you said go up 0.5mm here. If you don't want to don't say it:-)
  • GarremmashGarremmash
    Yes, you said go up 0.5mm here. If you don't want to don't say it:-)
    It's going  DOWN and pushing a heatbed, and it's really near to 50 mm
  • GarremmashGarremmash
    I captured where is a problem
  • GarremmashGarremmash
    there is some problem with
    Endstop distance after homing
    ENDSTOP_(X|Y|Z)_BACK_ON_HOME
    in Z axis
  • RepetierRepetier
    What version are you using?

    Where does your endstop trigger? Exactly at z = 0 or above bed?

    I guess it is also z probe so you need latest dev version and need to disable always check endstops.

    After probing it corrects ENDSTOP_Z_BACK_ON_HOME + z probe height + bed coating so check what values you have in eeprom for them (ENDSTOP_Z_BACK_ON_HOME is only in configuration.h and should be 0 in your case). Setting all to 0 should stop the latest move. If so then adjust z probe height.
  • GarremmashGarremmash
    What version are you using?

    Where does your endstop trigger? Exactly at z = 0 or above bed?

    I guess it is also z probe so you need latest dev version and need to disable always check endstops.

    After probing it corrects ENDSTOP_Z_BACK_ON_HOME + z probe height + bed coating so check what values you have in eeprom for them (ENDSTOP_Z_BACK_ON_HOME is only in configuration.h and should be 0 in your case). Setting all to 0 should stop the latest move. If so then adjust z probe height.
    I'm using 0.9.2, but in a dev version it don't want to make first Z, not complining the firmware, otherwise no way to use inductive sensor, changing it to 0 or to 100 or anything else don't changing something in moves
  • GarremmashGarremmash
    edited June 2016
    1)changing to dev not helped, same problem
    2)In dev not working
    HOMING_ORDER
    Z,X, then Y
    when compiling - such bug
    Printer.cpp:1715:3: error: #error Illegal homing order for z probe based homing!
      #error Illegal homing order for z probe based homing!
       ^

  • RepetierRepetier
    The error message is clear I think. If z min is z probe position in xy is important so you need to home xy first so you need xyz homing order, thats all. Older versions did not have that security check and did it wrong anyway.
  • GarremmashGarremmash
    The error message is clear I think. If z min is z probe position in xy is important so you need to home xy first so you need xyz homing order, thats all. Older versions did not have that security check and did it wrong anyway.
    yes, i i fixed it, but...
    1) why when I pressing in pronterface homing for Z it makes home all axis
    2) still problem with pushing the table, even in dev it NOT fixed
  • RepetierRepetier
    1) As I said it needs xy homed so home z will enforce that.
    2) ??? YOu mean original problem? Checked eeprom values on variables I said?

  • GarremmashGarremmash
    1) As I said it needs xy homed so home z will enforce that.
    2) ??? YOu mean original problem? Checked eeprom values on variables I said?

    1) I think it's abnormal, because G28 Z must make just in one axis, Z axis, it's not a security, it's a problem for user. I know how get round it, but why I must get round things that must working not like this? For homing all axes there is a G28 command. 
    2) Yes, it's fixed.
    THANKS

  • RepetierRepetier
    This is only if you use z probe for z min. There xy position matters and must be known. With the new dev version I might now be able to disable it once xy is homed as we now store if xy is homed. Earlier version did not know so they had to assume worst.
Sign In or Register to comment.