[Marlin_v1] Strange behaviour after homing about marlin HOT 15 CLOSED

I will try to reproduce this. Thats quite strange, and should not happen. Could you please tell, if you used the git-branch version or the tagged beta1? Also, can you assure that there is no problem in the endstop direction settings. You can test also by having manually toggling an endstop, and trying to move towards the endstop. If this for a strange reason works, with the same endstop toggled, try the other direction. If this other direction then blocks, there is most likely a confusion in the configuration.

from marlin.

I use the latest git pull of the v1 branch.
I am not quite sure whether I understood your other directions correctly.

I only have one endstop (just the Z_MAX). The homing itself works fine. It is just the move command afterwards which does not work as expected. I also do not do a G28, but only a G28 Z or whatever the command is, which pronterface sends when pressing the z home button. I also use pronterface from git, and not a tagged version.

from marlin.

ok. Z_MAX is usually an endstop at the highest possible z-value, while z_min is the endstop that is typically triggered at z=0.
A triggered Z_MAX should inhibit you from increasing the z-value, and allow you to go backwards towards Z_MIN by decreasing z values. Which actually partially fits to your description.
Is it possible that you have a incorrect config where Z_MAX is used instead of Z_MIN?

from marlin.

I guess we have a communication problem :-)

I have an endstop on Z_MAX (the top of my makerbot). I home to Z_MAX. The extruder axis / Z moves up to the maximum position, does the little endstop dance and stays at the max position. From my point of view the homing routine is sucessful.

Now I want to move down a little bit. I press the move down -1mm button in pronterface and it just keeps going down and down and down. I do not know where it would stop, and I usually abort.

Excerpt Configuration.h:

/// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR 1

Excerpt pins.h

#define Z_MIN_PIN 18
#define Z_MAX_PIN 19

Please let me know what other information might be useful.

from marlin.

Sorry, I have thought thats we are talking about an endstop related problem. Have you checked that you have the correct DEFAULT_AXIS_STEPS_PER_UNIT in Configuration.h ? If so, can you make sure that the first serial echos from the Printer contain the actual correct DEFAULT_AXIS_STEPS_PER_UNIT values?

from marlin.

Yes, those values are correct. I also do prints with this setup (which are marvelous). I am just the guy who seems to stumble over strange bugs :-)
The problem is really after the homing. It somehow behaves as if it tries to home to Z_Min when instead I just told it to move down 1 mm. And this happens only after homing to max. I also can use the control panel of pronterface to move all axis along, as long as I do not home to Z_MAX.

IMPORTANT: I just did another test. I reported previously that after Z_MAX_Home I can't use go down on z anymore. I just tried the other axis, X & Y. They also behave strange. All commands I use to move somewhere: x+, x-, y+, y- always result in the bot moving the z axis down. It really seems that it insists to do a HOME Z_MIN before it does any other moves.

from marlin.

Anything I can do to help solve the issue? Revert to the Marlin_ Gen3 firmware to see if it works there? Provide debugging info?

from marlin.

Sorry I did not have time yet to do anything, pre-christmas stress. Tomorrow is a holiday here, hopefully I will have some time then.

from marlin.

ok, i just tried with machine. I usually home to z-min,x-min,ymin. I tried to home to z-max,x-min,y-min. After the homing to z-max (aka the end height of the biggest possible printable object), I can only decrease the height, and 1mm is one mm.
Everything as it should be for me.
There was a general bug with the g28, that i intruduced by having the option to already set the position by "g28 x-105 y-105", and solved now.Maybe that was the problem. please try, and tell me your results...

from marlin.

Ok, I pulled all the changes up to today. The good results:
If I enter g28 in the pronterface gcode prompt and issue that command all works well and as expected.
However if I press the "Z-Home" button on pronterface the behaviour is as I described above. Any idea how I can find out what command pronterface is sending that results in this behaviour?

from marlin.

Ok, got it: When I issue the "G28 Z" command to just home the z axis, I get the error after the homing took place. Is the command as such invalid?

from marlin.

ah i just had an idea and think i know the problem. However I am printing for the next hour...

from marlin.

Fine! Print as long as you like :-) I am just happy that we are getting somewhere. I am just heating up too!

from marlin.

This somehow has been fixed awhile ago. Sorry - did not follow on the issue, just worked eventually after a new pull.

from marlin.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from marlin.