bugfix-2.0.x G28 with bump does NOT execute "Home 2 Slow" move #11056
Comments
|
you have |
|
@autonumous It also means that the routine enabled by This is the minimum modification needed to make it work as expected… $ git diff 225b2546c
diff --git a/Marlin/Configuration.h b/Marlin/Configuration.h
index 33fb9df8e..55847ee25 100644
--- a/Marlin/Configuration.h
+++ b/Marlin/Configuration.h
@@ -576,7 +576,7 @@
* based on the Makerbot design, since they already include the 100nF capacitor.)
*/
//#define ENDSTOP_NOISE_FILTER lrp changed... it needs to put capacitor...
-#define ENDSTOP_NOISE_FILTER
+//#define ENDSTOP_NOISE_FILTER
//=============================================================================
//============================== Movement Settings ============================ |
|
@thinkyhead I have not the skill (given the time I can spend) to debug this problem... I have no problem testing…. If you want, I'll keep my branch open till closure of this bug report: Just tell me. |
|
@lrpirlet : ENDSTOP_NOISE_FILTER works as expected. It just waits until the endstop line stops changing and, only at that time, it uses the endstop value as the accepted (denoised) value. |
|
The other way around. |
|
Please disregard hardware failure, it worked fine before I went to bugfix-2... |
|
The previous implementation had a 2 sample noise filter enabled at all times. The new approach, if you comment out (ENDSTOP_NOISE_FILTER) has no filter at all, and, if you enable it, has a filter that waits 7 samples with the same value before accepting the new endstop state... Sampling is done every 1mS .. |
|
As previously mentioned in another thread (#10986), on my setup, I do see a change in Z behaviour when enabling For me, it was easier to fix the issue that required me to use that option (by adding a capacitor to the Endstop) which was only introduced around May 21st |
|
@ejtagle — The endstop noise filter requires 7 samples before it trusts that the endstop state has changed, and this counting only occurs in So perhaps the endstop filter should be in effect at a lower level —at all times— and not just count-down when endstops are enabled. |
|
Teoretically, when you enable |
|
Only |
|
endstops.poll() calls update() (otherwise, a horrible bug would be there... ) |
|
But |
|
Humm.. Then we have a problem. Maybe it should always be called ? |
|
Humm... good question. Yes, this seems incorrect, but the periodic polling must be done periodically... |
|
The best solution to avoid side-effects would seem to be testing the endstops at all times and maintaining the "validated state" as a lowest-level value. |
|
I was thinking on the purpose of ENDSTOPS_ENABLED |
|
Yes, the idea is to always poll... or at least, when the endstop_poll_count > 0 |
|
Please, correct me if i am wrong @thinkyhead : The purpose of ENDSTOPS_ENABLED is just to filter out the reporting of endstops being hit - If that is the case, then we can modify easily the endstops::update() function to keep polling and only report if endstops are enabled |
|
Correct. The |
|
Do you want me to test anything? |
|
Let me check your config file... |
|
@lrpirlet : Could you try increasing The default 2mm bump for Z and the default speed of 4mm/s should give 0.5seconds for the bump, and that is 500 endstop samples ... unless the endstop code is disabled while performing the sampling... But i think it is not... |
|
Please note that I had to edit Marlin/src/module/endstops.h to remove a duplicate declaration that made PlatformIO to stop on error… git diff shows diff --git a/Marlin/src/module/endstops.h b/Marlin/src/module/endstops.h
index 830b1515b..7b41977bf 100644
--- a/Marlin/src/module/endstops.h
+++ b/Marlin/src/module/endstops.h
@@ -73,7 +73,7 @@ class Endstops {
#if ENABLED(ENDSTOP_NOISE_FILTER)
static esbits_t validated_live_state;
- uint8_t Endstops::endstop_poll_count;
+ // uint8_t Endstops::endstop_poll_count;
static uint8_t endstop_poll_count; // Countdown from threshold for polling
#endifTested as per request with ENDSTOP_NOISE_FILTER enabled and Z_HOME_BUMP_MM set to 5… SAME BEHAVIOUR : it fails to execute a second bump…. Also, a subsequent G30 fails as it does not touch the bed Log Output |
|
@thinkyhead @ejtagle |
|
@lrpirlet Could you try latest bugfix2.0.x with the following endstops.cpp file ? |
|
@thinkyhead : I could be wrong here, but i think the already merged PR #11066 is not enough. If you read endstops::update(), you will notice the endstop state is ONLY read if steppers.axis_is_moving() returns true. That will only return true if the motors are moving, Something that will not happen when the move stops due to an endstop being hit. |
|
Thanks ejtagle, with the new endstops.cpp, it does work as expected… Note that I set back the Z_HOME_BUMP_MM to 2 and it still continue working as expected… I would have closed this entry… do you want me to raise a PR for the duplicated declaration in endstops.h? (see 4 entries above) Log Output |
|
@lrpirlet: Donñt worry, i am raising a PR with both fixes (and an extra one to the Planner...) in a few hours... Thanks for confirming the fix works (i was not sure, as in my case the fix was not required) |
|
Seems we're still having some endstop issues. (e.g., #10986). Please test the latest code, doing multiple |
|
@thinkyhead Log is https://github.com/lrpirlet/Marlin/blob/lrpv2/Marlin/WhatIHaveDone.txt sorry no time for text formating…. I need to drop now… tell me if you want more testing, I'll try my best. |
|
|
|
@lrpirlet has problem gone away in latest bugfix 2.0? |
|
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. |
Description
I decided to switch to the bugfix-2.0.x, and to use the Visual Studio Code + PlatformIO…
I compiled the bugfix2.0.x with my config files (Mega 2560)…
I did reinitialize the EEPROM…
Seems that G28 does NOT execute the "Home 2 Slow" move
Steps to Reproduce
Compile using my config files (see https://github.com/lrpirlet/Marlin/blob/lrpv2/Marlin/Configuration.h and https://github.com/lrpirlet/Marlin/blob/lrpv2/Marlin/Configuration_adv.h)
Expected behavior: [What you expect to happen]
G28 does execute second bump...
Actual behavior: [What actually happens]
G28 does touch the switch once, retract and forget to bump again...
Additional Information
Please find here the debug session…
Note that the printer does NOT bump a second time after and that for X, Y and Z axis…
I may be doing something stupid, sorry if that is the case.
Log Output
The text was updated successfully, but these errors were encountered: