[1.1.x] Updated: Bed leveling more sensitive to noise than prior versions

[marcio-ao]

Description

Under 1.1.9, we are finding that probing is failing on our earlier generation machines. The nozzle only drops a few centimeters before a false probe point is returned. Flashing 1.1.8 resolves the problem.

I tried a "G29 V4", but no useful diagnostics was printed to the screen:

echo:Marlin 1.1.9

echo: Last Updated: 2018-08-01 | Author: (Aleph Objects Inc., LulzBot Git Repository)
echo:Compiled: Aug 23 2018
echo: Free Memory: 3248  PlannerBufferBytes: 1232
Error:EEPROM CRC mismatch - (stored) 505 != 59739 (calculated)!
echo:Hardcoded Default Settings Loaded
X:-3.00 Y:190.00 Z:159.00 E:0.00 Count X:-302 Y:19095 Z:254400
ok P15 B4
G29 Auto Bed Leveling
Bed X: -3.000 Y: 161.000 Z: 147.728
Bed X: -3.000 Y: -7.000 Z: 152.567
Bed X: 161.000 Y: -7.000 Z: 149.408
Bed X: 161.000 Y: 161.000 Z: 140.147
Eqn coefficients: a: -0.03274491 b: -0.04196742 d: 153.28105163
Mean of sampled points: 147.46270751

Bed Height Topography:
   +--- BACK --+
   |           |
 L |    (+)    | R
 E |           | I
 F | (-) N (+) | G
 T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
 +0.26543 -7.31595
 +5.10478 +1.94579

Corrected Bed Height vs. Bed Topology:
 +2.21408 +0.00000
 +0.01665 +2.22495

Bed Level Correction Matrix:
+0.999464 +0.000000 -0.032727 
-0.001372 +0.999121 -0.041886 
+0.032699 +0.041908 +0.998586 
X:156.07 Y:154.60 Z:7.84 E:0.00 Count X:15707 Y:15574 Z:6572
ok P15 B4

Somewhat at a loss as to what might be happening here.

Under bugfix-2.0.x, the symptoms are different. The printer prints "Error:Printer halted. kill() called!" immediately after G28 with no explanation on the serial console.

Steps to Reproduce

1. Run G28
2. Run G29

Expected behavior: The head will lower itself all the way to the probe washers.

Actual behavior: [1.1.9] The head only drops a few centimeters before continuing to the next probe point. [2.0.x] The printer halts on G28

Additional Information

The following zip file contains the Configuration.h and Configuration_adv.h got 1.1.9, as well as a movie showing the issue.

probe_error_issue_report.zip

[marcio-ao]

After M111 S38:

>>> G28
Machine Type: Cartesian
Probe: FIX_MOUNTED_PROBE
Probe Offset X:0 Y:0 Z:-1.37 (Aligned With & Below Nozzle)
Auto Bed Leveling: LINEAR (disabled)

  current_position=(0.00, 0.00, 0.00) : setup_for_endstop_or_probe_move
