Z at right edge out of mesh border is being overcompensated for UBL with a 9x9 mesh #271
Comments
|
Please, can you dump your mesh values? |
|
I don't think the bug is specific to my mesh data, but here it is: One other thing I found out is, the bug disappears after a reboot. I took the mesh posted above, had it tilted, tried a print, bug was there. Stored the mesh to memory slot#1, rebooted the printer and loaded mesh from said slot, tried a print, bug was gone. One possible source might be that on the right side of the bed, the mesh doesn't cover the whole bed since the probe is offset to the left. So the spot where the bug happens is outside the mesh area. For people with stock probe position with offset in x and y, the bug might happen in the back also since they can't probe that far in the back. I'll try a smaller mesh inset, see if the bug appears at other spots as well. |
|
Okay, reducing the mesh inset yielded results: on a 5x5 mesh, it said "the print got stopped" and I had to confirm to continue, but there was no "jump" bug. So it does have to do with printing outside the mesh area, but it still only happens on the right side. It can be avoided with printing inside mesh area and, if tilt function has to be used, you should reboot the printer afterwards to be safe. |
|
Please, I want to have the mesh data already tilted to see if there is any anomalous value. If the bug is present at 5x5 mesh, please do the test with that mesh size. |
You can set the physical limits to avoid that in Advanced/Physical Settings menu. |
|
As I wrote, I didn't get the jump on a 5x5 mesh. Also, my physical limits are correctly set. Manually, it's impossible to go out of printing area. At least that's how it was, when I set it up. Will check again. I'll have my mesh tilted and get the data dumped, but as I wrote, if i store the tilted mesh to a memory slot and reboot, load said mesh after the reboot, the problem disappears. |
|
I confirmed, my machine physical limits are correctly set. Here's the dump after tilting command: Since the user prompt is something the printer doesn't do on normal prints, here's the the console output of the printer after starting the print: It did jump again, but since I went back to the original bigger mesh inset, it stayed inside the printable area. After a reboot, it didn't prompt for user interaction after starting the print and it didn't jump anymore. If you want me to perform any other tests, it should be today, I'm not gonna have access to my printer for 4 weeks starting tomorrow. |
|
Please, post a capture of your info page. Thanks |
|
I have the same bug. "Jump" happens in back right corner of the bed. My BLTouch is on the left hand side from the nozzle. HS mode enabled. Grid size 9x9, no tilting enabled by me. Probe offsets: Bed size: Min position: Max position: |
|
Thank you for your report, I'm working on trying to replicate the bug to fix it. |
mriscoc
added
bug: Confirmed
|
UBL has some anomalies with move segmentation that can be solved by enabling SEGMENT_LEVELED_MOVES. And, when "outside" the known mesh bounds there may be a jump in Z with UBL. Perhaps this is a manifestation of one of those issues. |
Thanks. I was able to replicate the bug, the same behavior was found in the current Marlin bugfix 2.1.x. I will try those fixes. EDIT: SEGMENT_LEVELED_MOVES was active in Configuration.h |
|
How to replicate this bug with the firmware Ender3V2-422-BLTUBL: M502 ; Reset to defaults
C29 N9 T0 ; Mesh size to 9x9 and Pre-heat to 0
C851 M0 ; Multiple probing to 0
G29 P1 ; Take a new mesh
G29 A ; Active the mesh leveling
G0 X205 Y140 ; move to the mesh border
G0 Z0 ; Move Z to 0, the head moves to the expected position
G0 X210 Y140 ; exceed the mesh border, the head moves and Z is raised
G0 X205 Y140 ; return to the border, The head moves to the expected positionThis behavior was not possible to replicate with a mesh lower than 9x9. |
|
With With File ubl_motion.cpp, function: unified_bed_leveling::line_to_destination_segmented, just before of planner.buffer_line: |
mriscoc
changed the title
|
A PR was submitted to the Marlin repository fixing this issue: MarlinFirmware/Marlin#24631 and will be available in the next firmware release. |
do you think it would be interesting to modify the file and compile the firmware at this point?
do you think it would be interesting to modify the file and compile the firmware at this point? |
|
The next version will have this issue fixed. |
|
Fixed in the latest version. |
|
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. |
I've got a 9x9 mesh, HS probing disabled, multi probing disabled (one probe per meshpoint). I'm running this precompiled version on an E3 S1 pro, F1 Board. My probe has been relocated to be in line with nozzle on y-axis. On a sidenote, the physical machine limits are/were incorrect (too small) and I had to set correct values, mesh inset is close to maximum size from what the probe can reach, which is bigger than on stock since I relocated the probe. (x min=10,0; x max=216,0; y min 10,0; y max 218,0)
The unedited mesh is too far away on the right back corner so I tried the "tilt mesh" function which resulted in this weird jump over a nonexistant bump. I included a video because it is so ridiculous. It didn't do it on the untilted mesh. The gcode file certainly has no Z-movements there. I've had this issue before, but the jump wasn't as pronounced as the one I got filmed here. I think back then, I didn't tilt the mesh, but used the "edit mesh" function, but I wasn't out to document a bug so steps might have been different. I've only ever seen this on the right edge, but maybe I didn't get close enough to the other edges. I had to rename the gcode file to csv, so it would upload.
Here's the video
this is my current mesh (after the tilt)
This is the testfile it happened with. (rename to *.gcode)
CE3_SquareTest.gcode.csv
The text was updated successfully, but these errors were encountered: