Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Marlin_v1] Strange behaviour after homing #25

Closed
justjoheinz opened this issue Dec 2, 2011 · 15 comments
Closed

[Marlin_v1] Strange behaviour after homing #25

justjoheinz opened this issue Dec 2, 2011 · 15 comments

Comments

@justjoheinz
Copy link

This might actually be a bug of pronterface as well, I am not sure:

I have the firmware configured to do Homing on the Z Axis and aim for the Max Endstop.
In pronterface I press the "Z-Home" button. Axis moves up, reaches the endstop, goes down a bit and slowly reaches the endstop again. This is fine.
M114 reports:
SENDING:M114
X:0.00Y:0.00Z:0.00E:0.00 Count X:0.00Y:0.00Z:210.00
(Note, I have not set the correct Axis lengths yet, hence 210 on a Cupcake!)

Now, when I press the Move down -1mm button on pronterface the axis keeps moving down and down and down. I have to disconnect and reconnect to abort the move.

@bkubicek
Copy link
Contributor

bkubicek commented Dec 2, 2011

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.

@justjoheinz
Copy link
Author

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.

@bkubicek
Copy link
Contributor

bkubicek commented Dec 2, 2011

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?

@justjoheinz
Copy link
Author

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.

@bkubicek
Copy link
Contributor

bkubicek commented Dec 2, 2011

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?

@justjoheinz
Copy link
Author

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.

@justjoheinz
Copy link
Author

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

@bkubicek
Copy link
Contributor

bkubicek commented Dec 7, 2011

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.

@bkubicek
Copy link
Contributor

bkubicek commented Dec 7, 2011

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

@justjoheinz
Copy link
Author

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?

@justjoheinz
Copy link
Author

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?

@bkubicek
Copy link
Contributor

bkubicek commented Dec 8, 2011

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

@justjoheinz
Copy link
Author

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

@justjoheinz
Copy link
Author

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

rosenhouse pushed a commit to rosenhouse/Marlin that referenced this issue Feb 16, 2015
thinkyhead referenced this issue in thinkyhead/Marlin Dec 3, 2016
tonokip pushed a commit to ultimachine/Marlin that referenced this issue Jan 24, 2022
Resolve "Clean Nozzle script is not used"

Closes MarlinFirmware#25

See merge request lulzbot3d/marlin!18
@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants