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

Head crashing into heatbed on delta when issuing G29 #3666

Closed
tiagom62 opened this issue May 3, 2016 · 35 comments
Closed

Head crashing into heatbed on delta when issuing G29 #3666

tiagom62 opened this issue May 3, 2016 · 35 comments

Comments

@tiagom62
Copy link

tiagom62 commented May 3, 2016

I hope this is the proper place to ask as this is my first 3d printer, i tried the reprap IRC chat without success.

Machine is a Folger Tech Kossel.

I am using version 1.1.0-RC6 my configuration file is here: http://pastebin.com/UX5LRC8y

Only other change i have made is to RAMPS_14.h because i have a reprapdiscount smart controller that seems to occupy pin 32. The change being

if ENABLED(Z_MIN_PROBE_ENDSTOP)

// Define a pin to use as the signal pin on Arduino for the Z_PROBE endstop.
#define Z_MIN_PROBE_PIN 18

endif

I have verified that z_probe changes states from open to triggered using M119.

When i attempt to auto bed level using G29 after homing using G28, the printer drives the print head into the aluminum heat bed. The issue seems better when it gets to the middle of the plate as it just barely touches the plate.

I put a metal ruler along the first set of test points and it just crashes into it. When using the steel ruler the sensor seems to trigger earlier as indicated by the led on it.

@aiiaiiiyo
Copy link

aiiaiiiyo commented May 3, 2016

I have the same error, it started from RC4. It worked well in RC3. Tried the RC4,RC5,RC6 and the bugfix branch also, but the same issue.

I have a Kossel Mini using an inductive sensor. Endstops and sensor are changes states perfectly, tested with M119.

G28 then G29, it goes to the first point and trying to press the hotend under the alu heatbed constantly.

Edit: I'm currently not near my main computer, but I will be able to provide debug log message later.

@Blue-Marlin
Copy link
Contributor

For a DELTA try to define MECHANICAL_PROBE instead of FIX_MOUNTED_PROBE.

FIX_MOUNTED_PROBE did not work for deltas, but instead of fixing that for deltas, someone thought it would be a good idea to introduce a new kind of probe. :-(

@WZ9V
Copy link

WZ9V commented May 3, 2016

Make sure you have both your z height and any z probe offset set correctly or at least pretty close.

@tiagom62
Copy link
Author

tiagom62 commented May 3, 2016

@pubbebubben I'll try to test RC3 later today on my setup.

@Blue-Marlin I am experiencing the same issue with MECHANICAL_PROBE instead of FIX_MOUNTED_PROBE.

@WZ9V Are you referring to [XYZ]_PROBE_OFFSET_FROM_EXTRUDER? If so i believe i have reasonable values set.

I believe that i have MANUAL_Z_HOME_POS set appropriately. If i manually lower the machine using repetier-host the tip does not crash into the bed when z reaches 0.

@thinkyhead
Copy link
Member

thinkyhead commented May 3, 2016

Looking at your configuration @tiagom62

If you're connecting your Z probe to one of the unused endstop pins, you should enable the plug here:

//#define USE_XMIN_PLUG
//#define USE_YMIN_PLUG
//#define USE_ZMIN_PLUG

Since you have Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN you probably want to enable USE_ZMIN_PLUG.

@tiagom62
Copy link
Author

tiagom62 commented May 3, 2016

@thinkyhead i thought that as well but from what i recall uncommenting USE_ZMIN_PLUG produced a sanity check error. I will try this later today and provide you the output.

@Roxy-3D
Copy link
Member

Roxy-3D commented May 3, 2016

//#define USE_XMIN_PLUG
//#define USE_YMIN_PLUG
//#define USE_ZMIN_PLUG

This wording seems a little bit cryptic. Wouldn't it be better to have something like:

//#define USE_XMIN_PLUG_FOR_Z_PROBE
//#define USE_YMIN_PLUG_FOR_Z_PROBE
//#define USE_ZMIN_PLUG_FOR_Z_PROBE

@thinkyhead
Copy link
Member

thinkyhead commented May 3, 2016

That's not what those settings mean, @Roxy-3DPrintBoard. The USE_[XYZ](MIN|MAX)_PLUG setting only indicates that the plug connector is in use and should not be ignored.

@thinkyhead
Copy link
Member

thinkyhead commented May 3, 2016

from what i recall uncommenting USE_ZMIN_PLUG produced a sanity check error

If it does, please post the error.

@tiagom62
Copy link
Author

tiagom62 commented May 4, 2016

@thinkyhead new configuration http://pastebin.com/DDH07Qme

Error i recalled is:

SanityCheck.h:215: error: #error A probe should not be connected to more than one pin! [Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN || HAS_Z_PROBE]

   #error A probe should not be connected to more than one pin! [Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN || HAS_Z_PROBE]

    ^

exit status 1
#error A probe should not be connected to more than one pin! [Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN || HAS_Z_PROBE]

@WZ9V
Copy link

WZ9V commented May 4, 2016

OK, those were what I was thinking of and if the host stops at 0 without crashing when moving manually that would indicate something wrong with the z-min endstop settings when using it for the probe. It's been a while since I messed with this in Marlin and when I did it was a different fork. Sorry I can't help more.

@thinkyhead
Copy link
Member

thinkyhead commented May 4, 2016

Let's take a look at that error. I didn't add that check, so I need to deconstruct it…

#if ((HAS_Z_MIN && ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)) && HAS_Z_PROBE)  ...
  • HAS_Z_MIN indicates that you have a Z_MIN_PIN defined. That's the usual case, unless USE_ZMIN_PLUG is disabled.
  • Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN indicates that the probe and the Z min endstop share the same pin (Z_MIN_PIN).
  • HAS_Z_PROBE indicates that the Z_MIN_PROBE_PIN is (also) defined. For some boards, this will be true only if you have Z_MIN_PROBE_ENDSTOP enabled. For some other boards, Z_MIN_PROBE_PIN will always be defined (which is my recommendation, because I feel that boards should "suggest" the best pin to use).
    • This might be a source of trouble for you. You can enable DISABLE_Z_MIN_PROBE_ENDSTOP to undefine Z_MIN_PROBE_PIN.
&& ( ENABLED(FIX_MOUNTED_PROBE) || defined(Z_ENDSTOP_SERVO_NR)
     || ENABLED(MECHANICAL_PROBE) || ENABLED(Z_PROBE_SLED))

Together these just test that you have some kind of probe.

  • FIX_MOUNTED_PROBE is an inductive (non-servo) probe.
  • defined(Z_ENDSTOP_SERVO_NR) indicates a Z probe on a servo arm.
    • This should actually be HAS_Z_ENDSTOP_SERVO here (the same thing).
  • MECHANICAL_PROBE is when the probe is the nozzle.
  • Z_PROBE_SLED indicates a probe on a docking sled.

@tiagom62
Copy link
Author

tiagom62 commented May 4, 2016

@thinkyhead Setting DISABLE_Z_MIN_PROBE_ENDSTOP produced the following error with my configuration.

SanityCheck.h:250: error: #error You must have a Z_MIN_PROBE_PIN defined in your pins_XXXX.h file if you enable Z_MIN_PROBE_ENDSTOP.

       #error You must have a Z_MIN_PROBE_PIN defined in your pins_XXXX.h file if you enable Z_MIN_PROBE_ENDSTOP.

        ^

exit status 1
#error You must have a Z_MIN_PROBE_PIN defined in your pins_XXXX.h file if you enable Z_MIN_PROBE_ENDSTOP.

I then disabled Z_MIN_PROBE_ENDSTOP which which allow me to successfully compile. Those changes allowed me to auto bed leveled successfully.

The change i made to RAMPS_14.h was not required. I reverted back the change and retested successfully.

I would like to thank you for your assistance, it is much appreciated.

@pubbebubben

Here is my current configuration file with functioning auto bed level. I hope this is useful getting your auto bed leveling functional on newer firmware.

http://pastebin.com/yQ0bmvaY

@tiagom62 tiagom62 closed this as completed May 4, 2016
@thinkyhead
Copy link
Member

Whew! I also find all these probe options a little confusing. Okay, a lot. I'm starting to clean it up with #3672 but really want to come up with better names. The Z_MIN_PROBE_ENDSTOP setting in particular really bugs me.

@AnHardt
Copy link
Contributor

AnHardt commented May 4, 2016

Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN indicates that the probe and the Z min endstop share the same pin (Z_MIN_PIN).

Originally this was meant as: "The probe is connected to the Z_MIN_PIN. This connector is blocked by the probe. We do not have a z-min-endstop. Use the probe for homing to z-min."

@AnHardt
Copy link
Contributor

AnHardt commented May 4, 2016

Z_MIN_PROBE_ENDSTOP, for me, should mean: "The probe is connected to its own Z_MIN_PROBE_PIN. We also have a z-min-endstop connected to Z_MIN_PIN. Use the endstop for homing and the probe for probing."

That way the decision whether to use the probe for homing or not is made by the pin you use.

DISABLE_Z_MIN_PROBE_ENDSTOP is meant as: "Don't use the probe for homing if we have both, endstop and probe." This statement is superfluous if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and Z_MIN_PROBE_ENDSTOP are read as described above. Technically it is still needed until we unify SERVO_LEVELING with HAS_SERVO_ENDSTOPS and replace it with a common probe handling.

@AnHardt
Copy link
Contributor

AnHardt commented May 4, 2016

Just to repeat myself:
3f45a1a at the bottom.
#3154 (comment) #3082
#3154 (comment)
#3154 (comment)

@tiagom62
Copy link
Author

tiagom62 commented May 4, 2016

Being completely unfamiliar with marlin(and 3d printers) i found the configuration comments unclear as to what needed to be set for probing on my delta printer.

What i believe confused me was the comments for DISABLE_Z_MIN_PROBE_ENDSTOP

// This option disables the use of the Z_MIN_PROBE_PIN
// To enable the Z probe pin but disable its use, uncomment the line below. This only affects a
// Z probe switch if you have a separate Z min endstop also and have activated Z_MIN_PROBE_ENDSTOP above.
// If you're using the Z MIN endstop connector for your Z probe, this has no effect.

The last line in particular, i interpreted it as follows..

If you are using the z min endstop pin for the z probe then defining DISABLE_Z_MIN_PROBE_ENDSTOP has no effect.

Which in my case this was the missing piece to getting probing working.

@aiiaiiiyo
Copy link

@tiagom62 Thank you for the config file. It guided me in the right direction and finally the autoleveling works for me with the RC6 release.

Actually my problem was the same as you had. I didn't uncommented the DISABLE_Z_MIN_PROBE_ENDSTOPline. I'm also interpreted that last sentence in the same way.

@tiagom62
Copy link
Author

tiagom62 commented May 4, 2016

@thinkyhead Perhaps we can make that comment clearer as it may trip up others in the future.

@thinkyhead
Copy link
Member

thinkyhead commented May 5, 2016

I think it would help to have a complete grid / chart of how to set the probe (and endstop) options based on different kinds of setups. Certain combinations of these settings might be "nonsense" and we should check for that too. From the chart we should have a very good idea of how they all relate, and maybe this will even reveal a way to give a higher level of control (similar to the way that selecting an LCD controller enables a certain combination of sub-options).

@thinkyhead
Copy link
Member

thinkyhead commented May 5, 2016

I guess the "big three" options that need to be better understood in relation to each other are…

Z_MIN_PROBE_ENDSTOP
DISABLE_Z_MIN_PROBE_ENDSTOP
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

…and should be considered in combination with…

USE_XMIN_PLUG
USE_YMIN_PLUG
USE_ZMIN_PLUG // <===== This One Especially
USE_XMAX_PLUG
USE_YMAX_PLUG
USE_ZMAX_PLUG

Does this (proposed) sanity check make sense? :

#if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) && DISABLED(USE_ZMIN_PLUG)
  #error You must enable USE_ZMIN_PLUG if any probe or endstop is connected to the ZMIN plug.
#endif

@tiagom62
Copy link
Author

tiagom62 commented May 5, 2016

Sanity check makes sense to me. I tested it with my original configuration and it catches the configuration error.

@tiagom62
Copy link
Author

tiagom62 commented May 5, 2016

Is there any case where Z_MIN_PROBE_ENDSTOPand Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PINshould be enabled together? If not perhaps a sanity check for that would be useful as well.

#if ENABLED(Z_MIN_PROBE_ENDSTOP) && ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
 #error Z_MIN_PROBE_ENDSTOP and Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN should not be enabled together.
#endif

@Blue-Marlin
Copy link
Contributor

Blue-Marlin commented May 5, 2016

// To use a probe you must enable one of the two options above!

One and only one.

There is also no way to make sense of defining Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and DISABLE_Z_MIN_PROBE_ENDSTOP together.

@thinkyhead
Copy link
Member

thinkyhead commented May 6, 2016

A set of mutually-exclusive options should be consolidated into a single one. (LCD controller options excepted, for the moment!) For example, the single setting DISPLAY_CHARSET_HD44780 replaced 3 separate options.

@thinkyhead
Copy link
Member

thinkyhead commented May 6, 2016

For the moment I've added this mutual-exclusivity test…

/**
 * Only allow one probe pin option to be defined
 */
#if (ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) && (ENABLED(Z_MIN_PROBE_ENDSTOP) || ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP)))
     || (ENABLED(Z_MIN_PROBE_ENDSTOP) && ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP))
  #error Please enable only one of: Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, Z_MIN_PROBE_ENDSTOP, or DISABLE_Z_MIN_PROBE_ENDSTOP.
#endif

…but I would like to add more explanatory text about each one, in the format:

#if (ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) && (ENABLED(Z_MIN_PROBE_ENDSTOP) || ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP)))
     || (ENABLED(Z_MIN_PROBE_ENDSTOP) && ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP))
  #error Please enable only one of these options: \
         Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN for a probe connected to Z_MIN_PIN. \
         DISABLE_Z_MIN_PROBE_ENDSTOP for a probe that... \
         Z_MIN_PROBE_ENDSTOP for a probe that...
#endif

@jbrazio
Copy link
Contributor

jbrazio commented May 6, 2016

but I would like to add more explanatory text about each one

Could we give such examples near the option section in Configuration.h and on the #error point the user to read that section for more details ?

@thinkyhead
Copy link
Member

thinkyhead commented May 6, 2016

It was stated earlier that you can only enable one of these options, and yet the Configuration.h file reads:

// This option disables the use of the Z_MIN_PROBE_PIN.
// To enable the Z probe pin but disable its use, uncomment the line below.
// This only affects a Z probe switch if you also have a separate Z min endstop
// and have activated Z_MIN_PROBE_ENDSTOP above.
// If you're using the Z MIN endstop connector for your Z probe, this has no effect.
//#define DISABLE_Z_MIN_PROBE_ENDSTOP

The text "This only affects … if you have … also … activated Z_MIN_PROBE_ENDSTOP above." implies that you must set Z_MIN_PROBE_ENDSTOP in order to use DISABLE_Z_MIN_PROBE_ENDSTOP, and that DISABLE_Z_MIN_PROBE_ENDSTOP is not a good setting by itself.

@jbrazio
Copy link
Contributor

jbrazio commented May 6, 2016

implies that you must set Z_MIN_PROBE_ENDSTOP in order to use DISABLE_Z_MIN_PROBE_ENDSTOP

Exactly. after reading it 10x I could reach the same conclusion.
A non native speaker had to read it 10x to be able to take a conclusion in order to compare with yours. Definitely we need improvement there.

@thinkyhead
Copy link
Member

thinkyhead commented May 6, 2016

According to the documentation then, the actual sanity check should be:

/**
 * Don't allow nonsense probe-pin settings
 */
#if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) && ENABLED(Z_MIN_PROBE_ENDSTOP)
  #error You can't enable both Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and Z_MIN_PROBE_ENDSTOP.
#elif ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) && ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP)
  #error You can't enable both DISABLE_Z_MIN_PROBE_ENDSTOP and Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN.
#elif ENABLED(DISABLE_Z_MIN_PROBE_ENDSTOP) && DISABLED(Z_MIN_PROBE_ENDSTOP)
  #error You must enable Z_MIN_PROBE_ENDSTOP if DISABLE_Z_MIN_PROBE_ENDSTOP is enabled.
#endif

@jbrazio
Copy link
Contributor

jbrazio commented May 6, 2016

Scott before continue to discuss how the current sanity check could be improved, wouldn't be better to decide #3672 ?

@thinkyhead
Copy link
Member

thinkyhead commented May 6, 2016

Not necessarily. It doesn't rename any of the configuration options. It just combines some conditions to reduce the verbosity of these checks. And I am adding the sanity checks to #3672.

@thinkyhead
Copy link
Member

Continuing on #3672… this is closed.

@github-actions
Copy link

github-actions bot commented Apr 8, 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 8, 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

8 participants