[1.1.x] Updated: Bed leveling more sensitive to noise than prior versions #11626
Comments
|
After M111 S38: |
|
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
changed the title
|
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? |
|
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. |
|
@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? |
|
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... |
|
@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! :) |
|
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) |
|
@AnHardt: Does that mean that probing accuracy dropped by 900% too? |
|
~ up to. |
|
@AnHardt : Your comment is misleading here: We must differenciate between 2 scenarios here:
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. |
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. |
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. |
|
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. |
|
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... |
|
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.
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. |
|
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 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 |
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??? 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 |
|
@lrpirlet : I am aware of those problems. As you said, the lack of rigidity is a common problem between Reprap-like printers. 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! |
Also available with ABL (bilinear). |
|
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
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:
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
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
The text was updated successfully, but these errors were encountered: