[BUG] (UBL 3-point mesh leveling 'broken') #24665
Comments
|
It would be helpful to know the values of the points it probed. It kind of looks like one of those points was way off and as a result it took a 'correct' mesh and tilted it funny to fit the points that were probed. |
|
Sorry for my ignorance, are these tilting point values returned during probing, or do you have to query for them with G-code? I can check later today. I did get 2.1-bugfix compiled, but haven't had a chance to flash and test. If it needs an eeprom init, rebuilding the grid takes a while. Is there no way to 'save' the grid and restore via the console? |
|
Did some more testing. Figured out G29 J V4 to get the probed data. Here's the console output: It's detecting +0.26 compared to -0.64. I tried running G29 J again immediately after this: +0.01 to +0.89. Almost exactly the same absolute difference as the first time. However the mesh is 'normal'. It's the same reletive 'shape', just offset up a little. At this point I downloaded, configured, and compiled 2.0.9.5. Exactly the same thing as above. I then went back to 2.0.9.2 (that was previously ok) and got this: This time, Z was detected as +0.20 to + 0.07. A 0.13mm difference is more what I would have expected. The resulting mesh is the 'same', just offset up a bit. I'm just going to stick with 2.0.9.2 for now. |
|
I also have problems with UBL coming from 2.0.9.2 to 2.1.1. And I think it's the same issue. I probed the bed muliple times and saved it to EEPROM. But when validating it with G26 (of course G29 J before) the mesh seems totally tilted! This happened on two different printers and that's why I looked into here. |
|
Are there any updates concerning this bug? Is it already fixed in the bugfix branch? |
|
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days. |
|
I tested version 2.1.2 and the issue didn't occur so far. So it seems to be fixed with Marlin 2.1.2 and respectively with the issue #24622. |
|
I just tried 2.1.2, and it's having the same issue. 2.1.2 console output: Reflashed 2.0.9.2 without changing anything hardware wise on the printer. 2.0.9.2 output: (Didn't get the pre-tilt mesh, but it was basically the same. Corrected Z values are way less with simply a firmware flash.) Since it's only me having the problem now, it must be something in my configs. Aero4, which printer do you have 2.1.2 running on? Can you post your config? |
|
To be honest I didn't probe the bed twice and compared the values, I just probed once and there were no issues while printing... If you want I can run the same code as you did for testing. I am running Marlin 2.1.2 on a custom printer based on the Velleman K8200 with a "3DTouch" probe. I always track the differences I modify in the config files which are the following: |
|
Hello. Thanks for the config difference from default. What do you mean when you say you don't probe the bed twice? I do use "#define MULTIPLE_PROBING 2" and it looks like you don't. The other main difference I see is that I use "#define ENABLE_LEVELING_AFTER_G28" whereas you use "#define RESTORE_LEVELING_AFTER_G28". I don't fully understand one vs the other. I've got a 7x7 grid and you use 6x6, but my bed is 350mm compared to 200. What does your start gcode look like? |
|
Sorry for the late reply, you're welcome. I only probed the bed once and used these values for the bed grid and didn't repeat that. To be honest I also don't fully understand every single setting I used. I took most of the probing settings from tutorials and they were proved to be working so far. This is my starting GCode: |
|
Can you run the following G code right after the printers been powered up and post the console output after it's ran? It won't print anything, but does need to move the head around. |
|
Sure, this is my console output when sending the commands you stated: It looks quite right I guess? |
|
Thanks. Yes, it looks very normal. Not sure why mine ends up applying a 2mm tilt. I suppose I can try recompiling with absolute minimal config changes made. Like only set what's critical for stepper movement. Axis direction, z-probe as end stop, etc. I'll close the bug for now as I seem to be the only one having the issue. If I can find out what's causing it I'll re-open. Thanks again for your help. |
|
The bug re-occured! After determining the tilt of the mesh with G29 J V4 the first time, I get: the sencond time the third time: So the values are completely off! After every G29 J V4 I get completely different values in the range of multiple mm! I don't understand why this doesn't get more attention... UBL is basically unusable and the printhead or the heatbed can be destroyed! @titanrw can you re-open the issue? |
|
Not that I can help, but can you show the output of G29 J V4? The corrected Z values seem to be off. For example: Tilting point 2/3 corrected Z shows -0.7: Previous firmware before I noticed the bug have all corrected Z under absolute value of 0.1: I did manage to narrow it down to a specific version of marlin. I was running 2.0.9.2 as mentioned. I tried 2.0.9.3, and it was OK. Compiled and flashed 2.0.9.4, and it has this problem. Something changed between 2.0.9.3 and 9.4. I did look through the commits between 9.3 and 9.4, but I'm not much of a coder, especially in C. I also looked at the code, trying to figure out how the corrected Z could get so 'whacked' in 9.4, but didn't really get anywhere. I did see there were some debugging options around function get_z_correction() in ubl.h, but I couldn't figure out how to enable them. I'm currently running my machine on 2.0.9.3 as it's the latest version that doesn't seem affected by this. |
|
I reverted to Version 2.0.9 and for the exact same commands and config files the mesh values are for the first G29 J V4: And the second: Which are obviously way more covering... I saw that G29 J V4 with version 2.1.2 shows Corrected_Z values in the range of 1mm: and with version 2.0.9 in the range of 0.01mm: So very likely there the problem is located... |
|
Bug re-opened. Which version of 2.0.9 specifically? I bet 9.3 will work, and 9.4 will not. I did damage the build plate before realizing what was going on. Now I know to manually do a G29 J V4 (check probed values), and double check G29 T tilted mesh, to verify before printing. |
It's even 2.0.9.2... Yes my build plate also have one or two deep scratches because of this bug. |
|
Only if you want to verify that 9.3 -> 9.4 is where it broke. I ran 9.2 for a long time, so if it's working, why mess with it. Setting the configs are a bit of a pain. There's no pre-made config for my printer, with my exact mainboard. I find its fastest to use notepad++ with the compare plugin. Open the old_config and new_config, then run the compare. It'll show which lines are different, and you can 'move over' config options you need from the old to new files. Still takes about half an hour, but at least the bed mesh seems to persist. |
|
Good to know which version to avoid... I tracked my changes compared to stock and have to adapt about 80 settings, which as you said needs about half an hour. Yes I will also stick to the old version, the new features are unable to compensate this huge bug. Why are we the only two with that issues (or care about it)? Shouldn't that concern everyone with version >2.0.9.3 and having UBL enabled? |
|
I don't know why we're the only ones to notice. From what I can tell, it would affect anyone on 2.0.9.4 and later, using UBL, and tilting the mesh with G29 J. Maybe it's also tied to a specific config option we're both using. Other than #enable UBL that is. Haven't figured that one out yet. If my printer had the dual Z screws mechanically 'tied' together, then I wouldn't both with G29 J, and this wouldn't affect me. But I figured that since I'm not going to get them perfectly set every single time I power on the printer, it could compensate. |
snip I just noticed you change the mainboard. Maybe the particular mainboard used has something to do with whether this bug manifests or not. As mentioned in the first post, my printer is driven by a BigTreeTech SKR Mini E3 v2.0. What mainboard did you change from, and which one did you switch TO? |
|
I just swapped the board. So my previous BTT SKR 1.4 was damaged and I bought another one to replace. |
|
I tested the latest -bugfix from today (2023-01-16). The issue still occurs: |
|
This is a long shot, but try running a G29P5C so that the grid is centered before using G29J. |
Here's including G29 P5C before a G29 J: Corrected_Z is still 'wrong' when tilting. This is -bugfix from Jan 16. Flashing back to 2.0.9.3 now... |
|
The "Corrected_Z" value for the second point seems off. I had a cursory look at the diff for G29.ccp between 2.0.9.3 and the current version. A few things were changed but nothing stood out. Numerical algorithms can be tricky and certain ways of performing rotations are more numerically stable than others. When I have the time/motivation I'll have a closer look at what they're doing. In the meantime, could you try a G29J4 or G29J5? If your bed isn't the most even then a 4x4, 5x5, or even 3x3 sample of the bed will yield a much better approximation of the bed's planar component than the default three point sample. Incidentally, it may be beneficial if UBL's G29 aligned the planar component of the mesh itself with the printer's XY axis at the time that the mesh is sampled and/or as an option to G29J: #25262 (comment) This could probably be implemented reusing some code from G29J, provided that G29J works in the first place. |
The problem starts to occur between 2.0.9.3 and 9.4. So any changes past 9.4 shouldn't apply to this problem.
I'll try a > 3 point tilt, both on 9.3 and 9.4 and compare. Realistically I'm only looking for any possible left-right (X axis) tilt, as that's what would be introduced by non perfectly aligned dual z screws on the ender 5 plus. |
|
Here's 2.0.9.3 with a G29 J4 V4: All corrected_z values look reasonable. Here's -bugfix with G29 J4 V4: Some corrected_z are still quite high. Overall mesh isn't as far out, but maybe that's because of the 4x4 tilting grid? And for fun, I enabled debug_leveling_feature and ran a normal 3point tilt on bugfix. Not sure if this will help or not: Tilting point 2/3 is still weird. |
|
A good place to start debugging this might be to examine the data passed to and the data changed by these function calls, and compare them between 2.0.9.3 and 2.0.9.4. https://github.com/MarlinFirmware/Marlin/blob/2.0.9.3/Marlin/src/feature/bedlevel/ubl/ubl_G29.cpp#L1456 Less likely but still possible, it could be a loss of precision somewhere along the line, as computations such as https://github.com/MarlinFirmware/Marlin/blob/2.0.9.3/Marlin/src/libs/vector_3.cpp#L68 The code in general seems to use a lot of macros and inline functions, and frequently there are functions defined within header files. |
|
If/when I have time I'll try to reproduce the problem on my machine and see what I can do. |
|
Think I might have found something, line 268 of ubl.h in 2.0.9.4, get_mesh_x is a static float, but x0 and x1 which are set using it are being initialized as const uint8_t. https://github.com/MarlinFirmware/Marlin/blob/2.0.9.3/Marlin/src/feature/bedlevel/ubl/ubl.h#L268 I'll try changing the variable type and test it tomorrow, will let you all know how it goes. |
|
This alteration yields the following leveling topologies (First is after a fresh probing G29 P1 and P3, second is after G29 J), to me it looks as though it could be correct, it's much much closer than it was previously: I'll do my best to continue to validate this |
|
Done some G26s, and am pretty convinced that this has solved the issue. I'll try and make a push request once I'm out of work this evening. This was tested on 2.1.x bugfix , though I think the UBL code hasn't changed since 2.0.9.4, so it should work for all versions between. |
|
I didn't really understand your original post as to what you figured was wrong. My C skills are kinda non-existent. Can you post a diff, or the changes you made? I can verify tonight on my Ender 5 plus. |
|
In the referenced file, ubl.h, change line 267 and 268 from: to: |
|
Got a PR open, so can clone from here until it's done: https://github.com/jamespearson04/Marlin |
|
Good find, though it's not immediately obvious to me how it relates to the bug in this issue. I wouldn't think that G29J has anything to do with the interpolation procedure itself. |
Thanks. I'll try in 4-5 hours. I manually changed (patched) ubl.h for 2.1.2. Reading the PR and it now makes sense. My 3 point 'tilt' only had issues with point 2, which is the farthest right (highest X value) at x=310. My 4x4 16 point tilting only had problems with x>255 tilting points. This bug wouldn't have affected me if I had a smaller machine (ender 3 ish). All meshes here show a bed of X > 255. |
|
I can't say I've traced back the particular part where G29 J uses it, but the level probe points don't necessarily lie on top of the mesh points, so the interpolation will be used at some point along the line to calculate the mesh height at the level probe points in order to work out the difference for the adjustment. If the bed is big enough, the rightmost point will have an x coordinate above 255mm, which will bring out the rollover issue, giving completely incorrect values at the interpolation stage, which when used for the tilt gives another completely wrong result. |
|
@titanrw Yep, exactly, only affects beds over X:255mm. Even if we didn't screw the leveling with G29 J, the same function is used for the leveling whilst printing, so any prints past x=255mm would level erratically anyway. Explains some other issues people have been having with G26 past that point too. |
|
@apulver This is the function for the tilt leveling: Plenty of uses of and the grid version: |
I see now, I think you've got it.
I see, so in this case, the planar component of the mesh itself is also approximated by taking the plane defined by those three points on the mesh. This seems less than optimal since it can be computed exactly by using least squares on the whole mesh, which is essentially part of what I suggest here #25262 (comment), but I digress. |
|
So if I'm understanding correctly, your FR is essentially about pre-tilting the mesh to it's most level position before storing it? Interesting, though the bed should be trammed before probing, and shouldn't move a large amount after, so I'd wonder if it'd be worthwhile - more transformations might result in a loss of accuracy, and since in theory you don't need to tilt it initially, you may be starting with a less accurate mesh. With regards to the leveling though, the fact it uses only the 3 points means that any high or low spots don't affect the measurement. If you were to try and compare planes, a high spot under one of your 3 points would result in the measured plane being very different to the computed plane. Whereas with the current method, any such high point would also be present in the mesh, so would automatically be accounted for. |
Yes, essentially.
I do understand that. What they're doing now is a quick way to account for how the bed's planar component has changed. That is, by taking the delta for each point to compute the transformation. There's nothing terribly wrong with that, but I think having the UBL mesh handle the bed's non-planar component and G29J handle the planar component would be a clearer and cleaner way to organize the code and documentation and would actually simplify some of the math. Incidentally, I imagine that the presence of G29J's menu option is rather confusing for most users. "Do I make a mesh or use three point leveling? Why are they both present?". It's a bit of a mesh. Not quite on the level. |
|
I have to disagree entirely, it just doesn't seem beneficial at all. If it even works, the only effect to be seen will be increased resource usage. You mention overwriting in your FR, but that isn't relevant either because:
Basically there's no good way around the fact you need the tilted mesh in memory. If you try and seperate the plane from the surface, you just have to put them back together again anyway. And the fact that levelling the bed will align it with the mesh is moot, because you should've levelled the bed before probing it anyway, so they should inherently align. Sorry for being a bit of a downer, this just might be a bad use of your time. And as is basically essential for UBL, if they read the documentation, they won't have any issues. Just the unfortunate effect of a lack of LCD space I imagine. |
|
Just tested 2.1.2, with your PR merged (manually). Everything seems good now. Here's the console log: Tilting point 2/3 at -0.02, even at X=310. Considering this bug's been open since Aug last year, I'm glad it's fixed now. Thought I'd be on 2.0.9.3 forever. Now I can consider trying input shaping as that version of Marlin is usable now. |
I'm not disputing that. However, I don't see that there's significant extra overhead here. The mesh would be loaded and transformed according to the model of the bed's planar surface. G29J does the same thing each time you run it, except in this case, it can assume that the mesh is already level ( P.S. I should also say that adding a command to simply remove the linear component of the current mesh would not be very much work or very hard. That's all I was suggesting in the FR anyway. |
|
Fixed in #25453 |
|
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. |
Did you test the latest
bugfix-2.1.xcode?Yes, and the problem still exists.
Bug Description
G29 J seems to 'mess up' an already correct ubl grid.
This is on an ender 5 plus running mainboard 'BTT_SKR_MINI_E3_V2_0'
I was previously on 2.0.9.2, and everything worked correctly.
I upgraded to 2.1.1, and rebuilt the UBL grid, as I had to initialize eeprom. Saved grid to eeprom and verified it survives power cycles. This is the initial grid:
Max spread about 0.3mm. Decently good for a 350x350 bed I think?
My normal start g-code is:
I was doing the G29 J tilting correction, as the 5 plus has independent z-screws that are not 'belted' together. I try to align them as close as possible every time I power on the printer, but just in case they aren't exactly the same, I was using the mesh tilting to compensate.
However with 2.1.1 this is the mesh after the G29 J:
This now has a spread of about 2mm. The z-screws are definitely not that far off. Not realizing this messed up the mesh, I damaged the build surface as the printer applied a -1mm offset when it was originally measured as almost 0.
As a work around for now, I've commented out the G29 J tilting, and it's printing ok with UBL on. When I get a chance, I'll try -bugfix. I also might just run 2.0-lts.
Bug Timeline
2.0.9.2 didn't exhibit the issue.
Expected behavior
UBL mesh correctly modified for slight z-screw tilt.
Actual behavior
UBL mesh multiplied almost 10-fold.
Steps to Reproduce
Run 'G29 J' after UBL mesh populated and active.
Version of Marlin Firmware
2.1.1
Printer model
Ender 5 plus
Electronics
Stock other than BTT SKR Mini E3 2.0
Add-ons
No response
Bed Leveling
UBL Bilinear mesh
Your Slicer
Cura
Host Software
OctoPrint
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
Configs, and bed visualizer images below:
2.1.1-configs.zip
Before G29 J:
After G29 J:
The text was updated successfully, but these errors were encountered: