[BUG] <G2 and G3 arcs ignore the Z parameter on the MK4> #3179
Comments
|
I just had a look a the plan_arc() implementation and even the current bugfix-2.1.x marlin sources, and it seems that with UBL active the Z parameter is explicitly ignored: the arc is locked to the Z plane which is started on. Looking past the previous changes, this seemed pretty consistent for the past 2 years on UBL. So I guess the MINI FW is actually using ABL? |
|
@wavexx Thanks for checking that out. The fact that the Mini can print the arcs in 3D does indicate that it is using different code from the MK4, but I don't have a Mini myself. I don't know what UBL and ABL indicate. The gcode from PrusaSlicer for the MK4 has an MBL section that I assume is the bed levelling routine. I'd love to know how to specify the area for probing. Here is the section of code: ; MBL |
|
I should have added that I eventually got a response from the Prusa Customer Service person who I 'chatted' with online. It seems that Prusa is working on fixing the problem. Here is what he said: "A few days ago we were on chat talking about your issue with gcode.Unfortunately, G2 and G3 do not work with the Z axis at the moment, so you can't use it the way you want. Our developers are currently working on that and it should be fixed in the near future with one of the next FW releases. " |
|
UBL/ABL are two different mesh bed leveling implementations in Marlin, with UBL being generally the newest option. These can only be chosen when building the firmware from source, it's not a selectable runtime option via gcode unfortunately... |
|
Even though the g-code is hand-generated, I assume that the over-extrusion that comes after the spiral mode is started is "intentional" (slic3r/prusa-slicer had this issue for ages):
|
When interpolating the Z (and other non-XY) axes, reconstruction the position from start of the arc and current segment index, *then* apply the modifiers, so that modifiers are not accumulated for each vertex. Recalculating each absolute vertex location also reduces the error (and resulting jitter) of the Z/E axis for long moves at high resolution. For the same reason, this is also now done uniformly for all axes even if not affected by modifiers. At the end of the arc planning, correctly set current_position to the final logical position (that is, without modifiers). This fixes Z interpolation in arc moves in both ABL/UBL (bug prusa3d/Prusa-Firmware-Buddy#3179), removing the need for exceptions.
When interpolating the Z (and other non-XY) axes, reconstruct the position from start of the arc and current segment index, *then* apply the modifiers, so that modifiers are not accumulated for each vertex. Recalculating each absolute vertex location also reduces the error (and resulting jitter) of the Z/E axis for long moves at high resolution. For the same reason, this is also now done uniformly for all axes even if not affected by modifiers. At the end of the arc planning, correctly set current_position to the final logical position (that is, without modifiers). This fixes Z interpolation in arc moves in both ABL/UBL (bug prusa3d/Prusa-Firmware-Buddy#3179), removing the need for exceptions.
|
Heh, heh. No, the over-extrusion should not be there. It looks like I might have left out the necessary tapered layer prior to the start of the helical portion. I'll upload another test piece code after I print it on my Voron later today. |
|
OK I looked at the gcode and that over-extrusion was a result of me not putting in a line to move the nozzle up by a layer prior to the lines that start the helical section. That meant that the first 1/3 of a loop was too near the previously completed layer. This new code has that fixed, and the zipper seam is a little wider to be more obvious. |
|
@MichaelJLew responding here. The fix is merged in both marlin and in this fw in the latest alpha. So your gcode should now work correctly. If you can confirm, we could close this issue. PrusaSlicer doesn't use this in vase mode (yet at least), but the two things are independent. |
|
@wavexx Thank you! I'll install the alpha today (as soon as I work out how to go back to the stable release...) and test it out. |
|
Fixed now in 5.1.0 alpha 2. Thank you @wavexx ! |
|
Closing. |
Printer type - [MK4]
Printer firmware version - [4.7.2]
Original or Custom firmware - [Original]
Describe the bug
G2 and G3 controlled arc commands ignore the Z parameter. That means that arcs cannot be used to make helices where the Z level at the end is different from the start.
Arcs where the Z level is supposed to change print as flat arcs. A vase-style cylinder constructed with arcs prints all on one level and ends up as a flat donut of excess extrusion.
I have a couple of threads on the forum exploring this problem, and one user showed that the problem does not happen on his Prusa Mini, and I found code in the 8 but firmware that deals with arcs in X,Y, and Z, so it seems to be MK4 specific.
See here: https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4-hardware-firmware-and-software-help/g2-and-g3-arcs-dont-work-properly-on-mk4/
and here: https://forum.prusa3d.com/forum/general-software-discussion/what-makes-gcode-file-printable-on-prusa/paged/2/#post-663323
How to reproduce
The attached model is a hollow cylinder made of arcs. The lower 5mm has layers and the arcs print correctly (even if the Z parameters are ignored). The upper 5mm is a helix that should give a vase-style cylinder.
In the file the header and footer portions are taken from a PrusaSlicer cylinder print file and the model portion is hand coded (with custom software).
Expected behavior
The file should yield a straight sided cylinder 10mm tall but on my MK4 only the lower portion prints correctly. The upper half is a mushy donut because Z height stalls at 5mm even as the rest of the print tries to continue.
G-code
Arc test cylinder c.gcode.zip
The text was updated successfully, but these errors were encountered: