Default (or lower) g-code resolution settings results in missing retract/deretract and wipes

[freakydude]

Description of the bug

Retraction, Deretractions and Wipes (while retractions) seem to be randomly missing or displaced. It can be easily reproduced with the attached (fresh created) retraction-simple.stl retraction test.

Decreasing the Overlap: "Infill/perimeters overlap" parameter from default 25% to 15% or 10% g-code resolution makes the problem worse and more visible. Setting the default perimeter width to exactly 0.4mm makes it less visible.

Changing the Slicing: "G-code resolution" parameter from default 0.0125mm to 0.001mm results in to perfect generation of Retraction, Deretractions and Wipes - even the seam is then exactly accurate in the slicer (please spend a few minutes to experiment)

So it seems to me that a smaller "G-code resolution" would not only reduce the resolution - but more importantly, skip essential actions or at least not place them correctly. And the problems exists even with default "G-code resolution" of 0.0125mm.

My expectation would be that, regardless of the g-code resolution, things like retraction/deretraction and wipes would definitely appear in the g-code and not be lost.

See also the issue with 2.7.2-alpha2 - the problem is not the same but in the same corner https://github.com/prusa3d/PrusaSlicer/issues/12219#issuecomment-1937802047

With best regards freakyDude

Project file & How to reproduce

2.7.1-gcode-resulution-bugs.zip

Checklist of files included above

• [X] Project file
• [X] Screenshot

Version of PrusaSlicer

2.7.1+win64

Operating system

Windows 11

Printer model

Artillery Sidewinder X2 with Klipper

[virtualcomputerguy]

I did not spend the amount of time you did testing this. But I am seeing the same results with version 2.7.2 Alpha 2. Retraction does not appear to be happening at all during prints, visible artifacts on the print and lots of stringing. I have tested this on both of my Voron 2.4's. I am reprinting the parts on version 2.7.1, so far the parts look good.

[cordilon]

Seems I'm having the same issue. I feel it is connected to the size of the object, or in other words: Small circles like that are broken down into irregular linear pieces in PrusaSlicer, which could be connected to this issue. Have you tried scaling up the objects and seeing if it behaves the same?

[freakydude]

No, not yet. But that would make sense. Think it's a 'simple' floating point data type issue somewhere in the slicer design