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

G29 on corexy moves bed away from endstop first #4418

Closed
MichaelBrock opened this issue Jul 26, 2016 · 6 comments
Closed

G29 on corexy moves bed away from endstop first #4418

MichaelBrock opened this issue Jul 26, 2016 · 6 comments

Comments

@MichaelBrock
Copy link

I have a Corxy printer. In "rest" position the bed sits at the bottom and it is raised to home. With the latest RCBugFix, the printer attempts to push the bed downwards before raising it for homing. Back in the day we would set Z_RAISE_BEFORE_HOMING to 0 to prevent this. A while ago I updated to RC 6 and configured MIN_Z_HEIGHT_FOR_HOMING to 0 this seemed to do the trick. I started using RCBugFix a few weeks ago with no issues. However, yesterday I I just jumped to the latest RcBugFix and before homing Z the printer is again driving the bed downwards (or attempting to). To be clear it is homing X and Y (safe homing is set) first with no issue but before doing Z it is moving the bed downwards. I'm digging my way through the code right now. The issue isn't in the "Raise Z before homing" code as that happens before either x or y is homed (z is homed last with same homing obviously). Any ideas?

@Blue-Marlin
Copy link
Contributor

The second 'raise' is for deploying the probe. (Z_RAISE_PROBE_DEPLOY_STOW)

Park your bed some cm above.
Lift your bed (decrease the distance between nozzle and bed) before homing.
Use a z-max endstop for homing.
Use a conventional z-min endstop.

@MichaelBrock
Copy link
Author

I just found that in the code. Z_RAISE_PROBE_DEPLOY_STOW can't be set to 0 unfortunately. I realize that manually lifting the bed off the bottom to give it room to be lowered will "fix" the problem. I would prefer to fix this without having to do that or reconfigure the entire printer though. It seems to me that the code to deploy the probe shouldn't be run at all if FIX_MOUNTED_PROBE is being used. I guess I'm going to jump into using a customized version of Marlin.

@Blue-Marlin
Copy link
Contributor

There is NO way to make homing with a probe foolproof.
Ether you risk to scratch the bed or banging z-max. Usually scratching the bed is the more expensive problem (Nozzle damage, broken nozzle holder, damaged bed (surface), broken probe )

If you want to complain about unexpected 'extra' raises please join #4282.

@thinkyhead
Copy link
Member

thinkyhead commented Jul 27, 2016

If you want to compile with those set to zero, just make the following change to SanityCheck.cpp:

  /**
   * Make sure Z raise values are set
   */
  #if defined(Z_RAISE_BEFORE_PROBING) || defined(Z_RAISE_AFTER_PROBING)
    #error "Z_RAISE_(BEFORE|AFTER)_PROBING are deprecated. Use Z_RAISE_PROBE_DEPLOY_STOW instead."
  #elif !defined(Z_RAISE_PROBE_DEPLOY_STOW)
    #error "You must set Z_RAISE_PROBE_DEPLOY_STOW in your configuration."
  #elif !defined(Z_RAISE_BETWEEN_PROBINGS)
    #error "You must set Z_RAISE_BETWEEN_PROBINGS in your configuration."
- #elif Z_RAISE_PROBE_DEPLOY_STOW < 1
-   #error "Probes need Z_RAISE_PROBE_DEPLOY_STOW >= 1."
+ #elif Z_RAISE_PROBE_DEPLOY_STOW < 0
+   #error "Probes need Z_RAISE_PROBE_DEPLOY_STOW >= 0."
  #elif Z_RAISE_BETWEEN_PROBINGS < 1
    #error "Probes need Z_RAISE_BETWEEN_PROBINGS >= 1."
  #endif

@thinkyhead
Copy link
Member

the code to deploy the probe shouldn't be run at all if FIX_MOUNTED_PROBE is being used

We might as well keep the option, for the possible case where one starts G29 with the nozzle already touching the bed after a G28. The extra raise might be needed to disengage the switch in that case.

@github-actions
Copy link

github-actions bot commented Apr 5, 2022

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 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants