Marlin: endstops hit

[htaxil]

Hi,

I just finished configuring my Delta printer with Marlin Firmware 1. 1. 0-RC6.

My bed-leveling probe is the hot-end itself, and uses a micro switch which is very sensitive. So it happens that the probe triggers during moves or prints (echo:endstops hit: Z:163.13 P:163.13) and it seems that the firmware integrates this information to correct the tilt bed. Therefore, the effector no longer moves to the horizontal, but tilts.

How can i disable the Z_MIN_PROBE_ENDSTOP outside the bed-leveling ?

My config : https://github.com/htaxil/Marlin/tree/DeltaFold

[Roxy-3D]

I'm really the wrong one to ask. I always have a hard time getting my Z-Probe setup right. ThinkyHead is going to be able to tell you the correct answer.

But until he can answer, try putting your Z-Probe on the Z-Min endstop connector and setting these three defines like this. I think that will make it so it is only used for the Z-Probing.

//#define Z_MIN_PROBE_ENDSTOP
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define DISABLE_Z_MIN_PROBE_ENDSTOP

[htaxil]

Thank's for your quick answere Roxy.

I tested several combinations, but as soon as I activate the setting #define DISABLE_Z_MIN_PROBE_ENDSTOP, I get an error when compiling :

error A probe needs a pin! [Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN || HAS_Z_PROBE]

[Roxy-3D]

OK... Well, ThinkyHead is going to be able to tell you the right combination off of the top of his head.

One thing you can do is look at the example Configuration.h file for a Delta that has a Z-Probe and see how they have those settings. Do you have your

#define USE_XMIN_PLUG

enabled? Because you do have your Z-Probe on it, right?

[Blue-Marlin]

// If you want endstops to stay on (by default) even when not homing
// enable this option. Override at any time with M120, M121.
//#define ENDSTOPS_ALWAYS_ON_DEFAULT

[htaxil]

Hi all,

Roxy, I finally set up z-probe regardless of z-mini.

Blue-Marlin, I have not found ENDSTOPS_ALWAYS_ON_DEFAULT in the RC-6, but I saw it in the RC-7.
Maybe should I upgrade to RC7 release ?...
I tried to use the M121 command, but it doesn't change anything.

The following are excerpts of my configuration (which you can find in full here)

Configuration.h

// Specify here all the endstop connectors that are connected to any endstop or probe.
// Almost all printers will be using one per axis. Probes will use one or more of the
// extra connectors. Leave undefined any used for non-endstop and non-probe purposes.
//#define USE_XMIN_PLUG
//#define USE_YMIN_PLUG
//#define USE_ZMIN_PLUG // a Z probe
#define USE_XMAX_PLUG
#define USE_YMAX_PLUG
#define USE_ZMAX_PLUG

#define Z_MIN_PROBE_ENDSTOP
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
//#define DISABLE_Z_MIN_PROBE_ENDSTOP

#define FIX_MOUNTED_PROBE
#define MECHANICAL_PROBE

pins_RAMP14.h

#define Z_MIN_PIN          32
#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

Configuration_advh

#define ENDSTOPS_ONLY_FOR_HOMING // If defined the endstops will only be used for homing

Roxy, how do you integrate the code to your posts with this formatting and syntax highlighting?

[Roxy-3D]

Roxy, how do you integrate the code to your posts with this formatting and syntax highlighting?

Actually... I used to always do 4x ~ to start and stop a block of code. But ThinkyHead showed me how to get the C++ syntax highlighted. You do 3x grave followed immediately with a cpp and then the block of code. At the end of the block, you just put 3x grave to close it.

This is what it looks like:

code block

[htaxil]

in MarlinDev, there was DISABLE_ZMIN_ENDSTOP parameter, but it no longer exists.

[Roxy-3D]

Yes. And in fact, in the devel_ubl branch, there are some Configuration.h settings that no longer exist. If you do a visual diff of the Configuration.h files, you will see some names have been changed to be more clear. And other names have been dropped. The #define Z_RAISE_???? are an example of that. They are now Z_HEIGHT_???? and there are less of them.

