[BUG] Odd behaviour with UBL #18977
Comments
Marlin is updated daily, so it's best to try the latest |
|
I have just diffed 66676e6 to bugfix-2.0.x and found no substantive differences in code that could be related to motion or bed levelling. There were plenty of differences, but they were all in one of these categories:
In particular, I also looked in particular detail at the I am not able to just merge latest and rebuild right now, because this code is actually running the print where this odd movement has been observed. But, I am reasonably convinced that there haven't been code changes to the parts responsible for this behaviour. |
|
Please download |
|
Well, at the current rate I won't be able to do that for about a week. This print will be running until then. I'm disappointed that there's zero possibility of any investigation while the print is running that might reveal a solution that could prevent further damage to the print itself. But, once this print is complete, I'll reapply my configuration changes onto the latest |
|
I have upgraded to the latest Video: https://youtu.be/ziZTLfE1tbE New mesh (parameters are slightly different, but the overall shape looks pretty much the same): |
I too experienced this at the back and right side of my bed, just like on the video. But mine might does that weird z movement in the other direction, so it squishes the line more to the bed. SKR Mini E3 v1.2 |
|
In my case, it seems to temporarily go to higher Z value, which for my printer means physically the bed moves down. It moves a lot, too, way more than one layer's worth. The original video linked in the issue description shows this behaviour from a different angle. |
|
Ok, now I see. I have |
|
Just chiming in, that I'm experiencing the same behavior using a recent bugfix as base (d9ad8ca; my firmware here). Unlike @logiclrd's mesh, which has negative offsets at the border of the behavior, mine has positive offsets: Whenever the nozzle travels near the rightmost margin of the print bed, it abruptly drops to zero, as if no offsets are being applied there. |
|
This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days. |
|
I still experiences sudden jumps in Z height at the back and right side of the bed with UBL. Latest Bugfix-2.0.x |
|
@qwewer0 curious, where is your origin defined? Mine is slightly outside my 220x220 printable area, at -5,0. I'm wondering if the nozzle jumping is occurring when the nozzle is going beyond x_max + x_min, or 215. |
|
@tanaes Not sure, but I only tested to the end of the mesh, and not to the end of the bed. |
|
In my case, my bed is 400x400 and |
|
But, I should add, not all points that are inside the bed area and outside of the mesh. In the attached video, Marlin seems to be having a great deal of confusion about the correct Z height as it moves along a straight line at a constant Y value outside of the mesh. |
|
That's because unlike Bilinear, UBL does not extrapolate outside the mesh. The proper way to use UBL is to make the mesh the size of the bed and set PROBING_MARGIN to avoid probing outside the (25,25)/(375,375) area. Then use |
|
I got this problem within the UBL mesh area. Edit: And my mesh was measured entirely by the probe. |
|
Hmm, so if I don't want to probe the outer 25mm on all sides, I can't get better than a 13x13 mesh? Why is there a 15-point hard upper limit on the number of points per axis? |
|
The limit is because a mesh is one of the biggest users of EEPROM. You can definitely get a 15x15 mesh - it's just that you can't probe all of it. |
I have 15x15 UBL mesh on "235x235" bed with PROBING_MARGIN/MESH_INSET of 10 and all of the mesh points are probed automatically by the probe, because my X/Y_MIN_POS, X/Y_MAX_POS is allows it. |
|
I decreased my |
|
@ManuelMcLure and @logiclrd is there actually an issue here, or can this be closed? It seems like this is likely due to a misunderstanding regarding the UBL mesh, and everything works fine when the print is confined to the mesh boundaries? |
|
I can't seem to reproduce the issue on the latest bugfix-2.0.x.
|
|
As far as I know UBL does not extrapolate outside the mesh. |
|
@ManuelMcLure Thanks, didn't know that. |
|
This is probably better discussed on Discord since there doesn’t seem to be a bug here. |
|
So, this can be closed? |
|
i would say yes.... no response from logiclrd in over a month |
|
I can't immediately test it, because my printer is presently broken 😢 but I did do a couple of print runs after reworking the settings to not use MESH_INSET, and I'm pretty sure I did not observe the strange behaviour. |
|
Could not reproduce it on the latest bugfix, but I would wait for @logiclrd's printer to see if the problem still coccus. |
|
It seems very likely that this has been addressed by #20538. Please re-test with the bugfix-2.0.x branch and close this issue if it is no longer a problem. |
|
Unfortunately away from my printer for about a month, but I will definitely check as soon as I can get back to it. This sounds like exactly the thing! |
|
This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days. |
|
Just had another encounter with this behaviour, and can confirm that is almost certainly "by design", but I think the design could perhaps be improved. Basically, if it reaches a point where the mesh isn't defined (either past its boundaries, or a point that hasn't been sampled), it treats it as though it's a zero, causing a very abrupt change in Z. This is almost certainly undesirable. Perhaps there should be a better way to handle this? Improved feedback, improved default behaviour? In the print I have running right now, I had just re-measured the grid, because I added hardware to my hot end and re-flashed the firmware, and the new hardware restricts the range slightly. Because of this restriction, the entire line of points at max X were unsampled, because it can't get the probe there. I saw it behaving really oddly in the print every time it got to the right edge, and actually issued |
|
This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days. |
|
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
Forgive me in the event that this is a known issue, perhaps even already fixed, because my build of Marlin is a little bit behind. I do not have the liberty of updating it and trying a new version at this exact time, because I am observing the bug in an ongoing print that I don't want to interrupt and that I'm hoping will manage to produce acceptable results despite the bug. I have identified the exact upstream commit upon which my changes are currently based in the "Additional Information" section.
I have a printer with a 400x400 mm build plate, and I recently enabled UBL and measured a 15x15 mesh. I have included the mesh under "Additional Information" below.
I began a print that covers 350x350mm of the build plate -- almost the entire area. This print is proceeding very well in all areas except the very topmost area (largest Y values), where a strip is being treated very strangely, presumably by the UBL code. It's almost as if there is an abrupt end to the leveling mesh, and past that end, it does not interpolate linearly, but drops out suddenly, and every time the print crosses that boundary, Marlin raises the Z considerably, only to immediately lower it again. It's causing some artefacting that will almost definitely be visible in the finished product.
I have recorded a video of this behaviour: https://youtu.be/zdeDZaIIRdg
I also believe I have isolated the G code executing at the exact time of the video. I have included this in the "Additional Information" section as well.
This G code does not include any changes to the Z offset, so it seems likely all Z movement is the result of the UBL code. The coordinates in the G code range from (20, 20) to (380, 380), and I am printing with
M206 Y-9to compensate for centering issues.My Configurations
MarlinConfiguration.zip
Steps to Reproduce
Enable UBL on a 400x400 bed with 20mm inset. Record a 15x15 mesh.
M206 Y-9Begin a print that covers a square range from (20, 20) to (380, 380).
Expected behavior:
The print proceeds smoothly over the entire build area.
Actual behavior:
The print proceeds smoothly over the entire build area except for just a few millimeters at the upper extreme end of the Y range, where the bed starts wildly raising and lowering.
Additional Information
Marlin upstream base: 66676e6
Video: https://youtu.be/zdeDZaIIRdg
UBL mesh:
UBL bug video G-code: UBL bug video.gcode
The text was updated successfully, but these errors were encountered: