G2/G3: Fix Z/helix planning on UBL

[wavexx]

Description

The current G2/G3 Z parameter is ignored unless ABL is enabled. If high-resolution arcs are planned (small MIN_ARC_SEGMENT_MM or high MIN_CIRCLE_SEGMENTS) the accumulated error on the last segment can be significant, resulting in jitter when exiting from the planned arc.

This PR addresses both. From the commits:

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.

Requirements

None

Benefits

Fix Z arc interpolation with UBL. Reduce jitter at high res. As a downside, it does require an extra multiplication per axis/iteration, so it is slightly more expensive for older cpus like AVR or without FMA.

Configurations

Hopefully none needed. Test with UBL enabled.

Related Issues

Originally reported here: prusa3d/Prusa-Firmware-Buddy#3179 which includes a test-case.

[thinkyhead]

This introduces potentially a lot of extra multiplication –at least two for the most common case– which would be nice to try and avoid. Is multiplication actually more accurate than successive additions?

[thinkyhead]

As above, is multiplication actually more accurate than successive subtractions?

[thinkyhead]

The current G2/G3 Z parameter is ignored unless ABL is enabled.

That would be quite an error, and it doesn't seem to be true. How did you reach this conclusion? In my own testing, without any form of leveling enabled, an arc in XY with a change in Z does move Z. And a G2/G3 move with only Z also moves Z.

[wavexx]

This went in before I had time put in a detailed answer... I do have some numbers to corroborate the above (most of this was discovered in the mentioned test case).

The error is most significant for the Z/E axes (in the E MK4 case using >400 steps/mm) with a small MIN_ARC_SEGMENT_MM, where the error on the last segment can exceed 1 step. Of course, the MK4 uses a STM32F4 with FMA, so the effective cost is the same on that hardware, which is why I didn't give too much though on it.

As for Z, raw[axis_l] = start_L (done in two places with UBL explicitly) will lock Z to the starting plane of the arc, but will not interpolate through the start/end coordinates.

This is shorter than what I originally wanted to write (I just need some extra time).

[MichaelJLew]

Excuse me for not being able to follow the process here, but is this fixed? I notice that the release notes for PrusaSlicer 2.7.0 alpha 1 say that the slicer will use G2 and G3, but NOT with vase-mode. That makes it sound like the G2 and G3 commands will still ignore the Z parameter (at least on my MK4).