[htaxil]

Ok, waiting a more detailled help from ThinkerHead, i will continue grope.

[htaxil]

Hi psco68,

run_stow_moves_script() no longer exists un marlin 1.1.0-RC6. Furthermore, judging by the name of this procedure, it seems to concern the deployment or the retract of the probe, in my case the probe is fixed.

[htaxil]

I finally found a solution. I don't know why but the M121 command works today. I have so integrated it into the Z_PROBE_END_SCRIPT command

//#define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10" // These commands will be executed in the end of G29 routine.
                                                                             // Useful to retract a deployable Z probe.
  #define Z_PROBE_END_SCRIPT "M121"

[pysco68]

Hi,

actually I had the phenomenon, that the bed leveling worked perfectly except the retract phase of my allen key z probe. In my case I'm dealing with RC7 and the procedure's definitively there and in use.

The issue was (I mean I think - I'm in no way a marlin fw expert) that the endstop was triggered during the stow move which caused the printer to halt. Thus my "fix" to disable the endstops during the stow moves.

[Roxy-3D]

The issue was (I mean I think - I'm in no way a marlin fw expert) that the endstop was triggered during the stow move which caused the printer to halt. Thus my "fix" to disable the endstops during the stow moves.

Since the Allen Key probes came out, there have been problems with them being 'Triggered' when they are not even deployed. This has been causing issues for a while. Starting at about RC-5 (give or take) there has been the ability to ignore 'Triggered' situations unless the machine is actually doing a probe.

The support is definitely in place to handle that situation!

[pysco68]

Okay, then there's some configuration option that I've overlooked or the like. Any clue what I'm missing?

Here's my config (excerpt)

#define USE_ZMIN_PLUG // this is my Z probe
#define USE_XMAX_PLUG
#define USE_YMAX_PLUG
#define USE_ZMAX_PLUG

#define Z_PROBE_ALLEN_KEY
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

Thanks for the help - meanwhile my "fix" seems to work for RC7 (and my configuration)

[thinkyhead]

@htaxil The probe is supposed to disable as soon as it's stowed (or in your case, done), but I see what is probably a bug in RC6. And it seems to exist (in a different form) in RC7 as well. The probe is not being disabled.

To fix the issue in RC6, go to the region of lines 3584-3586 of Marlin_main.cpp and change…

-     #if ENABLED(HAS_Z_MIN_PROBE)
-       z_probe_is_active = false;
-     #endif
      st_synchronize();
    #endif
+
+   #if HAS_Z_MIN_PROBE
+     z_probe_is_active = false;
+   #endif

If this works, great! I will be making a similar change to RCBugFix.

[thinkyhead]

@pysco68 For your situation with RC7, a similar problem exists, but apparently only with homing Z. Since you're using an Allen Key probe I presume you must be using a DELTA. Therefore the logic in lines 2479-2484 of Marlin_main.cpp is screwing with you. Change the code for homing the Z axis in this manner and see if it works:

    if (axis == Z_AXIS && axis_home_dir < 0) {
      #if ENABLED(DEBUG_LEVELING_FEATURE)
        if (DEBUGGING(LEVELING)) SERIAL_ECHOPGM("> ");
      #endif
      if (STOW_PROBE()) return;
    }
+   else if (axis == Z_AXIS) {
+     endstops.enable_z_probe(false);
+   }

After G29, from what I can see, the probe is properly disabled in RC7.

[thinkyhead]

problems with them being 'Triggered' when they are not even deployed

@pysco68 The allen key probe has another feature, which is that Marlin actually _expects it to be triggered_ when it's stowed. That logic is handled in lines 2083-2095 of Marlin_main.cpp. I'm not sure how this is working out in your case, but it could prevent the probe from being disabled if it doesn't show up triggered as soon as it's stowed.

We don't have a lot of testers with allen key probes. So perhaps you can help to debug this issue further in RCBugFix…?

[zenmetsu]

Wasn't this already addressed by https://github.com/MarlinFirmware/Marlin/pulls?utf8=%E2%9C%93&q=4551 Or is this a different problem?

[pysco68]

@thinkyhead: yes I have a delta, I'll check your fix tomorrow morning, and yes I'd be happy to help fix that in RCBugFix

[pysco68]

I just reverted my patch and tried the changes in Marlin-main.cpp you suggested, but the problem is still there.

I looked at the lines 2083-2095 and I understand how it works. And all the tests (_TRIGGERED_WHEN_STOWED_TEST) etc pass ok. It's just that the motion stops when the probe is triggered during the run_stow_moves_script()`.

I uploaded a short video of the bed leveling feature running: https://staudteng-my.sharepoint.com/personal/yannic_staudt_staudteng_onmicrosoft_com/_layouts/15/guestaccess.aspx?guestaccesstoken=4Qv4b%2bO0mmbABvP3qTjmrZnk2vaijlmpMRkEQ9A%2bbEY%3d&docid=0896490d0f96141c3ac2adacf1ae03760&rev=1

[thinkyhead]

@pysco68 Here's a couple of things you can try. First, I note that the code at least _attempts_ to disable the probe before it stows it. See line 2084 in Marlin_main.cpp. So what's going on here? And why do endstops being enabled matter to the probe being triggered?

Note that the endstops are read and updated whenever _either_ the probe or the endstops are enabled. If neither one is enabled, then neither one is updated. But! If the probe isn't enabled then the state of the probe is not updated at all. Could it be that it's left in a "triggered" state?

So, try this. In endstops.cpp find the enable_z_probe method and change it to:

static void enable_z_probe(bool onoff=true) { z_probe_enabled = onoff; current_endstop_bits = 0; }

Does that have any effect? Maybe, maybe not. So here's another thing you could try. In the set_probe_deployed function in Marlin_main.cpp insert a line like so…

+   endstops.enable_z_probe(false)

    // Make room for probe
    do_probe_raise(_Z_PROBE_DEPLOY_HEIGHT);

Maybe that will do the trick? An alternative to that might be to make a slightly different change just below, where it disables the Z probe before the stow moves:

-       if (!deploy) endstops.enable_z_probe(false); // Switch off triggered when stowed probes early
+       if (!deploy) {  // Switch off triggered when stowed probes early
+         endstops.enable_z_probe(false);
+         delay(50);
+       }

If none of this has any effect I'll try to come up with some other ideas.

[pysco68]

Okay, so the in RC7 (which I'm using - in the video too) the problem was simply the missing https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Marlin_main.cpp#L2084 (from the current version, so basically my fix was doing the same just in a different place)

Give me a few minutes to check if RC bugfix works flawlessly (in that regard)

[thinkyhead]

Thanks for the update. I will sleep better knowing that there's not some weird flaw in the endstop pin handling.

[pysco68]

RCBugFix is working too.

Btw. if you have specific things to try on a delta, drop me a line, I'll be happy to help you out if necessary. Marlin is a great piece of hardware and if I can help make it better I'll do so! And at the moment I own two deltas, so its not much of an issue to try things ;)

[thinkyhead]

Thank you for the offer! I would be doing a lot more testing of things myself, but I'm thousands of miles from my 3D printers. And yes, it is painful.

[htaxil]

@thinkyhead I made the change that you proposed me, but it changes nothing. The ZMIN probe remains activated after the G29 cycle. Note that I do not use retractable probe.

My Marlin_main.cpp (line 3584) :

      #if HAS_Z_MIN_PROBE
        z_probe_is_active = false;
      #endif
      st_synchronize();
    #endif

[thinkyhead]

@htaxil Still using RC6?? I recommend moving on to RC7 or RCBugFix which I'm told has this fixed already.

[htaxil]

@thinkyhead yes, still using RC6. I will migrate soon.
Thank you all for your help :)