> endstops.enable(true)
>>> homeaxis(Z)
Home 1 Fast:
>>> do_homing_move(Z, 241.50, [8.00])
  current_position=(0.00, 0.00, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Move Away:
>>> do_homing_move(Z, -2.00, [8.00])
  current_position=(0.00, 0.00, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Home 2 Slow:
>>> do_homing_move(Z, 4.00, 2.00)
  current_position=(0.00, 0.00, 0.00) : sync_plan_position
<<< do_homing_move(Z)
>>> set_axis_is_at_home(Z)
For Z axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = -2.00
 soft_endstop_max = 159.00
> home_offset[Z] = 0.00
  current_position=(0.00, 0.00, 159.00) : 
<<< set_axis_is_at_home(Z)
  current_position=(0.00, 0.00, 159.00) : sync_plan_position
  current_position=(0.00, 0.00, 159.00) : > AFTER set_axis_is_at_home
<<< homeaxis(Z)
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, -247.50, [30.00])
  current_position=(0.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(X)
Move Away:
>>> do_homing_move(X, 5.00, [30.00])
  current_position=(0.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(X)
Home 2 Slow:
>>> do_homing_move(X, -10.00, 15.00)
  current_position=(0.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(X)
>>> set_axis_is_at_home(X)
For X axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = -3.00
 soft_endstop_max = 162.00
> home_offset[X] = 0.00
  current_position=(-3.00, 0.00, 159.00) : 
<<< set_axis_is_at_home(X)
  current_position=(-3.00, 0.00, 159.00) : sync_plan_position
  current_position=(-3.00, 0.00, 159.00) : > AFTER set_axis_is_at_home
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, 295.50, [30.00])
  current_position=(-3.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(Y)
Move Away:
>>> do_homing_move(Y, -5.00, [30.00])
  current_position=(-3.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(Y)
Home 2 Slow:
>>> do_homing_move(Y, 10.00, 15.00)
  current_position=(-3.00, 0.00, 159.00) : sync_plan_position
<<< do_homing_move(Y)
>>> set_axis_is_at_home(Y)
For Y axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = -7.00
 soft_endstop_max = 190.00
> home_offset[Y] = 0.00
  current_position=(-3.00, 190.00, 159.00) : 
<<< set_axis_is_at_home(Y)
  current_position=(-3.00, 190.00, 159.00) : sync_plan_position
  current_position=(-3.00, 190.00, 159.00) : > AFTER set_axis_is_at_home
<<< homeaxis(Y)
  current_position=(-3.00, 190.00, 159.00) : sync_plan_position
  current_position=(-3.00, 190.00, 159.00) : clean_up_after_endstop_or_probe_move
X:-3.00 Y:190.00 Z:159.00 E:0.00 Count X:-302 Y:19095 Z:254400
<<< G28
ok P15 B4

>>> G29
Machine Type: Cartesian
Probe: FIX_MOUNTED_PROBE
Probe Offset X:0 Y:0 Z:-1.37 (Aligned With & Below Nozzle)
Auto Bed Leveling: LINEAR (disabled)

  current_position=(-3.00, 190.00, 159.00) : set_probe_deployed
deploy: 1
do_probe_raise(5.00)
>>> do_blocking_move_to(-3.00, 190.00, 159.00)
<<< do_blocking_move_to
  current_position=(-3.00, 190.00, 159.00) : setup_for_endstop_or_probe_move
>>> probe_pt(-3.00, 161.00, raise, 0, probe_relative)
  current_position=(-3.00, 190.00, 159.00) : 
>>> do_blocking_move_to(-3.00, 161.00, 159.00)
<<< do_blocking_move_to
  current_position=(-3.00, 161.00, 159.00) : set_probe_deployed
deploy: 1
  current_position=(-3.00, 161.00, 159.00) : >>> run_z_probe
  current_position=(-3.00, 161.00, 159.00) : >>> do_probe_move
>>> do_blocking_move_to(-3.00, 161.00, -2.63)
<<< do_blocking_move_to
  current_position=(-3.00, 161.00, 158.50) : sync_plan_position
  current_position=(-3.00, 161.00, 158.50) : <<< do_probe_move
1st Probe Z:158.50
>>> do_blocking_move_to(-3.00, 161.00, 163.50)
<<< do_blocking_move_to
  current_position=(-3.00, 161.00, 163.50) : >>> do_probe_move
>>> do_blocking_move_to(-3.00, 161.00, -2.63)
<<< do_blocking_move_to
  current_position=(-3.00, 161.00, 159.03) : sync_plan_position
  current_position=(-3.00, 161.00, 159.03) : <<< do_probe_move
2nd Probe Z:159.03 Discrepancy:-0.53
  current_position=(-3.00, 161.00, 159.03) : <<< run_z_probe
>>> do_blocking_move_to(-3.00, 161.00, 164.03)
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(-3.00, -7.00, raise, 0, probe_relative)
  current_position=(-3.00, 161.00, 164.03) : 
>>> do_blocking_move_to(-3.00, -7.00, 164.03)
<<< do_blocking_move_to
  current_position=(-3.00, -7.00, 164.03) : set_probe_deployed
deploy: 1
  current_position=(-3.00, -7.00, 164.03) : >>> run_z_probe
  current_position=(-3.00, -7.00, 164.03) : >>> do_probe_move
>>> do_blocking_move_to(-3.00, -7.00, -2.63)
<<< do_blocking_move_to
  current_position=(-3.00, -7.00, 148.36) : sync_plan_position
  current_position=(-3.00, -7.00, 148.36) : <<< do_probe_move
1st Probe Z:148.36
>>> do_blocking_move_to(-3.00, -7.00, 153.36)
<<< do_blocking_move_to
  current_position=(-3.00, -7.00, 153.36) : >>> do_probe_move
>>> do_blocking_move_to(-3.00, -7.00, -2.63)
<<< do_blocking_move_to
  current_position=(-3.00, -7.00, 149.75) : sync_plan_position
  current_position=(-3.00, -7.00, 149.75) : <<< do_probe_move
2nd Probe Z:149.75 Discrepancy:-1.39
  current_position=(-3.00, -7.00, 149.75) : <<< run_z_probe
>>> do_blocking_move_to(-3.00, -7.00, 154.75)
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(161.00, -7.00, raise, 0, probe_relative)
  current_position=(-3.00, -7.00, 154.75) : 
>>> do_blocking_move_to(161.00, -7.00, 154.75)
<<< do_blocking_move_to
  current_position=(161.00, -7.00, 154.75) : set_probe_deployed
deploy: 1
  current_position=(161.00, -7.00, 154.75) : >>> run_z_probe
  current_position=(161.00, -7.00, 154.75) : >>> do_probe_move
>>> do_blocking_move_to(161.00, -7.00, -2.63)
<<< do_blocking_move_to
  current_position=(161.00, -7.00, 125.51) : sync_plan_position
  current_position=(161.00, -7.00, 125.51) : <<< do_probe_move
1st Probe Z:125.51
>>> do_blocking_move_to(161.00, -7.00, 130.52)
<<< do_blocking_move_to
  current_position=(161.00, -7.00, 130.52) : >>> do_probe_move
>>> do_blocking_move_to(161.00, -7.00, -2.63)
<<< do_blocking_move_to
  current_position=(161.00, -7.00, 129.14) : sync_plan_position
  current_position=(161.00, -7.00, 129.14) : <<< do_probe_move
2nd Probe Z:129.14 Discrepancy:-3.63
  current_position=(161.00, -7.00, 129.14) : <<< run_z_probe
>>> do_blocking_move_to(161.00, -7.00, 134.14)
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(161.00, 161.00, raise, 0, probe_relative)
  current_position=(161.00, -7.00, 134.14) : 
>>> do_blocking_move_to(161.00, 161.00, 134.14)
<<< do_blocking_move_to
  current_position=(161.00, 161.00, 134.14) : set_probe_deployed
deploy: 1
  current_position=(161.00, 161.00, 134.14) : >>> run_z_probe
  current_position=(161.00, 161.00, 134.14) : >>> do_probe_move
>>> do_blocking_move_to(161.00, 161.00, -2.63)
<<< do_blocking_move_to
  current_position=(161.00, 161.00, 85.75) : sync_plan_position
  current_position=(161.00, 161.00, 85.75) : <<< do_probe_move
1st Probe Z:85.75
>>> do_blocking_move_to(161.00, 161.00, 90.75)
<<< do_blocking_move_to
  current_position=(161.00, 161.00, 90.75) : >>> do_probe_move
>>> do_blocking_move_to(161.00, 161.00, -2.63)
<<< do_blocking_move_to
  current_position=(161.00, 161.00, 89.41) : sync_plan_position
  current_position=(161.00, 161.00, 89.41) : <<< do_probe_move
2nd Probe Z:89.41 Discrepancy:-3.67
  current_position=(161.00, 161.00, 89.41) : <<< run_z_probe
>>> do_blocking_move_to(161.00, 161.00, 94.41)
<<< do_blocking_move_to
<<< probe_pt
  current_position=(161.00, 161.00, 94.41) : set_probe_deployed
deploy: 0
>>> do_blocking_move_to(161.00, 161.00, 94.41)
<<< do_blocking_move_to
  current_position=(161.00, 161.00, 94.41) : > probing complete
  current_position=(161.00, 161.00, 94.41) : G29 uncorrected XYZ
Z from Probe:7.84  Matrix:132.34  Discrepancy:-124.50
  current_position=(129.27, 149.47, 7.84) : G29 corrected XYZ
  current_position=(129.27, 149.47, 7.84) : clean_up_after_endstop_or_probe_move
<<< G29
  current_position=(129.27, 149.47, 7.84) : sync_plan_position
X:129.27 Y:149.47 Z:7.84 E:0.00 Count X:12801 Y:15105 Z:-39972
ok P15 B4

[marcio-ao]

Okay, some progress here. Enabling "#define ENDSTOP_NOISE_FILTER" allows the printer to probe. I can only suspect that some recent changes have made Marlin more sensitive to noise and now it is picking up on transients it was not picking up on before. Does this explanation make any sense?

My concern is that the documentation says that ENDSTOP_NOISE_FILTER can add an error of up to +/-0.2mm ... this would totally wreck our auto-leveling. I assume this filter is a time-average of some sort, is there anyway to tune this so it has less of a penalty in accuracy?

[marcio-ao]

Okay, looks like this is how to tune the filter in "endstops.cpp" (I added LULZBOT_ENDSTOP_NOISE_FILTER_SPREAD) -- how come this isn't a configurable option? According to the comment, it looks like the old Marlin used a value of 2, but now it got bumped up to 7 and is disabled by default?

Why was this behavior changed without warning, when it can cause printers to suddenly stop working?

  #if ENABLED(ENDSTOP_NOISE_FILTER)
    /**
     * Filtering out noise on endstops requires a delayed decision. Let's assume, due to noise,
     * that 50% of endstop signal samples are good and 50% are bad (assuming normal distribution
     * of random noise). Then the first sample has a 50% chance to be good or bad. The 2nd sample
     * also has a 50% chance to be good or bad. The chances of 2 samples both being bad becomes
     * 50% of 50%, or 25%. That was the previous implementation of Marlin endstop handling. It
     * reduces chances of bad readings in half, at the cost of 1 extra sample period, but chances
     * still exist. The only way to reduce them further is to increase the number of samples.
     * To reduce the chance to 1% (1/128th) requires 7 samples (adding 7ms of delay).
     */
    static esbits_t old_live_state;
    if (old_live_state != live_state) {
      endstop_poll_count = LULZBOT_ENDSTOP_NOISE_FILTER_SPREAD;
      old_live_state = live_state;
    }
    else if (endstop_poll_count && !--endstop_poll_count)
      validated_live_state = live_state;

    if (!abort_enabled()) return;

  #endif

[ejtagle]

it was changed because the previous behaviour was also wrong and also induced reduced accuracy without even telling the user and that is worse than forcong users / manufacturers to read and actually understand the issue. It was decided that is better to force fixing the hardware rather than not telling the user a workaround was unnecesarily reducing accuracy There is no tuning of the algorithm as noise is not deterministic: the amount of samples to wait before accepting a value cant be determined a priori (on both old and new algorithms). And the exact amount of samples is what determines the error.

[marcio-ao]

@ejtagle: Alright. Fair enough. The thing is we have previous generation printers out in the field which we cannot modify. The older FW was working fine for us and I would like to get as close to that as possible. It looks like setting the endstop_poll_count to 2 will most closely match the old FW behavior. Is this correct?

[ejtagle]

Yes, it is correct. But even using the default value is as correct as setting it to 2. Don´t expect a miracle here... Software noise filtering will ALWAYS be a mitigation, due to the Nyquist-Shannon sampling theorem and aliasing issues...

[marcio-ao]

@etagle: Thanks for clarifying! I understand that theoretically 7 might be more reliable, but so long as it works as good (or as bad) as our older FW did on our older printers that is all we need for now and it seems like 2 is the choice for backwards compatibility.

If our customers want a more reliable printer, they can always buy our latest generation printer which doesn't need this kludge! :)

[AnHardt]

An other difference to before, where the endstops was tested once per step (up to 10KHz), is the new way of testing them in the heater ISR @ ~1KHz now. Depending on you feedrate while testing and steps/mm at Z, the decrease in accuracy may be 900% and more. (Additionally to the problem you talked about above)

[marcio-ao]

@AnHardt: Does that mean that probing accuracy dropped by 900% too?

[AnHardt]

~ up to. You have to calculate how many steps you are doing in in 2 (7) ms and compare that to the two steps from before. EDIT At the moment i have no clue what that means for repeatability - what is much more important.

[ejtagle]

@AnHardt : Your comment is misleading here: We must differenciate between 2 scenarios here:

If using Endstop Polling, or noise filtering, that results in a 1khz endstop poll period. The gain or lose of accuracy is questionable, because there is no mechanical switch with no hysteresis. I have shown proofs of what i say, and i don´t intend to pull the lengthly thread where we discussed it,

If NOT using noise filtering, and using ENDSTOPS INTERRUPTs, then there is even better accuracy than the previous implementation! ... The reason: Previously it was IMPOSSIBLE to disable the noise filtering algorithm, and that caused a 2 sample delay on detection of endstop switch. And the previous endstop interrupt feature was not checking the endstops at all. It was just flagging that a check should be done in the next step ISR... And 2 consecutive samples with the same value were required, so the precision loss was INTENTIONALLY CAUSED by the software implementation.

I will not pursue convincing anyone of the above facts. The github log is there for anyone to analyze and make his/her own conclusions. The only thing that i can say is that i devoted too much personal time to fix a lot of issues, including endstop code, stepper and planner, helped a lot to clean up and advance Marlin ... (and there are still pending things, LA is one of them)

Please, let´s avoid destructive criticism: It does no good to Marlin. If there is a suggestion on an improvement, let´s discuss it, but avoid comments such "this used to work better previously", because that it worked better FOR YOU does not mean it worked better FOR ALL.

[AnHardt]

there is no mechanical switch with no hysteresis

That's pretty irrelevant because we are always testing the same flank of the signal. Except in the try for a auto backlash calibration.

Please don't try to explain the previous endstop code to me. The 'endstop interrupt feature' was my baby. The intention there was to preserve a well working (low frequency off issues) long time tested endstop code, but speed the system up by only testing the endstops when it matters, instead of all the time. Exactness was (as before) two steps after the switch got stable (for 2 consecutive readings). Always two steps, regardless of, if the interrupts are used or not. But what we are looking for is not exactness, but repeatability. And repeatability does suffer when the tests are done in a jittering (jittering enough to make the ADC readings fail) timer based interrupt instead of a by step based A, different from before, exactness results in a different offset only one time, low repeatability results in getting a different offset all the time.

Your work is great most of the time, but the new endstop code can't convince me. I highly appreciate your work and time you invested over the last few month into Marlin. (I do know what that means)

I do see a sudden increase in endstop related issues after the change. Every change causes them until the users get used to it and have some experience to use the new options. But here i have the feeling some (like this) will remain. I'm far from convinced it's now working better than before FOR ALL.

ME is neither printing, nor testing, nor coding these days. Far from home, without a printer, with just a tiny laptop, i'm still in rehab from a heart insufficiency. Just reading, analysing, thinking and occasionally rising my voice. Hopefully i can return to home in autumn and can work on my Marlin to do list, probably long enough for the next few years.

[marcio-ao]

If NOT using noise filtering, and using ENDSTOPS INTERRUPTs, then there is even better accuracy than the previous implementation!

Some of our older printers have boards that can't do interrupts on the endstop lines. I believe our current boards can take advantage of this, however. There was a time in which ENDSTOPS_INTERRUPTS would not work with sensorless homing, so I had turned it off, but perhaps this has changed by now. On Monday I'll turn it on again and experiment with it.

[marcio-ao]

@ejtagle , @AnHardt : Thank you for all the clarification and help. Feel free to continue the discussion, but I'll close this ticket since my original issue on our older printers was resolved by enabling ENDSTOP_NOISE_FILTER.

[AnHardt]

Making the filter adjustable would be a first step into the right direction, to make the 5ms pulses of some BL-Touch probes make work reliable again.

[ejtagle]

BL-Touch is the perfect example of something that should improve when ENDSTOP-INTERRUPTS are enabled and ENDSTOPS_FILTERING is disabled.

@AnHardt : Do not take it personal. It would be completely unfair to say the previous endstops code was the cleanest solution, as it wasn´t. It was full of "workarounds" for unexplained and undocumented behaviour that noone seemed to understand (i refer specifically to the interactions between the stepper/planner/endstop code).

I still remember the call to the endstop poll routine WAS PRESENT in the temperature ISR. And also, it was present on the stepper ISR. There was also some "magic" counters that forced polling on the temperature ISR and on the stepper ISR "just in case"... And that were workarounds for other hidden race conditions in the code itself.

Eventually, at some point that would bite. Sooner or later that could was screaming to be cleaned up.

I just can´t see how it could be worse, when using interrupts, as now endstops are being polled as soon as the endstop is triggered, and the polling is not delayed, as it previously was.

Removing the endstop polling from the stepper allowed to improve step position in time (there is a beautiful graph done by @p3p regarding this, the adaptive step smoothing and how it improves step positioning...)

The code was just reordered, simplified quite a bit, and we fixed some strange problems on the dual endstop case that previously did not work at all...

[AnHardt]

BL-Touch's pulse was the reason for the workaround to add the poll in the temperature interrupt. When moved/probed stupidly slow and/or with very low steps/mm the pulse was over before the second step. But this was, as far i can remember, active only when there was a BL-Touch. Regulars here do know about my opinion about this shitty probes. But Roxy accepted some of them from the manufacturer for integrating them into Marlin, instead of rejecting support for a wannabe patented product. For me that was a major error. Now we have a bunch of wannabe BL-Touch probes where non is the same as the other, only because the design is not open. With proper hardware the interrupt solution is by far the best. If you can't have the interrupts but, have a moderate amount of noise and bouncing (for example with driven outputs - not relying on the internal pullups), or if you can have the interrupts but have a noisy signal, i do see a regression what could be worked around by a adjustable filter. I don't doubt the timing for the stepper interrupt is better now, but seemingly on cost of the temperature interrupt. We still have to see if the new compromise is well balanced. 'adaptive step smoothing' is great for the 32bitters, but i'm scared by the much higher average load to the system by the stepper interrupt. We always had issues with stuttering on short segment sequences where the buffer runs dry. The amount of that issues seems to have increased.

The code was just reordered, simplified quite a bit, and we fixed some strange problems on the dual endstop case that previously did not work at all...

For me it's more looking like a change in paradigms - what is not bad - in principal.

You are right. I'm a bit frustrated again. I should close my eyes and be quite. But that will not change the reality. Moaning? Maybe.

[ejtagle]

Regarding the noise issue. the current filter is as good as the previous implementation. I would not be worried about it.

On the adaptive step smoothing (AMASS), there is nothing preventing decreasing the minimum stepper frequency, or even disabling it if queue starts to become empty. On 8bit micros, the minimum enforced stepper frequency is 1khz when using that AMASS algorithm. And in fact, the AMASS algo is disabled by default... The problem of small movements is mostly caused by UBL, that is breaking long movements into smaller ones. It would be more sensible to try to avoid those breaks. For me, UBL/ABL is just a "hack" in the sense that having a properly leveled bed with proper mechanical design is way better. And having a perfectly flat bed surface should be very easy to achieve...

[thinkyhead]

The increase in endstop and probe issues is concerning, but not a total show-stopper. I agree that if noise is on the line then it needs to be fixed in hardware first, and users should prefer N-C switches for that reason. But, hall switches and inductive/capacitive probes are all N-O, so for those we're stuck with potential induction issues.

I think it's a Good Thing™ for the most part that the planner/stepper/endstops code has been overhauled to deal with the issues that Éduardo highlights. I agree that the 7 samples is probably overkill, and if 2 works for most cases then maybe that should be the default. That combined with enabling the noise filter basically emulates Marlin 1.1.8 behavior. I'd suggest not adding a new setting, but just allowing ENDSTOP_NOISE_FILTER to be set to an integer, or if not given a value then either 2 (old-style) or 7 (new-style) should be applied.

[lrpirlet]

@ejtagle

For me, UBL/ABL is just a "hack" in the sense that having a properly leveled bed with proper mechanical design is way better. And having a perfectly flat bed surface should be very easy to achieve…

I am not sure I can accept that… Please consider (too) many printer design where the axe ( X axis in the original Prusa I3) is NOT rigid enough… The extruder is hanging on ONE side inducing a torque… The net result when moving allong the X axis, is a CURVE (not a strait line)… So the distance to a perfectly flat bed is a VARIABLE… We have what I call a geometry issue.

A simple experiment is to press (lightly) with your finger where the filament enters the extruder. I observe a deviation, more than enough to prevent correct adhesion… In fact, measuring Z with a switch placed between the tip and the bed does flex the X axis too (that is ok cause it is mostly repeatable)… In the same vein, what happens when the tension on the filament is NOT constant??? To the best of my experiments, NONE of the REPRAP device would pass that test...

ABL is certainly NOT a correct answer to the above flexing issue… Mesh levelling is a good approach to minimize the bad effects produced by this X axis flexing… And UBL is even better because it introduced the M26 command that allows to adjust the mesh in REAL printing situation…

No it is NOT SIMPLE to "repair" such a behavior on an existing printer… NO it is not simple to design a device that is rigid AND light enough to print with a "reasonable" speed… As I perceive it, software MUST (try to) support UNPERFECT hardware.

Obviously, Marlin has been able to cope and I am most grateful to all the developers

[ejtagle]

@lrpirlet : I am aware of those problems. As you said, the lack of rigidity is a common problem between Reprap-like printers. You are giving the arguments, not me: The filament pressure influences (due to the lack of structural rigidity) the height of the nozzle, so that ends depending on printing speed, print head acceleration, Linear advance, etc, etc - Obviously this is not an ideal scenario Of course the effects can be mitigated (but not solved completely) by software workarounds... But all those workarounds require processing power, and that is something the AVR simply does not have - So we have a limitation here! I am using a Prusa i3 clone with laser cut steel frame: It was very cheap and it is extremely rigid. Perhaps that is the reason i have never used ABL/UBL My best advice is to upgrade your controller to a 32bit board: That solves a lot of the problems related to shuttering, and due to the extra available processing power, will allow to perform ABL/UBL if you need it without any problems - I am using myself an Arduino Due based controller, and it works beautifully! - But any 32bit board will have no issues.

There is simply a point where the AVR (atmega) processor is just not enough for the amount of features users want enabled at the same time - Either fix hardware or use a more powerful controller!

[thinkyhead]

UBL is even better because it introduced the M26 command

Also available with ABL (bilinear).

[github-actions[bot]]

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.