You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Under certain conditions, PrusaSlicer generates movement commands to wildly invalid locations.
Make sure to enable "Travel" visibility in the slicer.
Steps to reproduce:
With the attached 3MF, perform the following
Change infill setting, slice
Repeat step 2 until the bug in slicer is triggered and you see head movement to wildly incorrect coordinates
How do you recognize when you trigger the condition? Please see sample images below:
Repro with invalid Z axis coordinates Z-2147. Happens to be the minimum value for Int32.
Repro with invalid X axis coordinates X-1084.
In my case I ran into this issue during normal print operations. I switched to Classic perimeter generator because Arachne created broken tips to the cones in the model. This was the resulting g-code:
It tries to move to Z-2147, ramming the bed to the toolhead. Then tries to wipe the head to the wipe tower (among other movements).
And this was the result:
The issue seems to be related to Classic perimeter generator. I have not been able to reproduce using Arachne.
I contacted Prusa Support about this, they were able to reproduce the issue, but after investigating for 2+ weeks the conclusion was that ".. the error with the negative Z-height and invalid X coordinates is likely due to modifications in the slicer settings..". I am currently escalating my support case since this is obviously incorrect.
a) The slicing result is inconsistent. Sometimes it takes multiple tries to reproduce, sometimes it is triggered on the first try
b) The coordinates generated are wildly off. Likely buffer over/underflow or otherwise random contents of memory (assumption).
c) The manifestation of the issue varies by machine. I tested with 3 machines with same PrusaSlicer version and other settings except OS, #1 produces invalid movements on Z axis, #2 the slicer just crashes, #3 produces invalid movements on X axis.
Until this is fixed, especially with Classic perimeter generator, make sure to check the travel from the g-code preview before sending it to the printer. (Travel is hidden by default)
Including the 3MF that can be used to repro and multiple gcodes from two different computers. (On third machine PrusaSlicer just crashes when reproing)
Steps to reproduce (using PrusaSlicer 2.9.0):
Open 3MF
Slice
Enable travel from the preview, see if you have head travel to obviously invalid locations (if yes, repro succesful)
Change infill %
Slice again (goto 2) until you see it reproing or PrusaSlicer crashes
Changing the infill % might not be required, but that allows you to reslice and that is how I managed to repro it easily.
Checklist of files included above
Project file
Screenshot
Version of PrusaSlicer
2..9.0
Operating system
Windows 10, Windows 11
Printer model
Prusa XL 5TH factory assembled
The text was updated successfully, but these errors were encountered:
I can confirm this is reproducible with Prusa XL 5TH IS stock profile by just importing the 3d model, switching to Classic perimeter generator and doing the slice/change infill%-dance.
If your slicer crashes, you are lucky. If you are unlucky like me, you get invalid coordinates and your toolhead crashes instead.
@petrisi Hi. I am very sorry, but what you have experienced is really a bug in PrusaSlicer. It can happen in a very unlikely corner case in the G-code generator. It is not directly caused by Classic perimeter generator, with a different model and enough of bad luck you could get the same with Arachne. It will be fixed in the upcoming 2.9.1 release.
The tech support was not yet aware of the bug at the time they communicated with you, it is new in 2.9.0. They were informed about the situation, and they will sort the situation out. I am very sorry for the inconvenience.
Description of the bug
Under certain conditions, PrusaSlicer generates movement commands to wildly invalid locations.
Make sure to enable "Travel" visibility in the slicer.
Steps to reproduce:
How do you recognize when you trigger the condition? Please see sample images below:
Repro with invalid Z axis coordinates Z-2147. Happens to be the minimum value for Int32.

Repro with invalid X axis coordinates X-1084.

In my case I ran into this issue during normal print operations. I switched to Classic perimeter generator because Arachne created broken tips to the cones in the model. This was the resulting g-code:

It tries to move to Z-2147, ramming the bed to the toolhead. Then tries to wipe the head to the wipe tower (among other movements).
And this was the result:

The issue seems to be related to Classic perimeter generator. I have not been able to reproduce using Arachne.
I contacted Prusa Support about this, they were able to reproduce the issue, but after investigating for 2+ weeks the conclusion was that ".. the error with the negative Z-height and invalid X coordinates is likely due to modifications in the slicer settings..". I am currently escalating my support case since this is obviously incorrect.
a) The slicing result is inconsistent. Sometimes it takes multiple tries to reproduce, sometimes it is triggered on the first try
b) The coordinates generated are wildly off. Likely buffer over/underflow or otherwise random contents of memory (assumption).
c) The manifestation of the issue varies by machine. I tested with 3 machines with same PrusaSlicer version and other settings except OS, #1 produces invalid movements on Z axis, #2 the slicer just crashes, #3 produces invalid movements on X axis.
Until this is fixed, especially with Classic perimeter generator, make sure to check the travel from the g-code preview before sending it to the printer. (Travel is hidden by default)
Project file & How to reproduce
invalid.travel.zip
Including the 3MF that can be used to repro and multiple gcodes from two different computers. (On third machine PrusaSlicer just crashes when reproing)
Steps to reproduce (using PrusaSlicer 2.9.0):
Changing the infill % might not be required, but that allows you to reslice and that is how I managed to repro it easily.
Checklist of files included above
Version of PrusaSlicer
2..9.0
Operating system
Windows 10, Windows 11
Printer model
Prusa XL 5TH factory assembled
The text was updated successfully, but these errors were encountered: