Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Under specific conditions, PrusaSlicer generates gcode with travel to invalid locations #14079

Closed
2 tasks done
petrisi opened this issue Feb 3, 2025 · 4 comments
Closed
2 tasks done

Comments

@petrisi
Copy link

petrisi commented Feb 3, 2025

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:

  1. With the attached 3MF, perform the following
  2. Change infill setting, slice
  3. 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.
Image

Repro with invalid X axis coordinates X-1084.
Image

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:
Image
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:
Image

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):

  1. Open 3MF
  2. Slice
  3. Enable travel from the preview, see if you have head travel to obviously invalid locations (if yes, repro succesful)
  4. Change infill %
  5. 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

@petrisi
Copy link
Author

petrisi commented Feb 3, 2025

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.

@lukasmatena
Copy link
Collaborator

@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.

@petrisi
Copy link
Author

petrisi commented Feb 4, 2025

Thank you @lukasmatena , is there an issue I can link this to and close as duplicate?

@lukasmatena
Copy link
Collaborator

Should be fixed in PrusaSlicer 2.9.1-alpha1. I hope you got everything sorted out with the support. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants