[BUG] ADAPTIVE_STEP_SMOOTHING Causes Random ABL Points to Register 1mm+ Lower Then Reality. #18598
Comments
|
Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:
Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine. |
|
@thisiskeithb Alright I did as you asked but I also decided to add my settings in stages. By choosing exactly what I used in 2.0.4.1 I got consistent meshes 3 times in a row so I slowly added in the handful of new settings I had been advised to use and was trying to add. I expected it to be #define FAN_SOFT_PWM but that added without issue. Next I readded Configuration.h Configuration_adv.h At this point I had my first two meshes both show a dip and a different place. I missed the first bit of the log the first time so I only have the M111 S247 detailed terminal from the second but the second one did the same thing so it worked out. I will attach the Terminal Log, Config Zip and a Bed Visualizer Graph of said failure.
|
|
I'll do more test to see if I can narrow down an exact setting but it may be hard as I am continuing to test this build and have just gotten 3 successes in a row after the 2 fails I may have to test more then 3 times each configuration to be sure! *Edit: I will have to run each test until it fails or I hit something like 10 in a row to be sure as there were about 5-6 successful meshes until I had another failure |
|
I just ran about 10+ levels in a row with #define HOMING_FEEDRATE_XY (50*60) still changed and I reset #define SLOWDOWN_DIVISOR 2 To these defaults. It has resulted in a very repeatable mesh. If you need me to dial it down to one of those two setting it will have to wait till tomorrow as I need to catch some sleep but I hope this was enough to get an idea of what is happening. |
|
Whats' happens with such value in slowdown (2) is that logic works, here is code |
|
|
|
@qwewer0 in my opinion endstop is better because it detect faster the trigger. About slowdown divisor what I can see is that with 8 and block_buffer_size to 16 the slowdown code doesn't work but AFAIK such code is used to other purposes, not related to home or probe |
While it wouldn't surprise me that it is the slowdown devisor since that seemed like a really random setting to tweak i had never changed before but I stumbled onto this guide (https://www.reddit.com/r/ender3/comments/e894j7/marlin_20x_guide_for_ender_3_using_skr_mini_e3_v12/) which has a tone of suggested changes id never seen before and adaptive sync and slow divisor where the last ones Id never used before but had tried in 2.0.5.3. I honestly dont know why youd compair it to ENDSTOP_INTERRUPTS_FEATURE @qwewer0 they have nothing to do with one another. From the little they say in the configs the Slowdown Devisor says "If defined the movements slow down when the look ahead buffer is only half full" so if i understand that correctly it relates to slowing the printer down if your buffer becomes to full as to not overload it. Now the suggested reason for changing this is in the merge request #17171 stating that 32bit boards were not even coming close to half fulling there buffers with a setting of 2 though they say they are using 4 not a wopping 8. I and other users are i'm guessing using 8 simply due to the guides on reddit as that same user made a e3 2.0 tutorial as well which is the mainboard The3DE is using in the other issue. |
|
I'm closing this issue since there's already one open for ABL/BLTouch compensation issues: #17262 |
|
Id argue that one has become a mess and doesnt actually identify the issue but I guess this is still linked at minimum. This issue also related the multi probing causing entire failures which is not under discussion at all on the other side so we must keep that in mind as well. |
Do you have a link? It sounds like multiple issues still need to be consolidated. |
|
I will test more in a day or two when I am back home on the multi probing but this is very much a diffrent beast then #17262 but very much related to or the solution for #18526 with us finding that either the adaptive sync settings has confilcts with other parts of the code or a problem with setting the slowdown devisor to high, but the result is random massive dips in an otherwise perfect mesh vs the issue you posted shows poor probing results at best and they dont mention outright failures with multiple probing enabled which is being used as stated in their first post of that issue. |
|
Wow the issue you linked got salty not sure how much headway youll make over there but honestly after reading through the posts it is unrelated @thisiskeithb |
|
Dracrius, I am one of the people in 17262 that is having issues. I am building firmware right now that removes multiple probes and your homing feedrate changes to see if by any chance that those two modifications may help the issue we are having. |
|
@txt4nk I will post my Marlin changes text file so you can compare our other settings as well |
|
That would be great. @thisiskeithb are you okay with Dracrius and myself continuing troubleshooting between ourselves in this closed thread? Any findings worth sharing will be posted in #17262. |
|
Marlin Firmware Changes.txt Edit: Woops first one had Multi Probing listed I dont enable that any more I only did that to try and improve accuracy |
|
alright so I put glass on my ender 3 this morning, and just now changed my firmware. I ran a bed visualizer run in octoprint and it looks pretty decent.. Starting a 160mm X 160mm single layer square right now to test my first layer. I'll post results as soon as its done. |
|
@txt4nk @thisiskeithb I had a second between work to run another test. I enabled ADAPTIVE_STEP_SMOOTHING and then reflashed. After the third bed level I got the dip again I am now going to sanity check that is is just ADAPTIVE_STEP_SMOOTHING by disabling it and resetting SLOWDOWN_DIVISOR to 8. |
|
Also @GMagician the SKR Mini e3 1.2 example config has the block_buffer_size set to 32 not 16. I'll admit I do not know how these settings actually interact with anything as I could sware making the SLOWDOWN_DIVISOR bigger would tell the printer to slow down more often making it trigger at an 8th rather then a half of the buffer size but the original pull request mention increasing it for 32bit boards and at least one user with a very popular tutorial for SKR Mini boards suggest setting it to 8. |
|
My test print failed, left half of the bed was not sticking, whereas the right side looked semi okay. Just this morning I got a great first layer using the z end stop switch and removing ABL completely. However with that being said.. It did not fail as bad as it has in the past. Its either something to do with the settings you provided, or the glass. I'm running another visualizer right now on the glass, and will put my spring steel sheet on right after to see what the difference is between the two via bed visualizer. |
|
Whel.... apparently my glass is warped lol |
|
haha well glass isnt perfect and bed visualizer/ bed probing is very accurate that looks WAY worse then it actually is if you look at the scale we are talking 100ths of a mm differences. I'm on test 6 with ADAPTIVE_STEP_SMOOTHING disabled and SLOWDOWN_DIVISOR set to 8 no issues yet. |
|
This issue may be a duplicate of others, but I’ll reopen it based on the quality of the discussion here. The several open issues related to this may need re-consolidated at some point, but it is hard to tell which are truly duplicates and which are not. |
Dracrius
changed the title
|
I agree with the fact that the delta is super minor, however the corrections being made during the print don't seem to be doing the trick. At this point I do believe that my issue and your issue are two entirely different animals. |
|
If someone could confirm by enabling ADAPTIVE_STEP_SMOOTHING and running half a dozen probes you should see a This can also be seen in the Terminal like so Just take note of a few that match and if one G29 results is -1.### that would be this bug. |
|
I have posted my PR, so that people can pull it down and see whether it fixes their issues. I look forward to hearing feedback on it. |
@AnHardt I really hope this was mostly a joke because otherwise you'd make ALOT of user very very upset. The bltouch is THE most popular(edit) abl unless I'm crazy. It is well made well documented and as far as I can tell the number 1 suggested ABL solution simply based on the amount of material about it in comparison to other methods! It is also more accurate then many other abl options I'd pursonally never install one of those EZABL's. You've got me quite concerned as firstly I'm pretty sure this would effect any ABL that uses Servo pins not just BLtouch and secondly a solution is obviously being made without the need to see their source, so the statment kind of seems uncalled for! |
|
@sjasonsmith I'll happily give it a try but based on these discussions is Adaptive Step Smoothing actual a setting worth using. Unless i misunderstand your conversation it sounds like it "breaks" other things such as
So I'd happily test if this fixed probing but from what i understand Adaptive Smoothing just causes problems in its current state as I can only imagine that kind of behavior is not intended! |
I was thinking the same thing until I installed a precision piezzo system.like this one on my "revisited" A8: https://www.precisionpiezo.co.uk/product-page/precision-piezo-orion-kit Plugged in Zmin, analog electronics only and quite easy to set-up. |
|
Well I didn't mean like the best but the most popular. Especially cause its pretty cheap and damn accurate. |
|
@Dracrius the problem my PR addresses is not caused by adaptive step smoothing, but it is easier to hit with that enabled. Testing with adaptive step smoothing enabled will more effectively verify it is fixed. Step smoothing as written today does consume too much of the CPU. It will limit the time available for passive tasks such as updating the LCD, querying TMC driver status, etc. It might be able to even starve the temperature ISR if you are moving at just the right (or wrong?) speed. |
|
@sjasonsmith Thanks that put the whole discussion in to context a little bit better. Since it should be an improvement either way Ill try and do it shortly. I unfortunately only have one printer and I have been trying to get to printing minis haha. Also could you clarrify what you meant when you said
I currently have Linear Advanced enabled in my configs but hadn't gotten around to trying to configure the k value but the first time I did try and use it earlier in the year, it didn't seem to work and would cause print issues on anything but 0 let alone the test patterns never worked. Was that related and is this still an issue and something I should just disable for now since the SKR mini uses TMC drivers? |
|
@Dracrius Linear Advance results in inconsistent step timing which can cause TMC drivers to turn off. It seems to be worst on the TMC2208, and not every user encounters it. I don't want to further distract this issue by discussing here. There are many open Linear Advance issues related to this. |
|
Apologies Thanks |
|
@sjasonsmith Ran about 6 bed meshes in a row without any major deviation with Pull Request #18637 and Adaptive-Step_Smoothing enabled. So to be clear this is a fix for STM32F1 boards Servo Pin priority more so then a fix for Adaptive_Step_Smoothing? In that Adaptive_Step_Smoothing was just an easy trigger of the existing issue but still contains issue of its own and should most likely be disabled for the time being until it's problems are fixed as well correct? |
|
@Dracrius could you post your testing results as a comment on the pull request as well? |
Yes. If no one else is faster. Will last some days. I want to experiment with an idea - a kind of SLOWDOWN companion, reducing the oversampling before slowing down. If that will last over the weekend i should at least have an idea what the factor in the two line patch above should be and make a minimal PR vor that. |
|
@sjasonsmith Done! I added my confirmation. Did you need terminal read outs as well? I just kinda did it quick since i knew what i was looking for if it failed and didnt track those tests. |
|
Very off topic. Please don't comment!
I'm serious about that. But don't be scared! I'm pretty alone with this opinion. As long i can not convince at least the relevant developers noting bad (or good, depending on the view) will happen (and i'm pretty far from that - they have been bought by free hardware - too cheap). Just me will not touch the probe/endstop code anymore.
I admit, there are peaces of hardware less well documented, but documentation can not replace source-code. But here and now is not the place to discus "The open source religion". :-) BL-Touch is not only the most popular probe but also that having caused by far the most problems and changes in Marlin. (https://github.com/MarlinFirmware/Marlin/issues?q=BL-Touch 316) (https://github.com/MarlinFirmware/Marlin/issues?q=Allen+Key 191) |
|
@AnHardt sorry I wanted to leave it but while i can understand your frustration based on those points your conculsions seem biased. For istance stating the BLtouch by far caused the most problems is reaching at best. Your linked search, results in 14 open issues 316 total, change the search to ABL and you get 28 open issues 768 total and if you change it again to UBL you get 47 open issues 1329 total. From that a truer statement is that ABL code in general has needed the most work since its raise in popularity and unfortunatly a strong part of that is the BLTouch. But to say the BLtouch has also caused the most problems seems more like finger pointing then actual fact. I'm happy to leave it at that as i can understand the frustration and didn't want to push an offtopic, but truely feel just because its meation by name doesn't make it at fault. Conitation does not equal cosation. But thank you for your insite it is always nice to know more about your hardware including its effects on development. |
|
I submitted a change to reduce the target CPU usage from ADAPTIVE_STEP_SMOOTHING to 50%. With that and the Servo priority change I suspect the issues reported here can no longer be reproduced on STM32 boards. I'm not sure whether we should go ahead and close this, or wait for @AnHardt if they are planning a more comprehensive update to ADAPTIVE_STEP_SMOOTHING. |
|
Testing it right now. Will be back with some result. |
|
I ran M48 P50 V3 and M48 P50 S1 V3, each 10 times, with both ADAPTIVE_STEP_SMOOTHING Enabled and Disabled. ADAPTIVE_STEP_SMOOTHING Enabled M48 P50 V3Mean: 0.000000 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0013231 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.000150 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0012661 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.004250 Min: 0.000 Max: 0.007 Range: 0.007 Standard Deviation: 0.0016771 of 50: z: 0.002 mean: 0.0025 sigma: 0.000000 min: 0.002 max: 0.002 range: 0.000 Mean: -0.000250 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0016011 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.001100 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0014281 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.001150 Min: -0.002 Max: 0.000 Range: 0.002 Standard Deviation: 0.0012461 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.001750 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0012501 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.001050 Min: 0.000 Max: 0.005 Range: 0.005 Standard Deviation: 0.0015071 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.005800 Min: -0.008 Max: -0.002 Range: 0.005 Standard Deviation: 0.0016911 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: -0.004450 Min: -0.008 Max: -0.002 Range: 0.005 Standard Deviation: 0.0012541 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 M48 P50 S1 V3Mean: -0.000650 Min: -0.005 Max: 0.005 Range: 0.010 Standard Deviation: 0.0019241 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: -0.002850 Min: -0.005 Max: 0.000 Range: 0.005 Standard Deviation: 0.0017331 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: -0.004300 Min: -0.008 Max: 0.000 Range: 0.008 Standard Deviation: 0.0015031 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: -0.000600 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0016251 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.002550 Min: -0.005 Max: 0.005 Range: 0.010 Standard Deviation: 0.0020911 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: -0.004050 Min: -0.008 Max: 0.000 Range: 0.008 Standard Deviation: 0.0020551 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: -0.005100 Min: -0.008 Max: -0.002 Range: 0.005 Standard Deviation: 0.0016551 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: 0.000400 Min: -0.002 Max: 0.007 Range: 0.010 Standard Deviation: 0.0018951 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.000400 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0016851 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.001900 Min: -0.005 Max: 0.005 Range: 0.010 Standard Deviation: 0.0019721 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 ADAPTIVE_STEP_SMOOTHING Disabled M48 P50 V3Mean: -0.000950 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0014041 of 50: z: 0.002 mean: 0.0025 sigma: 0.000000 min: 0.002 max: 0.002 range: 0.000 Mean: 0.001400 Min: 0.000 Max: 0.005 Range: 0.005 Standard Deviation: 0.0014281 of 50: z: 0.002 mean: 0.0025 sigma: 0.000000 min: 0.002 max: 0.002 range: 0.000 Mean: -0.001850 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0013051 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: -0.001400 Min: -0.005 Max: 0.002 Range: 0.008 Standard Deviation: 0.0016701 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.000050 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0013681 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: 0.000350 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0011191 of 50: z: 0.002 mean: 0.0025 sigma: 0.000000 min: 0.002 max: 0.002 range: 0.000 Mean: -0.000450 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0013871 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.002750 Min: -0.005 Max: 0.000 Range: 0.005 Standard Deviation: 0.0014361 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.000200 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0012081 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.000800 Min: -0.002 Max: 0.002 Range: 0.005 Standard Deviation: 0.0014531 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 M48 P50 S1 V3Mean: -0.002050 Min: -0.005 Max: 0.002 Range: 0.008 Standard Deviation: 0.0019161 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: -0.004650 Min: -0.008 Max: 0.000 Range: 0.008 Standard Deviation: 0.0018031 of 50: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000 Mean: -0.003500 Min: -0.008 Max: 0.000 Range: 0.008 Standard Deviation: 0.0020621 of 50: z: -0.008 mean: -0.0075 sigma: 0.000000 min: -0.008 max: -0.008 range: 0.000 Mean: 0.000200 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0016461 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: 0.001150 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0017471 of 50: z: 0.002 mean: 0.0025 sigma: 0.000000 min: 0.002 max: 0.002 range: 0.000 Mean: -0.001200 Min: -0.005 Max: 0.002 Range: 0.008 Standard Deviation: 0.0016761 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: 0.000650 Min: -0.002 Max: 0.005 Range: 0.007 Standard Deviation: 0.0018581 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.001650 Min: -0.005 Max: 0.002 Range: 0.008 Standard Deviation: 0.0018451 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 Mean: -0.002200 Min: -0.005 Max: 0.005 Range: 0.010 Standard Deviation: 0.0023261 of 50: z: -0.002 mean: -0.0025 sigma: 0.000000 min: -0.002 max: -0.002 range: 0.000 Mean: -0.001450 Min: -0.005 Max: 0.002 Range: 0.008 Standard Deviation: 0.0020061 of 50: z: 0.000 mean: 0.0000 sigma: 0.000000 min: 0.000 max: 0.000 range: 0.000 |
|
@qwewer0 so to ask for a quick summary did this fix the issue so far or not? |
|
@rallegade Yes, it fixed the probe inconsistency when using |
|
@qwewer0 thank you! I'll re-enable it then. |
|
I still disabled it as it gives me better Z-layer accuracy, I ignore the reason. |
|
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. |
Bug Description
Since updating to Marlin 2.0.5.3 from 2.0.4.1 I noticed my BLTouch v3 was reporting random major dips in my bed. I am using an Ender 3 Pro with a SKR Mini e3 1.2 mainboard. I decided to try and tune my BlTouch settings to improve reliability BUT this lead me down a hole that only resulted in even more issues. I'll admit I went a bit crazy trying to figure this out and lost track of some things I tried but what I have verified should be enough for someone to help me track it down.
My Configurations
Required: Please include a ZIP file containing your
Configuration.handConfiguration_adv.hfiles.Marlin 2.0.5.3 Configs.zip
Steps to Reproduce
I setup my BLtouch identically in both firmware versions. I just verified by reinstalling my 2.0.4.1 build that with it and Octoprints Bed Level Visualizer report a VERY consistent bed level mesh!
Flashing Marlin 2.0.5.3 results in a fairly repeatable 1 in 3 bed level test result in random massive dips in the mesh
Enabling #define MULTIPLE_PROBING 2 changes the result from a bad mesh to an entire printer fail with an M112 Restart Printer Message basically the same 2 out of 3 times. Strangely it fails mid air on a random position. some times its in the first 3 some times its one of the last 3 but it will prob once in said position then drop the pin to prob again but immediately fail and begin to blink without lowering to the bed.
Expected behavior: Consistent probing like 2.0.4.1 without the need for Multi Probing and or successful multi probing
Actual behavior: Dips in mesh or complete failures
The text was updated successfully, but these errors were encountered: