Motor after homing in Z going down

Garremmash

Here is a video 

https://dl.dropboxusercontent.com/u/9343746/VID_20160604_225232.mp4

Here is my configuration.h

http://pastebin.com/ZQ0qw5Dm

Repetier

#define ENDSTOP_Z_BACK_ON_HOME 0.5

Garremmash

#define ENDSTOP_Z_BACK_ON_HOME 0.5

change it or what?

Repetier

Yes, you said go up 0.5mm here. If you don't want to don't say it:-)

Garremmash

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

Garremmash

I captured where is a problem

https://dl.dropboxusercontent.com/u/9343746/VID_20160608_214103.mp4

Garremmash

there is some problem with

Endstop distance after homing

ENDSTOP_(X|Y|Z)_BACK_ON_HOME

in Z axis

Repetier

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.

Garremmash

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

Garremmash

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!

   ^

Repetier

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.

Garremmash

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

Repetier

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?

Garremmash

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

Repetier

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.