G-Code contains moves out of range

[blastrock]

Description of the bug

By slicing the attached file, prusa slicer generates two moves out of range

;AFTER_LAYER_CHANGE
;20.2
G1 Z20.6
G1 X103.611 Y7.288 F12000
G1 X104.389 Y-94.984 ; <---- negative
G1 X104.389 Y7.354
G1 X205.106 Y15.784
G1 Z20.2 F720
G1 E.5 F2100
;TYPE:Perimeter

The second one is at height 27mm.

I have two issues with this:

• It should not generate such invalid moves
• It should print an error if such moves are generated, I usually see a "A toolpath outside the print area was detected" when that happens, but not this time.

Project file & How to reproduce

container.zip

1. Open the project
2. Slice it
3. Open the gcode
4. See lines 99520 and 136458 for a negative Y value

Checklist of files included above

• [X] Project file
• [ ] Screenshot

Version of PrusaSlicer

2.8.1-linux

Operating system

Debian sid

Printer model

Sovol SV06

[u89djt]

(fellow user looking around) Noting in passing that the problem goes away when avoid crossing perimeters is deactivated, here are your negative moves: The classic perimeter generator produces similar output. If you right click and fix by windows repair algorithm, your negative y moves go away, and it looks like a feasible print. But that doesn't apparently fix all the problems. If I rotate the object 90 degrees, we see some strange stuff in the middle: Each time I slice any given rotation of the object during a single session in the slicer, the outcome is slightly different. I haven't found anything weird in the mesh yet. Seems like a bug.

[u89djt]

Here's a chopped down object that still has nonsensical moves: choppedcontainer.zip

[u89djt]

Here's a simplified box that glitches and a fusion file with history for someone else to noodle with. offsetnotch.zip

[blastrock]

Thanks a lot for taking the time to do this!

If you right click and fix by windows repair algorithm

Could you elaborate? I can't find this feature

[u89djt]

You're very welcome! Looking at a problem that hasn't hit me yet is relaxing :). OK, I've just noticed that you're not in Windows, so you probably haven't got the windows repair method! If you just rotate the object as it is now clockwise through 90 degrees, there are some silly travel moves, but it looks a feasible print. If you can't find a pose of the object that works, do you still have an option to send a mesh to a third party repair method in a linux build? It might be Netfabb. I think we can't know that it would have the same effect.

[blastrock]

Oh I see, thank you! For the moment I removed the two out-of-range moves from the gcode and restarted the print, but I'll keep that in mind if I hit this kind of bug again.

[creativelies]

I have encountered this problem as well; slicing some files (which are years old and have been printed hundreds of times, are manifold etc.) with 2.8.1 with "Avoid Crossing Perimeters" selected results in negative moves between layer changes, where disabling that feature removes them. This does not happen in 2.8.0. I'm running Prusaslicer on MacOS.

That shown negative move is missing when slicing in 2.8.0 with identical settings except for the "Avoid crossing perimeters".